I didn't choose to renew my iPhone developer membership. So after a year, the apps I built with my provisional certificate stopped working on my phone. I really don't like the idea of paying Apple 100.00 bucks a year to put an application I wrote for myself only, on my own phone. Maybe there was some other certificate I should have been using, but it's too late now. I need to spend another 100.00 bucks to get my app working on my iPhone.

My membership is just about to expire. I don't think I'll be renewing it, but strictly because the company I work for is getting a membership.

I'm not sure why'd say little has changed. The development tools have been updated significantly. And the process of getting a signature, installing it, selecting it and building with it (and troubleshooting along the way) has changed quite a bit, and all for the better.

Neither is a major change, but they are a couple good sized steps in the right direction that make my life easier on a (nearly) day-to-day basis.

I'm not saying it hasn't got a long way to go, but I don't see how you can view the last year as anything other than positive. The Apple interaction part is still horrible as far as I can see, but it certainly is no worse than last year.

Re-reading that, I come across as too positive for my taste. I meant "anything other than mildly positive." If it was good enough a year ago, it's very slightly better now.

Agreed. I'm still helping on the sidelines with another iPhone app, but I've cancelled my own independent iPhone projects as well and won't be renewing in the program. I'd much rather focus on Mac or web development where I can control the process.

Steven Fisher: Key word in my summary was "substantive". Yeah, they've done quite a few little things, but the major problem remains. We now get fancy ketchup on our turd instead of the store brand. Well, that's better, but doesn't change the turd.

Mike, I meant to sound more like I was agreeing with you than I did. I just got my tone completely wrong. I remain on the platform, but it's frustrating.

I certainly agree the process hasn't seen any real improvements. Although it's too late for Erik W., if anyone else is in the same boat, I am fairly certain any apps you create and sell on the store (free or non-free) continue to work even if you don't renew your contract. So if you have an app that you want to continue to use (and think Apple will approve it), you can submit it to the store.

I also agree that in many ways it's easier to make money on the Mac and there are fewer hassles. The biggest frustration for me is needing to wait two weeks to release an update even if it's a one-line bug fix. I understand why - Apple doesn't have the source code for my app. To them it's not much different than reviewing a brand new app.

The reason I plan to renew my contract is I have a regular "day job" and this was an easy way for me to take the first step as an independent software developer. I didn't have to set up my own e-commerce site, do any advertising, etc. I realize that step isn't incredibly difficult, but that was a hurdle I'm not ready to tackle.

I agree that if you're a Mac developer with an existing e-commerce setup, there's not much incentive to spend time developing iPhone apps unless you think your app will sell many, many more copies than a Mac app you develop.

My app is a relatively niche app (takes attendance so it's mainly used by teachers). Without any work other than the actual coding (no advertising) on my part I've made about $4500 in 9 months. Obviously, I can't quit my day job on that and if I value my time at much more than minimum wage, it's barely worth the effort. But since I enjoy programming, it's $4500 I wouldn't have otherwise and I have an app I want to use.

I do hope we will see improvements. I agree it's not much different than it was a year ago and I'm not optimistic that it will improve in the near future.

That's a pretty big generalization.

I've made money developing iPhone applications and dozens of my friends have as well. Some of my friends are doing it full-time and other ones are planning to very soon.

Mike Rundle: A statement of probability is not a generalization. A generalization would be if I said "nobody makes money at it."

And of course, "won't make any money" is exaggeration for effect. Any paid app in the store is going to make some money. It just probably won't make a lot.

How do your full-time iPhone development friends feel about the fact that Apple could destroy their livelihood in a moment with no hope of appeal?

Although I agree that the app store process is a giant frustration, it's still a step up from developing for J2ME handsets. For those, the carriers have strict control over what apps they display to users, and if your app isn't on their decks, nobody will ever see it. Many carriers also use the "Java Verification" stamp of approval system, which in my experience was a far bigger pain in the ass than Apple's approval process. Plus, having the App Store be the centralized and easy-to-use location where users look for their next purchase is a giant improvement over the carriers' decks.

The bottom line is that developing apps for the iPhone is the most viable of all revenue-generating models for mobile in general currently, but your iPhone app will still (for probably 95% of developers) not pay your bills. (Luckily (sheerly luckily), I happen to work with a great marketing team, so my apps all do generate significant revenue, but not nearly as much as, say, apps on Facebook.)

My favorite quote about this is http://twitter.com/joehewitt/status/3522913927. So true. But this is the world of mobile development, unfortunately.

Amanda Wixted: Yours is an argument I hear a lot, and it's absolutely correct as far as it goes. Many other mobile platforms are far worse.

The problem is this: I don't care. The fact that J2ME handsets are ten times worse than the iPhone doesn't make me feel better about the iPhone. It's still cumbersome, it's still unnecessary, and it's still way harder and less attractive than doing Mac development.

I'm a Mac developer, so ultimately I compare iPhone development to Mac development. Comparisons to other phones are interesting from an abstract point of view but ultimately make no difference to me. The question is not, "Which phone shall I develop for?" It's, "Shall I develop for a phone at all?" Answer: no.

Wow. That's an understatement. The SDK over the past year has seen substantial strides. Many of the changes have been specifically for developers to make our lives easier. From new APIs to access the iPod, to porting a desktop technology (CoreData) to the phone...Apple wants to help us develop applications.

I think it's worth pointing out how amazing developer for the iPhone is after it's set up. The tools and sdk are first class. We get to program with an amazing language with amazing, desktop class, frameworks.



Insane eh? On current projects, I lose maybe 5 hours to certificate setup and provisioning. And about the same submitting. I don't know about you, but that leaves about 99% of my development time on coding. That sounds about right to me.

It's a stupid habit of mine that when I'm unhappy with the code I'm writing, I work at about 1/10th of my usual pace. Despite all the cool hardware and software potential, I also find "no joy in iPhone development" because of Apple's authoritarianism.

Since even interesting ideas were proceeding at the "slow motion me" rate when they needed to end up in the App Store, I've don't waste my time trying anymore. Between the Web and Snow Leopard, there's plenty of cool territory to explore outside of Apple's dystopian "revolution".

I agree the process is extremely frustrating, and possibly getting worse (witness favoritism of the Flickr app update in under a week) as we speak. But the tools themselves have gotten better. Things are much more stable now than during the run-up to 2.0.

I disagree when you say the platform is crippled by the lack of quality applications. It's still just too darn hard to find them.

I agree with the assertion that in general we probably won't make any money at iPhone development, but some of us are making a living out of it. Perhaps having multiple apps in the store helps. I won't recommend to anyone with just a "good idea" that they quit the day job. But personally I don't see any reason to abandon the platform now.

Zac White: It's interesting how different people have had such vastly different experiences with the toolchain.

If I only lost 5 hours per project, that might be tolerable. (Still insane: setting up a Mac project is literally five seconds.)
But it wasn't 5 hours. It was far more.

The problem lies in your "after it's set up" phrase. No such state ever existed for me. My tools would break at the slightest provocation. Upgrade Xcode? Spend hours struggling to make things work again. Upgrade iPod OS? Ditto. Upgrade iTunes, everything breaks, spend hours fixing it.

And then there were partial failures. My debugger would stop working for a month at a time, spontaneously, at random. Just as spontaneously it would come back. Try as I might I could never detect a cause or a solution for this. Going for a month without a debugger is completely unacceptable just by itself, let alone with all the rest of this craziness on top of it.

As for the amazing environment, I don't know what's so amazing about it. It's a small Mac where everything runs in a sandbox. Big deal. I guess it's "amazing" compared to all these crap platforms out there, but the Mac is far more amazing yet.

If Apple wants to help us develop applications, why do they stand in our way so much? It's not like it would be hard work for them to flip the switch and allow us to install arbitrary applications on our phones without their intervention.

Matt Martel: If I can't find them, they might as well be there. The number of third party apps I regularly use on my iPhone is ridiculously small compared to my Mac. It's pretty much just Twitteriffic and AIM (and AIM is a giant pile of crap, not even close to "quality", I only tolerate it because of Push) with any frequency, and TouchTerm and Stanza occasionally. Most apps are small, fast projects designed to be built quickly and make a bit of cash, not to be long-term viable. I place the blame for this squarely on Apple: when you've pushed prices down so far, and any given idea could be wholesale rejected from the platform for no good reason, it doesn't make sense to dedicate serious effort to building an iPhone app!

I have to disagree with you, not on the Apple part of your story. Not on your personal side. On the iPhone vs mac story.

I've wanted for years to create an app and make 'some' money on it on the mac. But all the way from 10.1 to 10.5 the APIs have extended so much that building a quality app on the mac has become a job for titans.

The iPhone is a wonderful device, and you cannot compare cocoa touch to android. It doesn't have the polish, the nice Apis and productive tools like IB. I sold my gphone after several months of it staying in the drawer. And I have been developing in Java before.

The iPhone is today like kindrgarten or sometimes high school for would be mac devs. We learn the rules, some of which are good (to known) some of which are bad (I'm looking at the AppStore yes. But we learn. And some make money. And some make enough money to become full time iPhone and mac devs too.

Another point where I think you might be wrong is in thinking that not having Apple in the way would make developers create better apps. I have seen the apps available on the dark side (jailbroken). The sightseeing looks like a summary of brain dead to me.

I hate Apple as a corporation. I like the ideas and the people and the platforms that make that corporation.

Cyril Godefroy: Interesting perspective. I disagree that it's easier to build a quality iPhone app than a quality Mac app. However I fully accept that I could simply be biased due to me much larger experience on the Mac side. But let me explain my position.

The API explosion you talk about is, to me, overall a helpful thing. The new APIs have mostly fallen into three categories. Some provide better ways of doing things than the old, where "better" means "less work for the programmer". Some provide new capabilities for things that programmers previously had to write for themselves. And some are just optional.

New technologies like QTKit and WebKit haven't made it harder to write apps, they've made it easier. You take what you need and leave the rest alone

The Mac side has a much richer GUI layer which in turn makes it possible to create good apps without spending a lot of time customizing the GUI. Some do, to be sure, but it's possible to make a high-quality Mac app without once doing any custom control or even any custom graphics besides your app icon. It seems that for a quality iPhone app it's pretty much necessary to have a good graphic designer deeply involved in the project.

The iPhone side is much more constrained as far as what the APIs offer and what the environment permits. I have a bunch of good iPhone app ideas which are all shot down by the iPhone sandbox or by Apple's restrictions on what you can or cannot write. Similar ideas on the Mac go right through.

Meanwhile the tools are vastly more difficult to work with. I can get a total newbie from zero to "hello world" in about thirty seconds on a Mac. How long does it take to do it on an iPhone? Hours, at least, plus they have to pony up a hundred bucks. Once you're up and running, the whole edit/compile/test cycle is slowed down enormously by the fact that the app has to be downloaded and installed onto the phone, then verified (ugh!) before anything can happen. Then the tools break all the time, wasting even more time.

Apple provides the simulator to get around some of this, but the simulator is about as good at simulating an iPhone as Microsoft Flight Simulator is at simulating an airplane. It's ok for certain situations but is mostly just a toy.

Finally you get to the fact that the hardware itself is much more limited. Many enjoy this aspect because of the challenge it presents, but the fact remains that it is a challenge. iPhone developers have to be much more mindful about memory, disk, and CPU consumption than Mac developers.

As for Apple being the gatekeeper, you're looking at the average quality, which is completely irrelevant. The cream rises to the top. If Apple getting out of the way means that there are twice as many good apps and a hundred times as many horrible ones, that's a huge win, not a loss.

I don't agree with your view about signing and submitting. That part has become quite easy: basicly you only need to read 2 documents that are linked on the same webinterface and follow the maybe 10 steps. That rearly is not bad considering you are dealing with a closed, codesigned platform.

Still you are very right about the review and the restriction part. Maybe apple will get that parts done too?

Not insane. It's a different platform and .01% of your development cycle vs. .0001%. That's assuming 5 hours vs. 5 minutes and a 2 month cycle. And you have to jump through similar hoops on Mac to get your code signed, so part of that is a wash. Let's not forget there are similar time sinks in Mac development too: Package Maker, Sparkle appcast setup, codesigning, Applescriptability...not trivial tasks. The fact is, there's unavoidable setup and friction to *any* platform development.

The figures above are assuming no trouble. I'm very sorry to hear that the development tools have given you trouble. That's not how it's supposed to work, and it's completely understandable you got frustrated.

Debugging on device is a hard problem to solve. I wish it worked 100% of the time, but that is unrealistic. I understand your situation and obviously that's unacceptable, but my situation has been different. Yes, sometimes debugging just craps out...but power cycles usually fix it. For me, the inconveniences have been fairly minor in exchange for RUNNING CODE ON MY PHONE! IT FITS IN MY POCKET AND TALKS TO SPACE! WEEEEE!



I think it is a big deal actually! It's a small Mac. It fits in your pocket. My code can be at people's fingertips 24 hours a day. Within 30 seconds of telling someone about my app, it can be on their phone. Amazing.



I agree the simulator needs some work. I have been fairly frustrated lately because most of my debug cycles have had to be on the device due to a completely lack of support for any iPod related APIs on the sim. Completely annoying. However, 90% of my work is done in the simulator the time to get a Hello World on the simulator is the same as on Mac.

Of course this is leagues better than development on other mobile platforms. And of course there is sometimes more friction than Mac development. Comparisons don't get us very far. It's about effort and reward. But for me (and the company I work for), the friction in development for iPhone is worth the end result.

I have no complaints about the development side and the tools since I haven't had as much trouble as you. I came into the process later than you - in fact, I read your original post from a year ago before I got started on my own process :) So the tools were much better by then and I've never had any trouble with signing and certificates so far. So I can't complain about that.

But I do agree with your comments about the app store process and especially the fact that while Apple makes reassuring noises, that they don't really look as if they intend to do anything much to make it easier on the developer.

My take is, they will do what they think will help sell more apps but they aren't really interested in letting go of the control they have at the moment. They really are not in this to make friends with developers :)

Speaking of friends, a high-profile developer, I forget who, said something like "Apple is my friend and you don't give up on your friends just because they don't do what you want them to do." I don't agree with that and think that's total crap :) Apple isn't our friend. They aren't in this to make friends. They are in a business and we should make our own decisions in a business-like fashion. If it isn't worth your while to develop for the iPhone, you shouldn't be doing it - friend or no friend. So I totally agree with your decision - not that you needed my agreement :)

Personally, I would have shifted to another platform if one was viable. Where I am, I can't sell apps over the Internet easily since receiving payment is always an issue. None of the other mobile platform app stores even support more than a few countries and for all it's vaunted "greatness" Android supports like 7 seven countries or so, most of them in Europe.

So I still stick with the iPhone platform but my personal development work for the platform has had a steep decline. Will I renew my developer account when it expires? I have no idea at the moment. But I certainly have lost the initial joy I felt in developing for the iPhone and that's all on Apple.

Sebastian: I don't understand why you say, "...considering you are dealing with a closed, codesigned platform." Why give it extra leeway because Apple deliberately crippled the platform? This makes no sense.

Zac White: Much of the Mac tasks you describe are unnecessary. I'm amazed that you include code signing in your list. Guess what, the Mac is not an iPhone! You don't need to code sign your apps for them to be able to run! Amazing! If you think that code signing is important and deserves much of your time for a Mac app then I'm afraid to say that you've been brainwashed by Apple's propaganda on the matter and need to reconsider.

As for the rest, most of it is optional as well. Package Maker? Come on, now. You ship a .zip. It takes fifteen seconds to script the creation of one. Done! Applescriptability? Unnecessary. Plenty of apps don't have it. Certainly no iPhone app is scriptable! Sparkle is optional as well, although I will concede that any serious effort ought to include it.

Your statement about unavoidable setup is true but completely glosses over the magnitude of it. The unavoidable setup on a Mac is minutes, on the iPhone it's hours at least. Furthermore, and this is what really gets my cheese, must of the unavoidable setup on the iPhone would completely disappear if Apple hadn't put a huge number of man-hours into making us put a huge number of man hours into it.

As for "supposed to work", great, I don't care how things are supposed to work, only how they do work. From everything I hear, your trouble-free existence is the exception, not the rule.

Why a 100% working debugger unrealistic? What is inherent about the mobile platform which makes this impossible?

Newsflash: the iPhone is a standard UNIX system. It can run sshd. It can run gdb. Put the two together and bang, 100% working debugger (except for gdb's crappiness, which is a separate issue). Oh wait, Apple doesn't let us do things like ssh in and run the debugger manually. You appear to have confused Apple's completely arbitrary restrictions on what you can do with a law of nature.

I guess I'm just harder to excite. Yeah, the idea of running code on a little pocket computer is pretty cool. But the cool factor evaporates completely once I have to beg a giant uncaring multinational corporation for permission to do so, and then jump through dozens of pointless hoops to make it happen. And then once I succeed, I'm stuck in a sandbox and can't do anything that's actually interesting! Nope, no cool factor there.

I think comparisons get us plenty far. Yes, the iPhone is much better than many other mobile platforms, and much worse than the Mac. From this ordering, you seem to draw the conclusion that "comparisons don't get us very far". This makes no sense to me. The logical conclusion is to develop on the Mac!

You're of course absolutely right that it's ultimately about effort and reward. But the fact is that the iPhone simply does not have reward proportionate to its difficulty for most. You may be an exception to that rule (although have you put similar effort into the Mac?) but that doesn't disprove my assessment of the overall probability.

It's interesting to see how your perspective as a Mac developer makes the iPhone look unattractive. I can fully appreciate it.

I on the other hand develop J2EE apps for a living, and compared to that developing for the iPhone is a joy.

One thing that has always held me back from developing Mac Apps, how do you handle the payment/serial number/validation side of things easily and effectively? This to me is the biggest plus of the app store. I don't have to deal with customer payments, I just get paid.

Hi Mike,

It worries me that a handful of extremely talented developers are stepping away from the iPhone as a viable platform -- I really hope it doesn't pick up any kind of critical mass.

As an iPhone user, all the great applications I use on a daily basis are generally from developers who have been working with Cocoa *much* longer than the iPhone's been around. If these developers are no longer excited by the platform, the quality of applications at the top end of the market goes down.

And as an iPhone developer, I get a lot of technical insight from people such as yourself, Matt Gallagher, Bill Bumgarner etc. If these developers turn away, there's going to be less thought-provoking discussion around iPhone development. No-one will push the SDKs beyond what Apple intended them to do, so all we'll get is cookie-cutter development, with no-one capable of bringing new ideas to the table.

My personal choice is to continue developing for the iPhone. It still excites me, I enjoy the commercial development side of things & the tools are great (it surprised me to hear you've had so many problems with them). That being said, I don't disagree with any of the issues you want fixed -- I want those changes too.


Cheers,

Nathan de Vries

Russel Ivanovic: eSellerate provides a completely integrated payment/licensing solution. It's not 100% turnkey but it's close. Having dealt with both, I can state that getting up and running with eSellerate is vastly easier than getting up and running with the App Store, and at the end of the day eSellerate skims off less than half of the revenue than the App Store. I have no experience with them in this millenium but Kagi is similar.

This is by no means the only way to do things. For example, the combination of Potion Store, Aquatic Prime, and either Google Checkout or PayPal will duplicate the Kagi/eSellerate experience but give you more control and cost you even less.

I can see how it may look daunting from afar, but I can assure you that it's a lot easier than digging up an entering all the crazy information that the App Store demands of you.

Nathan de Vries: I completely sympathize with your worry. At this point, I'm pretty much Just Another iPhone User, and I want good apps too! On the other hand, we're already not getting very many of them. There's very little that I wish I could have that isn't blocked or forbidden by Apple. Ultimately, having enough people leave is the only way to actually get Apple to change. The way things are right now, they have no incentive to actually improve things. They have developers pounding on the doors to get in. They have 50,000, 65,000, 75,000 apps to trumpet in their ads and at their speeches. The current state of affairs moves phones and pods, and that's all they care about. If this really gains critical mass, then maybe Apple will wake up and start paying attention and start making substantive improvements, and at that point we'll really see some good apps.

As for technical insight, certainly you've never gotten any real iPhone-specific insight from me, because I really never got that deep into it. Anything you may have seen from me was just Mac stuff that translates over. I suspect the same is true of Bumgarner, and many others too.

Just out of curiosity, what's your development background? I ask because in my experience, most people who think that Xcode is a wonderful paradise tend to have Windows programming backgrounds, and most people who hate it (like me) are old-school Mac types who still remember CodeWarrior back when it was good. Just wondering if that holds true, not trying to pass judgement.

Mike Ash: LOL. Not sure about Nathan, but I'm certainly from a Windows background and I do appreciate the tools in XCode. But then again, I don't think it's better than anything I've had in Windows. I used to be a Delphi developer and I still like the Delphi tools and how they work together over XCode. But for C-variant coding, I do think XCode is much better over Visual Studio, which tended not to be very visual at all :) (Disclaimer: I haven't used Visual Studio in years but am now getting back to it again funnily enough after I'd given up Windows ... :p)

mikeash: My professional background is web development using Ruby, on OS X via Textmate. I'd never done commercial development in C/C++/Objective C, but knew the basics either through dabbling or university.

While I would never describe Xcode as "paradise", I do think it's highly assistive in bringing developers like myself across to Objective-C and C from higher level "scripting" languages like Ruby. Despite Mac OS being my personal and professional platform choice, I'd never had as much drive to "scratch my own itch" with desktop applications as I've had with mobile applications. For the most part, Xcode has made the transition easier for me.

As an example, gdb on its' own would not compete with something like ruby-debug, but Xcode's gdb integration is very good (both on the device and in the simulator). Likewise for Instruments, you don't need to be a rocket scientist to make drastic improvements to the performance of an application. I'm not sold on IB, and resolving SCM conflicts on XML configuration files is a PITA, but other than that it's mostly been smooth sailing.

One element of my past I should probably admit to is working for a company that was developing J2ME & Symbian applications, which might explain why I'm still quite positive about Apple's platform :-). At the time I was working as the lead server engineer, and wanted nothing to do with mobile development (other than feeding them any web APIs they needed). I was at WWDC when the SDK was released, and immediately transitioned to doing commercial iPhone development. My web background comes in handy if the projects I'm working on need some kind of web service, or for any web-specific work that comes up.


Cheers,

Nathan de Vries

For what it's worth, I used CodeWarrior from Gold 5 or so until Pro 9. While it was a good environment, I greatly prefer the recent releases of Xcode.

Nathan de Vries: How funny! The parts of Xcode you like are the parts I dislike, and vice versa.

Xcode's debugger is a source of constant hate for me. It's buggy and slow. I can't tell you how many times I've spent carefully working an app into reproducing a tricky bug only to have Xcode decide that it hasn't locked up the debugger in a while and it's overdue to do it again. All of Xcode's data formatters and inspectors are colossally unreliable because gdb is a pile of crap and can't get ObjC information from the debugged process if some unrelated thread happens to be in the middle of various memory management or runtime functions, and Xcode's front-end can't deal with this failure and will just explode. Overall, I find the Xcode debugger to be on average barely an improvement over command-line gdb (and indeed I spend most of my Xcode debugging time in the debugger console) and frequently it's actually much worse. The only thing it provides that I actively like is automatically showing what line of code I'm on in the editor. Otherwise I can't think of a single compelling advantage over command line gdb.

Likewise, Instruments is a giant pile of junk. In short, it seems like it was built for the express purpose of producing really cool looking WWDC demos. It's slow and unreliable. The all-in-one-window GUI guarantees that every display panel is either too large or too small. The CPU profiling tools included with Instruments are utterly worthless, and it's a crime that Apple is killing off Shark in favor of them. I keep waiting for Apple to realize that they're pursuing completely the wrong approach when it comes to Instruments and nuke it and start over, but it increasingly like they think they're actually doing things the right way there.

On the other hand, Interface Builder is pretty good, and sure beats coding GUIs by hand. (This advantage may be significantly reduced on the iPhone, though, which could be behind our differing opinions there.) Sucks pretty hard with SCM conflicts, that's for sure, but in practice that's an extremely rare event for me.

I agree with most of your points to differing extents, but I do not reach the same conclusion of abandoning the platform.

I guess I start with the idea for the app first. Then try to think where it makes most sense. I also consider where I will enjoy working on it. Then I go back and reevaluate and feedback on my own ideas a lot. I must admit, the iPhone is such an exciting platform as a user that it biases my creative juices toward it.

So my current project started as a mac idea. I then convinced myself I makes a lot of sense as an iPhone app. Not so much for technical reasons, but from the marketing perspective. I still want it to live on the mac as well. I also have thought of the possibility of a windows version, but when I think of supporting all that sea of different hardware specs... well that thought never lasts long.

I have been lucky so far not to encounter any show stopping issues like the debugger going bye bye for a month. As for the pain of dealing with the store... It's a pain, but I know I can handle it.

The final issue is the possibility of Apple rejecting me. I have always been more concerned with working on a project for ages and then after going to the market, getting sued for infringing on some stupid patent and getting blown out of the water for that. I don't know, bad things can always happen. I try to stay out of trouble and have faith that things will work out.

People seem to spend so much time comparing the iPhone to a Mac, Apple should consider it a compliment. The truth is only a couple years ago your choices between cell phone SDKs were vomit or diarrhea. Now you've got a "phone" that can pretty much replace most netbooks, and honestly based on the amount of things available on the App Store compared to the actual usability of trying to run software on a slow/high dpi netbook I bet it's more productive.

Maybe it's not your perfect incarnation of a phone, but for me it's hard to imagine life without it and many of the app store apps I use every single day.

As a phone, I'll compare it to my other phones. It's quite good at this.

As a development platform, I'll compare it to my other development platforms. It stinks at this.

There's no reason to conflate the two and restrict the development platform comparison to other smartphones as far as I can see, other than to deflect attention away from its deficiencies.

"It's cripped by the small number of quality third-party applications available"

I understand your greater point, but this is bullshit. Yes, 99 percent of the apps may be junk, but the 1 percent that aren't are fantastic. Taking notes, running my life, listening to a major league baseball game, there are great apps for just about anything.

It's too bad you've decided against the platform. But luckily, at this point, enough are sticking around to put up great products.

The official AIM app is the one that always gets me. It's a giant pile of crap. Others may be better, but last I looked none offered push notifications for more than an hour after quitting the app, making them useless to me. Where are all the great IM apps? So far, there aren't any for what I want.

Another thing I would like to have is an app that will fetch weather radar in a reliable and persistent fashion on slow networks. Many weather radar apps exist, but all are junk, vastly inferior to simply visiting wunderground.com.

I use Twitteriffic a lot and it's mostly a good app, but it falls down constantly on EDGE because it's intolerant of slow networks. I get the distinct impression that Apple never tests anything on EDGE, because most apps which use the internet don't work well on it.

Most of what I'd really like to have is forbidden. I want an app that automatically reconfigures the phone depending on where I am, but that would require background processes and access to system settings. I want an app that uses vertical velocity information from the GPS chip to help with flying, but Apple's crappy GPS API doesn't provide vertical velocity. I want to be able to retrieve photos over wifi so I don't have to fetch the phone and plug it in to my computer every time I come home with pictures, but again that would require background processes and full access to the photo library. What's left, quite frankly, just is not very compelling. Push AIM is cool, but there's very little else that I would really miss if my phone suddenly were stuck back in the 1.x days of only having Apple's apps.

One final note: "listening to a major league baseball game" is not a point for apps, it's a point against Mobile Safari. On a real computer you can do that stuff in your browser. Only because Mobile Safari supports so few streaming media options and is completely non-extensible do you require a separate application for it on the iPhone.

Mike, I'd love to argue with you (and am doing well enough with iPhone App development on average), but last night my latest build wouldn't install with a 0xE800800E error, the Touch is stuck on the connect-to-iTunes display, and iTunes says it can't connect to the Touch when I plug it in. Oy!

I left the ACN (Apple Consultants Network) after 6 years because Apple has kept upping the membership price (and also added the requirement for extra liability insurance) without adding any other enhancements. The support ACN members get from Apple is almost non-existant. It is just not worth being in the ACN anymore. I will continue to run my consulting business, just without Apple. My customers really don't care if I use Apple's logo on my website or not!

I think the problems of Apple kneeing developers is just extension of the way they treat everyone associated with them. I guess this is the result of Apple's growth - cockiness.

Not even Microsoft treated developers the way Apple has. I was very close to joining the iPhone developer program as I had a few good ideas for some iPhone apps, but have decided to put my efforts elsewhere. Mostly due to the horror stories I have seen.

I have customers asking me for free upgrades to a product they paid $0.99 for... gotta be fucking kidding me.

Agreed. I've by now completely given up on iPhone as a platform to work as an independent developer.

The hype machine is going strong, however, and I'll keep my dev membership solely to work as a subcontractor developing enterprise apps. When you're billing by the hour, the setup hurdles don't bother as much (and so far, my clients have been understanding of that).

The iPhone was what introduced me to the Mac development platform (I've been a Mac user for a while, but didn't develop anything). I'm now seriously considering developing for the real Mac, specially with the sexy new API's in Snow Leopard. I just *need* to develop for that.

Mike

I've not tried developing for the iPhone so far and I've never been tempted yet - I've taken on enough to develop my own app on the Mac.

From the sounds of things, I've saved myself from pulling my hair out. Your development experience sounds hellish.

Thanks for telling us all about your experience and saving other people from having the same problems and wasting their time developing an app that they need to pay Apple for every year.

Facebooklicious (.com) spams again! Keep it up, guys, one of these days I'll totally fail to notice and delete the post.

what do u think of tools such as widgetpad, and now, adobe's new flash pro thing?

Widgetpad is not interesting to me, being HTML/JavaScript and not, as far as I can see, giving anything like full access to native APIs. Might as well just make a web page.

Adobe's Flash thing is abstractly interesting in that it allows a whole bunch of existing code, and a whole bunch of people with existing skills, to suddenly move over with probably not a lot of pain. It's not very interesting to me personally, though.

Both of them are largely irrelevant to the problems with the iPhone development process. Every iPhone app, no matter how you create it, still has to go through provisioning/certificate hell, and still has to go through Apple's Kafka-inspired review process. It makes no difference whether you use Xcode or CS5 to create the binary.

I don't know, to me things don't seem so terribly dark. Each of us really only has their own anecdotal evidence on how well the SDK and the app store work.

When I first set up my own certificates etc over a year ago, it took me approximately one workday to get it right. If the tools available at that time had the sort of error reporting that today's tools have, it probably would have taken half that time. In either case, a big part of that time is just learning what the various things are. Apple would do all new devs a favor by providing a simple flowchart-style description of all the certificate stuff.

In any case, learning how to deal with the certificates etc is really a one-time cost. The terminology is unusual outside of mobile dev circles, and the workflow as laid out on the portal website is really non-obvious, but it's learnable. Now and then during the past year, when I've had a certificate expire or needed to regenerate a provisioning profile, I entered the portal website full of anticipatory dread; but each time, I had everything back in working order in less than 30 minutes. And just the other day, I dealt with all the certificates and provisioning for a new client, and it took maybe an hour. From my perspective, the certificate/provisioning process surely isn't hell, in fact it's less irritating than, say, my daily commute.

So the certificate stuff becomes less painful as you learn how to manage it, and the SDK really has dramatically improved its error reporting and project config for the certificates. What hasn't improved is the review process, which if anything has gotten slower (currently about 2 weeks, vs about 1 week when I started submitting apps). That is a shame, because it gives Apple and the iPhone platform a bad rap. OTOH, if a company lives or dies by whether its app is released on October 1 or October 15, then that company is doin' it wrong. IMHO. Yes, it's frustrating to toss things off into the void and not get any status updates on them, and it's maddening to have an app rejected for what you think are spurious reasons, but to me these small bads are heavily outweighed by the goods.

Experiences do seem to vary. I don't really know why. For me, an expired certificate or, more frequently, a spontaneously broken toolchain meant hours of new struggle.

Your "lives or dies" comment ignores the realities of software development. Critical bugs happen. They shouldn't, but they do. If you can't get timely fixes to your users, you could very well be screwed. Look at what happened to Twitterrific, which is by all indications an extremely professional product. Iconfactory got rescued because they're a huge name and Apple gave them a break, but you or I will have to suffer through the two week (or more) waiting period even if our users have an app that simply does not work. Wait until your customer base has spent two weeks (or two months!) sitting on an app that doesn't run anymore and see if you have any business left.

Apple would really do all new devs a favor by eliminating the pointless certificate nonsense and make it so that the flowchart for getting an app onto a device has a single entry: "Click Build & Run".

I have experienced some problems along the way, but overall things have been quite smooth. Setting up the profiles took a few hours the first time, following Apple guidelines to the letter, and ended up with a cryptic error message that luckily I was able to solve with the help of Google. From 2.0 the SDK has improved quite a bit with regards to the handling of the profiles, but I agree that if Apple really wanted, they could make the whole process of obtaining and installing the certificates a lot simpler. Then again, given how many developers are pounding at the doors to get in the App Store, it may be good for Apple to introduce these "complications". There are, what, 125 000 registered iPhone developers now? How big would that number be if everything was "click and run"? Anyhow, right now I spend a negligible amount of time managing certificates so that's not an issue at all for me.

With regards to the app review process, I guess I'm in the vast minority thinking that it's not that bad, actually. It is obvious that the review team is overloaded and Apple should hire more reviewers, but I think this is deliberate: the vast majority of Apps are rejected outright because of bugs, and Apple never intended the review process to be the QA and testing that the developer should have done thoroughly before submitting. A two week delay should act as an incentive for developers to test well, or risk getting delayed by two weeks. I know bugs slip into shipping products, in fact I'm speaking of experience here, with two app rejections because of totally trivial bugs that would have surfaced with a bit more testing. Am I angry at Apple for this additional 3-4 weeks delay? Not at all. Next time I will devote more time for testing. The iPhone still excites me, both as a device and as a development platform, even though I am aware of the limitations that prevent some really cool things now.

Now, with regards to bug fixes, I agree that they should be reviewed differently, especially for critical bugs. But is the App Store really worse than the alternatives out there, even for desktops? What is the average time it takes for iPhone users to get their updates installed in their machine vs. desktop Mac users? I don't know, but I don't think it's so black and white. Sure, you can upload the fixed binary to your servers as soon as it is ready, but what about the updating process for the users? Desktop developers, to my understanding, have to handle checking for updates by themselves whereas the App Store makes all that totally automatic for the developer.

In the end, as is the case with all platforms, the iPhone and the App Store have their strengths and weaknesses. For me, the strengths so far greatly outweigh the weaknesses, but for some others the equation is different.

The bug fix situation on the desktop is vastly better, absolutely no question about it. Adding Sparkle to your application is trivial. Meanwhile, when you fix a critical bug, you can ship it immediately. Users may not find out about it immediately if they aren't checking for updates, but the first thing a typical user does when he encounters a critical bug is check for an update.

Your discussion about how many developers there are already is spot on. Apple has zero incentive to improve anything about the process as long as the iPhone is the hottest platform going.

Ok, I have no experience of desktop Cocoa so I didn't know what kind of solutions exist there. You mentioned Sparkle, which seems like a good solution, so the burden for providing the update mechanism is not that big, although it is still bigger than in the App Store. But probably the ability to get critical updates immediately wins out in the end.

Although there are a great number of developer on the iPhone, I disagree that Apple has zero incentive to improve the process, after all they have made some improvements along the way already. And I'm pretty sure Apple knows they can't ignore the Android as a competing platform for mobile developers, so they really have to improve to stay ahead in the game. Right now, iPhone App Store is where the money is, but from the figures I've seen the ratio between turnover and installed base is not that different between iPhone and Android. When more and more Android handsets are released, things will balance out. And at the end of the day, developrs go to where the money is.

I disagree that the burden for updates is bigger on the desktop. It maybe true if you only post 2-3 updates for your application over its lifetime, but not true after that. Every time you post an update to the App Store you have to go through the craziness of making a special build of your application (and jumping through the completely insane and unsupported hoops required to actually test that build, if you want to do things properly) followed by the craziness of iTunes Connect. The per-update burden of Sparkle is vastly lower, so over time it wins.

Of course, most iPhone apps appear to be throwaways that get few or no updates....

You're absolutely right that most iPhone apps are just thrown together quickly with no regard to maintenance. I'm still not convinced about the updating, though... I don't really see the need to test the distribution build, it's exactly the same build as release build, just with a distribution profile for code signing instead of a development profile, and maybe in some cases a different bundle identifier. I think it is perfectly adequate to do the testing using the release build. Then when you're ready, you just zip the built binary and upload it, there are not that many clicks to it, really. Unless your App takes an extraordinarily long time to compile, it takes less than 10 minutes to compile the update for distribution, zip the binary, click through the iTunes Connect pages and update the necessary information and upload the binary. Then you must wait for the review, which is where the App Store clearly loses. Anyway, I'm not here to debate or argue with you, I just think you've run into much more problems than a typical iPhone developer, at least if they started later than you did.

The need to test the distribution build should be obvious. The Apple-Approved way to make them is by using a different build style. What else is different between the build styles? What switches have you flipped or options have you added to the development style that didn't get applied to the distribution style?

You might say, "Well don't do that!" And of course that's the goal. But mistakes get made. That's what testing is for, as a safety net for your mistakes.

Of course nobody actually tests their distribution builds. But that's not because it's reasonable not to test them. It's completely unreasonable. Nobody tests them because Apple has made it so unreasonably difficult to do so.

As for more problems than a typical iPhone developer, I don't think there is such a beast. For every person like yourself who has had it easy and can't understand why I have so much trouble, there's another person who nods in agreement at everything I say. I have no idea what makes the difference (I suspect that more of it is about perspective, and that our experiences are closer than we think) but the fact is that there are wildly varying experiences, and I see no evidence that mine is by any means an outlier.

Regarding the differences between the release and distribution builds, as per Apple's own documentation you duplicate the "Release" target, rename it distribution, then change the code signing to use distribution profile and, if needed, change the bundle identifier. So, unless something fishy goes on somewhere, the result should be exactly identical to the release build, only that it has been code signed with a different profile. As far as I'm concerned, if the distribution build has bugs that are not in my release build, that is something Apple needs to fix. I'm not qualified to tamper with the code signing anyway.

It may well be that we have just a different perspective, or that I've been lucky so far, or that you were very unlucky. And yes, I understand that the limitations of the iPhone platform are irritating compared to the desktop OS X. I can, for the most part, understand why Apple has put these limitations in place. And although I may be just naive, I believe that they have a long term plan in motion. Apple is a business, and they don't want to reveal all their cards at once, no matter how frustrating that is to customers and developers. In a way you are absolutely right in saying that they have little reason to change when it seems everything is going the way they want, although I'd say that they are sticking to their plans most of the time, and make whatever adjustments are needed when needed, not before.

It'd be interesting to know what percentage of developers renew their iPhone developer program membership, that would tell quite brutally what developers think about the platform. If a large percentage does not renew, I think that will ring some bells at Apple, even if new devs keep pouring in.

Do you create a new distribution build style every time you make one, deleting the old one, or do you reuse the original one? The natural thing to do is to reuse the original, and this will be prone to errors over time. You're right that the first build has no reason not to be identical to the one you tested, but what about update #10?

I understand completely why Apple put all of these limitations in place. I'm sure that everything they're doing furthers Apple's goals, or at least that they think they do. The trouble is, I'm not Apple. My goals aren't aligned with Apple's goals. It's all well and good for them that they're doing what they want, and I can hardly expect them to change, but I don't have to like it when they're behaving in a manner which is so clearly contrary to what I want.

Regarding renewals, as long as your apps are bringing in over $99/year then there's no reason not to renew even if you've completely ceased development. I just renewed mine a couple of months ago even though I have absolutely no intention of doing any more iPhone development.

Ok, now I get your point about the different build targets. Yeah, the right way would be to create a new target every time, or at least every time you change some build settings in your release target. So, at least every time you change the target OS version you should also update the distribution target, and possibly more often than that if you twiddle with the other settings.

Again we agree, the real question each developer has to ask and answer is if working on the iPhone platform is good for him/her. It certainly is not for everybody, for a great number of reasons. In fact, if you take all the developers in the world, those willing to work on the iPhone are a great minority. I have no clue how many developers there are out there, but the number must be at least a hundredfold the number of iPhone developers, and perhaps even much greater than that.

By the way, do you think it is a goal of Apple to use the iPhone as a gateway to desktop OS X development? I can't come to any other conclusion, why else wouldn't Apple provide practically ANY tools in the iPhone SDK for syncing data with a desktop? It would be trivial for them to implement a data sync framework with a OS X part and an iPhone part, but they've chosen not to do that and I believe that's because they want iPhone developers also to venture on to the desktop side of things. The (possibly) coming tablet with more complex Apps is one step further in that direction, at least I believe it will be.

I don't think Apple's goal is anything so complicated. I don't think they're capable of selectively providing capabilities in order to push developers toward another platform as you propose, and even if they were, I don't think they'd want to.

The iPhone platform (including iPod Touch users) already has more users than the Mac platform. So far, the price difference means that the Mac is still making more money for Apple, but that probably won't last. Apple has no reason to make iPhone development more difficult than it needs to be just to entice developers onto the Mac.

No, I think their goals are much more mundane: Apple loves control. They were forced to develop open platforms before in order to get developers, but now they've lucked into a situations where not only are open platforms not expected, but the existing stuff is so horrible that they can provide a completely locked down and controlled platform and people will still thank them for providing something that's so nice compared to the rest! The crypto and lockdowns exist pretty much for their own sake, so that Apple, not users, controls the platform. Plus, who can say no to skimming 30% of every third-party developer's revenue? Steve must adore the fact that he's managed to convince tens of thousands of developers that all of this stuff is a good deal.

On the tools side, that's just Apple's general organizational incompetence. Xcode has been a fairly poor development environment since long before it was even called Xcode. It's much improved in the past few years, but the iPhone side is more or less starting over. Combine this with the locked down nature of the platform, meaning that third-party developers basically can't provide any tools to improve the development experience, and you have the current situation without any actual ill intent.

Yes, iphone dev truly is awful, and to add insult to injury the codesigning shenanigans provide zero protection against piracy.

I'm not about to give it up, but reading this has inspired me to port my app to the mac.

It should be a pleasure.

Ta,
RF.

"and to add insult to injury the codesigning shenanigans provide zero protection against piracy. "

Can I get an AMEN brother!

Really interesting year ahead, how many people will actually shift to developing apps exclusively for android, and how many will stay as iPhone developers.

And more importantly, will consumers follow?

I'm not gonna renew my subscription too. I tried posting my iPad app twice. First time got rejected from an icon resolution issue which seems ok to me. So, I fixed it and resubmit now got rejected again coz my app is partially supported both orientations. Now this is silly. I want my app to be like that.. so what? don't bother thou. I'm not gonna fix it as you want and no more renew subscription.