There’s been a lot of discussion lately about the economics of developing iPhone apps for sale in the App Store. Craig Hockenberry, best known for his work on Twitterrific, attracted a lot of attention with his open letter to Steve Jobs in which he expressed concern over the proliferation of 99c apps in the top 100, and the difficulties that poses for established developers to turn a profit making more full-featured apps for iPhone.
My own view on this is that it mostly affects ‘smash and grab’ apps that depend on hype to survive, and the days of these apps are probably numbered anyway, once developers realize that the window of time they spend in the top 100 list is becoming more and more fleeting as the competition heats up. Planning on getting into the top 100 for any extended period of time is ultimately not a business model — it’s a quick money grab, and one that is fast losing its attractiveness. It wouldn’t matter how Apple determined the top 100, there would always be 100 happy developers, and 9900 (and counting) unhappy ones.
I suspect Hockenberry is hoping for some sort of system in which established companies like his own can divide up the top 100 amongst themselves, and the rest of the riff raff can fight it out in the gutters, but that would be just as unfair as the current system. The fact remains that there are only 100 places in the top 100, and many developers vying for them. Relying on the top 100 to keep your app afloat is doomed to failure in the long term; most apps — even well written ones — will never even see the top 100, because they fall outside the few mass-market categories of applications which have top 100 appeal.
There’s nothing new in this. The same situation exists on the Mac. If you are lucky, you may get featured on Apple’s downloads site, which can lead to a spike in sales, but in the longer term, you have to find other ways to get the word out. Apple can’t bring every good app to prominence for any extended period of time — there are far too many for that. Instead, developers have to look to traditional means of promoting themselves: Google Adwords, Search Engine Optimization (SEO), Blogging, Word of Mouth, etc.
This is all a rather prolonged introduction to what I really wanted to discuss: the cost of producing an iPhone app. Hockenberry suggested a 3 man month project would cost around $80k. Sounds like they are pretty comfortable down at the Icon Factory, because if I could earn $80k in 3 months I wouldn’t be complaining. But it does highlight that developing an iPhone app is not as trivial as you might think.
I think many would have the preconception that developing an iPhone app would be considerably easier than a Mac app. I was certainly of this mindset before I began developing on the iPhone. You don’t have to worry about things like cut-and-paste, undo, printing, managing menus etc. The interface of the iPhone is that much more sparse, so it must surely require considerably less code to develop an iPhone app as an equivalent Mac app, right?
Because we develop a Mac and iPhone version of Mental Case, we are probably in as good a position as any to evaluate this claim. To find out just how long an iPhone app is, I did a simple line count of the source code in our Mac and iPhone editions, and came to the simple conclusion that an iPhone app is half a Mac app. We have around 12000 lines of code (including empty lines) in Mental Case for iPhone, and about 25000 in the Mac version.
This analysis is very rough — for example, it ignores that a lot of a Cocoa application resides in special archives called NIB files — but it is probably a reasonable rule of thumb. So an iPhone app is far from a trivial undertaking, and this certainly correlates with out own experience developing Mental Case 2.0 for iPhone over the last few months.
It’s also worth pointing out that the apps that have the most thought put into them often appear to be the simplest, and the natural assumption is that they were also simple to develop. My experience is that the opposite is true: if you see an app with pages of buttons and configuration options, the developer has put very little thought into the UI, and the application was probably actually much simpler to develop than one with a sparse and simple interface. When it comes to iPhone apps — and Mac apps for that matter — the best ones are 90% under water.