How the iPhone helped developers
One of the things I mentioned in my previous post on the appeal of the iPhone to users was the app store, with its quarter million apps (and counting). Of course, most of those apps are really, really bad (just search for “fart” on the app store; or rather: don’t). But with so many apps from so many developers, there is inevitably a huge bunch of great, quality apps too.
The reason for this is simple: Apple revolutionised the way developers think about mobile, how they build their mobile apps and how they sell them.
When the iPhone launched, there was no app store. The iPhone shipped with a dozen and a half or so apps from Apple, and that was it. The Safari web browser was the window through which you could access additional functionality. Of course, this was somewhat frustrating to the first generation of iPhone users (although I suspect most early adopters didn’t mind too much because their phone just worked so much better for so many other things than anything that came before).
In hindsight, the fact that Apple focused only on establishing their market share during that first year helped kick off the app store with a bang when it launched in mid-2008 (a mere two years and around five billion downloads ago). Apple wasn’t distracted by trying to figure out how to sell apps and support developers when they launched, they only had to focused on selling the idea of the iPhone to people who had never experienced anything like it. The result of this was that by the time the app store launched on 11 July 2008, the iPhone already had 6 million users who loved their phones and were hungry for more.
The thing is, software developers only get off their Star Trek watching, Red Bull drinking butts late at night to build cool things if they believe that (a) there is an audience for their applications, (b) that it will be really easy for users to find and buy your product, ( c) that it is easy to develop powerful applications, (d) that you can easily distribute your product and get your fair share of the revenue and (e) that it is cheap to develop applications.
Apple rose to the challenge posed by these developer requirements. By building up a user base before launching the developer program which feeds into the app store, there was a sizeable audience already. By putting the app store on the home screen of the iPhone, users instantly know about the app store, they don’t have to stumble across a place to buy apps on the Internet through word of mouth or a concerted effort. But it’s not enough to have users, those users also need to have and have an easy way to spend it. By linking the app store with Apple’s huge existing iTunes store user base, most iPhone users already had accounts with linked credit cards through which they could download or buy apps from the app store. (And if you don’t have an account, you can even create one within a few minutes when you first fire up the app store.) It’s also important to note that Apple’s customers tend to have more money than your average cellphone user by mere virtue that all of Apple’s innovation and design style comes with a price tag.
Apple also integrated their iPhone development tools with their existing standard Mac development software. So it wasn’t difficult at all for Mac developers to make the jump to iPhone development. (Most early iPhone developers like Pangea and Freeverse had a long history of Mac software development.) They didn’t have to learn new languages or new tools.
Also, virtually all software for cellphones before the iPhone was written in Java MicroEdition (or J2ME, as it was then known). The idea behind Java ME was that you could write software that ran on nearly all cellphones. As is so often the case in the real world however, this noble idea didn’t translate all that well into reality. Since Java ME set out to be a lowest common denominator environment, the programs you could write were very basic and rather bland, and couldn’t take advantage of many of the advanced features of different makes and models of phones. So various “add-ons” were created which allowed Java ME programs to access useful features like SMS, the GPS, the mobile web, data connections, the camera and so forth. While you could now, in theory, write much more powerful applications, it also meant that suddenly you had to figure out on what specific phone model you were running and what that phone supported. What a headache! Also, even if a phone allowed developers to access a certain feature, there are no guarantees that Nokia and Samsung (for example) would implement it in the same way. (And quite often, the manufacturers would even implement some features differently among their own models.)
If this wasn’t bad enough, the basic hardware on phones differs significantly. Some phones have tiny memory, virtually no storage for files, slow processors and tiny screens. Other phones have a lot of memory, file storage, fast processors and higher resolution screens. Most phones lie somewhere in-between. If this sounds like a mess, it’s because it is! If you wanted to develop on software that ran on a few hundred devices, you had to write and compile dozens of different versions of your program.
In the world before the iPhone, some manufacturers like Nokia, Motorola and Samsung had very large market shares. Nokia at some stage manufactured more than half of all phones on the market. However, that market share was split into dozens if not hundreds of different models with different features. Then Apple came along, launching a single model phone with a single, fixed set of features. Absolute lunacy, commentators from the sidelines said! You’ll never compete with the hundreds of models from your competitors!
But what seemed like lunacy to tech commentators was absolute bliss for developers who were so used to the hurdles of developing applications for hundreds of different phones. There was only one set of well-defined features to code for, you only had to test applications on one emulator that was tightly linked to your development environment, and only had to test your app on one real iPhone to know with near certainty that your app will run on all iPhones.
In the two years since then, Apple has upgraded the iPhone twice (first with their 3G model and then the 3GS). While doing that, they’ve taken great care not to unnecessarily introduce model-specific features. So even in the two years since then, iPhone development is still far and away the simplest, least “headachy” of all the platforms.
The first real fragmentation (geek speak for introducing a model which does have significantly different features) will probably occur with the announcement and possible introduction of the fourth generation iPhone next month. Specifically, the new iPhone will almost certainly have an incredibly high-resolution screen which will be capable of showing four times the level of detail of existing iPhone screens. This means that developers need to go through a tiny bit of extra trouble if they want to take full advantage of the new resolution. But since Apple is well aware of the fact that their restraint on major hardware upgrades has worked for them so far by limiting fragmentation, and since they certainly don’t want to undo that advantage, it is virtually certain that all of the existing applications will work out of the box even on the newest, coolest model. Albeit with graphics that are a little bit less crisp than the new screen would be capable of; essentially the apps will look exactly the same as they do on older devices.
Apart from great developer tools, Apple also made it very easy for developers to distribute applications. You merely upload them through the Internet to Apple. Apple will then test your applications to make sure they don’t contain any obviously broken code, and to make sure that your app doesn’t do anything that would be harmful to users (like sending a copy of your emails to some dodgy server). Once Apple has approved your app, they load it onto the app store, and you’re good to go. Users will be able to find your app, tell their friends, and hopefully you’ll make a truckload of money.
When it comes to earning money from your applications, Apple made it super-straightforward for developers: no complicated, tiered revenue share models, minimum sales or revenue thresholds. Apple will keep 30% of any money a developer makes to cover their costs of operating the app store (which are significantly higher than people think!), and gives 70% back to developers by paying it into the developer’s bank account once a month. If an application is given away for free, Apple doesn’t charge developers anything even though it does cost Apple quite a bit of money to look at and approve and distribute the free application. If you add features to your app, you just upload the new version to Apple (at no cost), and once the new version appears on the app store, users who already own the app can update it for free. You can change the price of your app to nearly anything you want it to be, from free to hundreds of dollars.
All of this power and simplicity comes at the very low price of a developer subscription with Apple for $99 per year. To put that into perspective: if you can find a mere 130 or so users (out of the hundred million or so who own iPhone OS devices) willing to buy your app, you make that back. (It’s worth mentioning that the iPhone development tools only run on a Mac. So if you’re a Windows/Linux PC person, you’ll need to also buy a Mac. As a Mac-fan, I don’t necessarily see that as punishment.)
Of course, all of this sounds great on paper. Obviously developers didn’t line up around the block to sign up for iPhone development the day Apple announced the developer tools; most developers are often risk-averse to trying out “unproven” business models. But a few developers writing apps over weekends and during their spare time became so rich and successful during the first months of the app store that stories obviously started to spread, and more and more developers gave iPhone development a shot.
Today, tens of thousands of enthusiastic and skilled developers build and sell applications either full-time or part-time. This enthusiasm, coupled with the ease of distribution and the potential to make money from a hundred million users has even changed the gaming industry. Big names like EA, Activision, Rockstar, Ubisoft, Sega and Square Enix have released games on the iPhone. Today, the iPhone games market in the US generates nearly double the revenue of the PSP. Those kind of numbers make even big developers and publishers sit up and take notice.
The last revolution the iPhone caused for developers is that the app store allows a single developer working in his spare time to compete with massive publishers like EA. Apple features apps from small teams and big publishers in equal measure, all developers have to follow the same processes to have their applications loaded onto the app store, and ultimately it’s up to users to decide whether they like it or not. Before the app store, it took a lot of time and energy (and money) for an indie developer to find a publisher with the right connections to have their application published on a big network portal (like Vodafone Live) or one of the many off-deck (non-operator) content portals. Even then, promotion was often a major issue.
The app store is full of remarkable success stories of indie developers hitting the big time. Doodle Jump has sold millions of copies at $0.99 and was mentioned on The Big Bang Theory show on TV; it was produced by the Pusenjak from Croatia. Loren Brichter from Atebits developed the beautiful twitter client Tweetie and became so successful that he recently sold his company to twitter, which re-released Tweetie as the free, official twitter client for iPhone.
Success if by no means a sure bet on the app store, but it’s stories like these, coupled with the ease of iPhone development that keeps the app store dream alive for countless developers who feel stifled in corporate cubicles.
In the next instalment of my series on the iPhone revolution, I’ll take a look at how the cellphone networks have been affected by the arrival of that magical device.