Web Directions Year round learning for product, design and engineering professionals

As did many others, I greeted the arrival of version 2.0 of the iPhone operating system no little enthusiasm. To be fair, in the world of endless betas that is the web these days, as a version 1 the iPhone OS was pretty amazing. But what would Apple do with Safari? What aspects of CSS3 and experimental CSS support that we’ve been seeing in Webkit nightlies, and even Safari 3 for Mac and Windows would we see in mobile Safari 2.0? All these really interested me.

Seemingly putting me in a minority, one area I really wasn’t particularly enthused about was that of native apps for the iPhone, and iPod Touch. To me it seemed a pretty pointless step right from the get go – especially after a minor iPhone OS update last year allowed developers to make icons for their web based apps that could be added to the home screen of an iPhone. In essence, web apps became native, first class apps on the iPhone.

But the clamor for a software development kit (SDK) was loud, and the rejoicing great, when Apple announced that native app development support was forthcoming.

The first fruits of the labors of the developers who signed (and ponied) up, and were accepted into the iPhone developer program recently turned up in the new App Store (the only official way to get iPhone native apps – more on that below). And the results? Well, much excitement from the assembled blogosphere, but in my not so humble opinion, pretty much nothing to write home about. Well, except for Apple’s own remote app, which is frankly amazing [1]. In fairness, I’ve not tried any of the non-free applications (who doesn’t want to try before they buy), but I’m seriously underwhelmed by much of what I’ve tried.

This is not to say that the apps are pointless, many are very useful. But my overall take away from the apps I’ve seen is that, well, on the whole there’s little if any reason why most of these couldn’t be done with HTML/CSS/Javascript (I’ll get back to why building web apps instead of “native” apps would be of more than little benefit to developers in a moment). I can’t see at all why developers have waited a year to release applications that could have been developed and released in a matter of weeks, or even less, as web apps (and I’m talking from experience having done some work with webapps for the iPhone), a year ago.

In the meantime, Apple has invested enormous resources into delivering an SDK and App Store. Developers have learned new languages, development tools, and platforms. And yet, in all, it seems a great leap backwards, in several ways.

Perhaps my biggest disappointment is that so few of these applications take advantage of the connectedness and “always on” nature of the iPhone (and to a lesser extent the iPod Touch). They tend to use local storage of data, and do very little tapping into the shared resources and intelligence of the web. A perfect example is a $10 cocktail application, with a searchable database of cocktail recipes. This is just a client side, CocoaTouch version of the online database. Why all the resources poured into developing the iPhone app, when a little bit of CSS would probably have been enough to have a native version a year ago! [2]

In conception most native apps seem on the whole to be just scaled down desktop apps, living in their own isolated world. I wonder how much of this is because the developers of these apps are more likely to come from the desktop world, being Mac application developers, and how much this is a function of the toolsets being used – after all, CocaoTouch is a subset of Cocoa, itself a desktop application development platform.

Now, in fairness, only native apps get access to things like your location, the camera, your photos, and so on, which means certain types of application, for example a photoblogging application which uploads photos as you take them, or applications that rely on knowing your position, are restricted to being native apps at this stage. But most apps in the App Store don’t tap into these things.

And there’s little reason why this sort of functionality couldn’t be exposed by Apple using a Javascript API so that applications built using CSS, HTML and Javascript couldn’t take advantage of them as well (subject to addressing issues around privacy and security, you don’t want arbitrary web pages accessing your location data, photos and the like).

But, you might be thinking, “isn’t this some pointless little language war?” Does it really matter whether apps for the iPhone are developed using Cocoa or JavaScript/CSS/HTML? I’d argue that it does matter. The web apps approach to development brings with it significant practical advantages to developers, users, and Apple as well.

First up, there would be an order of magnitude more web application developers than Cocoa developers. By privileging CocoaTouch apps over web applications, Apple gains unique applications (all these native apps will need to be rewritten for Widows Mobile, Nokia devices, the upcoming Android platform, PSP, and other platforms). But everyone else, including developers lose out. As users, there’s less choice. As developers, you need to rewrite your apps for other platforms, as well as, of course, for the platform that really matters – the web.

But that’s not the end of the problems. As noted by many developers, debugging CocoaTouch applications is hard. Compare this with the debugging tools and resources available for web developers. Then, there’s the dearth of information, tips, gotchas, and so on that developers share with one another on forums, blogs and the like, and which are a lifesaver for many developers, whatever the platform or language or framework they use – these just aren’t out there for iPhone developers right now not simply because it’s such a new platform, but because the terms and conditions of being a developer restrict this. In fact, established publishers have had a difficult time even putting together books on developing native apps for this very reason.

These are big problems for developers, and ultimately users, as they will impact on the quality, and number, of applications available for no little time.

But it doesn’t get any better. There is but a single way to distribute native applications for the iPhone – Apple’s App Store. App Store is only open to registered developers, who both pay for the privilege of being a developer (an ongoing fee, presently $99 a year), and who are selected by Apple, according to whatever criteria Apple wishes to use. Apple are definitely gatekeepers here, and can arbitrarily exclude anyone from being a developer. Now, Apple are quite entitled to do this with their platform, but it should give anyone pause as a developer wishing to be involved – afterall, your professional and business future is entirely dependent on a third party’s arbitrary decisions, over which you have no right of appeal.

Again, this is not just a problem for developers – as a user, it’s your problem too. Why? Well, not only does it restrict the amount of innovation of the platform, but more directly, because software has bugs. That’s why you see so many x.x.1 releases of software. As a developer, this is very frustrating, but at least you can auto update your application, or post a fix and notify your users as soon as the fix is done. Not so with the App Store. You post a fix. Apple decides when this is pushed out to users. If you’ve paid for an app (and recall, you can’t demo an app, unless the developer has two separate versions, a free and a paid one), then you need to wait for the fix. If you are a developer, you wait anxiously, as your competitors get an hour, a day, or whatever, headstart while you wait for your fix to be available.

With a web based application, you have zero config updates – users need to do precisely nothing to update their version of the app, as it all resides on the server (or in libraries that the client application loads each time it runs). The App Store is a big leap backward over the always up to date nature of web applications, and even the desktop world, where apps can auto update, and developers can contact their user base to notify them of updates, and where developers can make sure the latest version is available online as soon as it is ready.

So, are there any arguments in favor of developing native apps for the iPhone? Well, arguably, there’s the whole issue of business models. People, we are often told, don’t buy web applications, but they do buy desktop apps, and so by extension will buy native iPhone apps. So there’s a ready made business model there. In fact, being able to charge for your apps is one of the key points of interest for many developers.

But let’s take a look at this issue in more detail. Disclaimer and aside – this is all back of the envelop stuff. But it is also based on 15 years of successfully developing and selling software online, and 15 years of pretty serious interest in this issue, and many frank discussions with other folks in a similar situation. Yes, the iPhone may just change everything about the software business. I just don’t think it will. If folks want to argue that iPhone native apps will turn all software business experience on its head, I’d be very interested to hear their arguments and see any evidence.

Firstly, people will and do buy web applications. Just ask folks like Flickr, Remember the Milk, and 37 Signals. In fact, they don’t just buy the app, they subscribe to the service, and pay recurring monthly or monthly fees. Now that’s a business model! Do you wonder why magazines offer subscriptions at a steep discount to the newstand price? Recurring, guaranteed income. One off sales with intermittent upgrades is not nearly so good a business model – just ask Microsoft, who’ve been trying to move users to a subscription model for years for Office and their OS products. Once more, native iPhone apps are a leap backwards, to the desktop world, and a time when freeware was on the whole not very good, and folks had the choice of either buying, or copying software. A lot of folks bought. But as any successful “shareware” developer will tell you, anything more than 1% of your downloads translating to sales (on the Mac typically these conversion rates were a little higher) was a pretty good outcome. In this regard, the App Store is a double whammy for developers – at a glance, many categories seem to have several free apps for each for fee app (just look at to do lists for a start). And, because there is no “try before you buy” system, what are folks going to download? The free app, or the $12.95, or even $1.95 app? So if the free version is “good enough”, you’ll struggle to compete regardless of how brilliant your app is. Good enough is a great strategy with software, and doubly so on the iPhone.

And even if you do start selling your app, let’s look at the kinds of numbers you’ll need to have a commercially successful app. Let’s suppose you are a small developer team. Hey, one person even. If you are a remotely good developer, an annual salary of $75K USD is probably on the low side. But let’s aim for just $50KUSD in income. Let’s say you sell your App for $1.95. You’ll need to sell 25,000 copies to make your income. Hang on, Apple take about 30% so you’ll need to sell 30% more. That’s 36,500 copies. If you look at a typical conversion rate of say 3% of downloads to sales (in my experience, good Mac apps can get that kind of conversion), if this were a desktop shareware app, you’d need to have 1.2 million downloads. That’s more than 10% of the entire projected iPhone user base for the end of 2008 interested in your app.
OK, let’s think about higher price points – at $5, you need to sell 14,000 copies, with a theoretical download of 476,000 demo copies. Up this to $10, and we are looking at 7,000 sales, and 233,000 demo downloads. And that’s for a single developer. Double this for 2 developers, triple it for a team of three, and so on.

In my experience, these are all very big numbers, and even with restricted competition (Apple is the gatekeeper remember, and there is only one way to develop and distribute your apps), I wonder how many folks are going to be making a decent profession or business out of developing native apps for the iPhone.

Now, let’s compare the “sell the app” business model with the increasingly common “subscribing to a service” model (like 37 Signals Basecamp and similar offerings). The model here is typically a free gateway version – with some kind of limit on how much you can do – for example the number of projects you can manage – then a graduated series of levels, starting at a small recurring fee ($5 per month for instance), up to a limit of typically $100 a month, which provides more or less unlimited functionality.
Let’s say we only have customers paying $5 a month. They are already paying $60 a year! So to make our $50KUSD, we’ll need around 1000 customers (about 14% of the number of sales of a $10 app). And I’ve factored in about 12% costs here (transaction and hosting costs, based on personal experience).

Interestingly, from what I’ve seen, the conversion rates from free to paying accounts for more than one such service based business is around the magical 1% number. So, you need 100,000 customers a year to try out your service, rather than anywhere between a quarter of a million and 1.2 million. Still a big number – but spread across all web users, not restricted to just iPhone users.

Now, there’s of course no reason not to have an iPhone native version of the client software for your service. It might even be an interesting marketing tool, and point of differentiation from your competitors. But it will require considerable effort and resources, which many small teams just don’t have. [3]

The launch of the iPhone was greeted with great excitement, but right from the outset, the lack of a way of writing “native” apps was considered widely to be detrimental to the platform. To my mind this shows still how little we really “get” the web. Instead of this being a defect, the iPhone marked the launch of one of the first, and certainly most hyped, web native devices. The way you wrote applications for it was using open, interoperable, non proprietary standards.
The arrival of native apps brings little or nothing to anyone other than Apple, and perhaps a few developers who launch successful businesses based on selling native apps. And it draws our focus away from the truly fantastic thing about the iPhone – its support for the web, which has driven data plan pricing down dramatically in many markets (sadly not yet in Australia), and as a consequence, ushered in an era of always on, web native devices, and seen a huge increase in mobile web usage. And, we are already beginning to see the impact on other mobile browser and device developers, as they ramp up innovation in the face of the success of the iPhone.

But imagine as newer Nokia, Windows Mobile, and other devices come online. Will developers have to develop for each individually? Yet another great leap backwards to the days of the platforms wars of Windows versus Mac, versus the rest.

That way madness lies.

The iPhone has amazing standards based support for developing applications – CSS/HTML/Javascript. Applications which will also run on the desktop browsers, on other mobile devices, on the Chumby, on your fridge, on your Wii, on Panasonic Viera televisions, and devices not yet even built. It’s time to put platform specific fragmentation behind us, and write applications for the one true platform. The web.

• [1] Others I’ve not tried that look pretty amazing, and which would probably prove far more difficult as web apps than native apps include the Moo music apps, and various games.
• [2] On the other hand, an application like Graffito, which lets you post notes that are then associated with where you posted them, and let you see other notes posted in the same area.
• [3] Notice I’ve made no mention of the advertising business model, for either iPhone or web apps? That is no business model at all in this space I’d argue. but that’s the subject of another post.