small medium large xlarge

Nice Apps, If You Can Afford To Write Them

What the iPad Really Means to Developers

by Chris Adamson

Generic image illustrating the article
  The App Store and iPhone opened a market, but will iPad limit it to large apps?  

In its event introducing the iPad, Apple showed off elegant tablet versions of its iWork applications, which will presumably serve to set the bar for applications on the much-anticipated device. The demonstration of Keynote, with a slick interface and deep functionality, portends great things for users of this platform... provided third-party iPad apps are anywhere near as good.

But that might turn out to be a taller order than is initially apparent.

Return of the Thick Client

Five years ago, desktop apps were dead. Everything, we were told, was going to be a webapp, as epitomized by Google’s efforts to put together an Office rival that ran entirely within the context of a web page.

And then a funny happened on the way to the cloud: people discovered that native, local applications offer a better user experience than webapps.

It wasn’t a necessary development: at first, Apple was determined to tell developers that writing iPhone-specific HTML and CSS was the One True Path to delivering a nice iPhone experience. But the huge interest in the “jailbreak” community, at least some of which was motivated by an honest desire to understand and employ the native APIs, proved that there was tremendous interest in delivering native applications on par with those that Apple shipped with the device. Maybe this forced Apple’s hand, maybe it was their plan all along, but at any rate, Apple eventually offered a native SDK, and everyone knows how that’s turned out.

But how is it that the same users who were perfectly happy to use webapps a few years ago are now insisting on custom mobile client apps for Facebook and Twitter, even when each has a perfectly good mobile website?

I think the answer is one of distribution. The win of webapps was always that they didn’t require any client-side installation process: no installer to run, no arguments with sysadmins about “approved” software, and no hassles for developers trying to update thousands or millions of client installations. To cite my own experience, I wrote a Java Swing client application in 1999, and in 2003 I found myself assigned to rewrite it as an IE-only webapp, a huge step backwards in usability and compatibility, but so much easier for customers to maintain that it was a no-brainer. Not having to drive out to client sites to debug botched installs or unanticipated network hassles got me over my aesthetic qualms pretty quickly.

With the iPhone and the App Store, many of these problems go away.  With the filesystem abstracted away, many of the installation hassles disappear: click “buy” or “download” and the app is on your device, ready to run, and impossible for the user to mess up by moving or deleting needed files. Updates are trivial to perform, and a red badge on the App Store makes sure the user always knows that he or she has new features or fixes available.

iPhone OS makes distribution and maintenance of native applications nearly as easy as webapps, and this has led to a renaissance of thick-client programming. (Between the iPhone and iPad, we need a new term for this style of programming. These devices aren’t “desktops,” and when the user is working in a local productivity app, they’re not really a “client” to anything either.) Developers who’d been forced to adapt to JavaScript and the fractured world of browser semi-standards are delighted to return to a proper user-facing API, particularly one as thoughtful and elegant as Cocoa Touch.

The App Store has its downsides, to be sure. Apple’s review process is often derided as unfair, imposing inconsistent, unclear, and self-serving rules on developers that are sometimes only discovered after an app is developed, submitted, and rejected. And some developers, accustomed to the freedoms of traditional web and desktop programming, will never accept the premise of Apple acting as a gatekeeper between them and their would-be users.

But the fact that more than 140,000  apps have been written for the platform in 18 months is more than just a story about the iPhone OS. It heralds the resuscitation of the user-facing native application itself. Tim O’Reilly might have been right that every app in the “Web 2.0” era needs to be network-enabled, but that doesn’t mean it needs to run in the context of a browser. Perhaps, the read-write web needs more than <textarea> for participation to be truly practical.

Now, with the iPad, we have an opportunity for a radical new start. Its interface metaphors are neither those of the iPhone nor of Mac OS X. Seeing iWork rethought for the iPad interface brings to mind a host of questions. Like the desktop, there’s much to manage on one screen, but like the iPhone and iPod touch, there’s no concept of window management. The OS X developer will need to start thinking in terms of views dominated by one or two significant tasks, like the editing of a document, without a collection of palettes and inspectors to assist. The iPhone developer will need to think in terms of staying on one view and handling many events and activities within that view, rather than navigating to a new narrowly-scoped view controller every time something is tapped. Using iPad may turn out to be a fundamentally new form of user interaction with applications.

A Rock and a Hard Place

Yet as the iPad giveth, the iPad may also taketh away. We might see a real renaissance in big user-facing apps, but I wouldn’t be surprised to see an end to the short-lived revival of the “one-person shop.” There have been a lot of stories about individual developers striking it rich—or at least paying the mortgage—entirely with iPhone apps they’ve written themselves. This phenomenon may be very difficult to recreate on the iPad, Apple’s promises of a “new gold rush” notwithstanding.

The difference is one of scope and shape. The iPad’s larger screen calls for more substantial applications, as does the imagined use scenarios of sitting on the couch for a long stretch with your iPad, as opposed to whipping out your iPhone for short sessions, like checking Twitter while in line at the store. Apple’s guidance to developers is noteworthy here. The message to iPhone developers thus far has been one of minimalism: only include the essential feature set your app needs, plan for short periods of use, keep it simple and responsive. With the iPad, the early message to developers stresses appearance: lavish graphics, on-screen objects that closely resemble their real-world counterparts, and a deeply immersive experience. What we’ve seen of Apple’s initial iPad apps, like the book reader with the photo-realistic bookshelf and e-books, exceptional layout and typography, and beautifully animated page flips, typifies this philosophy.

Apple has a world-class art department to produce this stuff. The indie developer in the garage does not.

Already, the App Store suffers from a Bling Arms Race.  Some categories of apps—unit converters and Twitter clients come to mind—are primarily differentiated by their appearance, with developers one-upping each other in the presentation department.  It’s not vanity that drives them, it’s sales: with app review sites overwhelmed and no “try before you buy” option (the usefulness of which is debatable anyways), the most obvious clue to the quality of an application is the screenshots that are so prominently featured in the App Store’s desktop and mobile GUIs. If developers care enough to make an app look good, shoppers sensibly conclude that the rest of the app is a quality production, and therefore a good purchase.

Thing is, bling costs money. There are Renaissance Men and Women among us who understand Photoshop’s blooms, diffuses, and glows as well as they understand Objective-C’s delegates and retains. For the rest of us, the choice is to either look “average” (which is the fast track to one-star reviews) or to hire on graphics professionals who can get our visuals up to snuff. And an app that has to pay two people’s bills, the developer’s and the artist’s, needs to make twice as much money to justify their investment.

Unfortunately, but probably not surprisingly, the App Store has proven to be highly hit-driven, with a small percentage of apps garnering an overwhelming share of the downloads. A Pinch Media analysis shows the top 10% of paid apps outselling the 10-20% decile by a factor of 8, with subsequent deciles quickly becoming even more irrelevant. Pinch’s analysis showed the average net proceeds of a given app to be about $8,500 as of October, 2009, but that’s a misleading figure: the distribution of sales suggests that the median revenue is much lower.

In an earlier analysis of the App Store economy, Twitterific developer Craig Hockenberry wrote about the lamentable rise of the “ringtone app", saying that his company was focusing on inconsequential 99-cent novelties rather than more substantial applications, because market conditions made it too risky to spend the developer months required to create more sophisticated apps. True to his word, his latest work is a premium flashlight application.

Maybe we can keep a developer and an artist housed, clothed, and fed on 99-cent ringtone apps, but only if they’re cranking out low-risk, low-investment apps by the bushel, and occasionally getting lucky.

And there’s the problem: little apps are what the iPhone and iPod touch excel at, so there’s some hope for the indies to produce a few hit apps that pay the bills. Scale up to the iPad, and the numbers aren’t as encouraging. The device demands more functionality, more art, more immersion... all of which means that iPad apps are going to cost more to produce.  Yet the device will start from an install base of zero, and iPad apps will still have to compete with tens of thousands of existing iPhone apps, which will happily up-scale to the device.

Put another way, the whole point of the iPad is to run the kind of apps that Hockenberry has already concluded that companies like his cannot afford to develop.

Outside of the opportunities for early-adopting developers to get some sales from early-adopting users eager for any iPad-optimized apps, the best hope for iPad developer might be higher prices. If users will pay $20 or more for iPad apps, they might justify developers and artists putting in months of work on them. But Apple has priced its iWork apps at $9.99 each, setting a price standard much lower than comparable desktop titles command (the three iWork apps cost $80 in a bundle for Mac).  If the iPad economy then experiences the same kind of “race to the bottom” that occurred on the iPhone, it’s hard to see how the romanticized “developer in the garage” has any chance of paying his or her bills with iPad development.

Oh, there will be plenty of opportunities for iPad developers, in contracting, vertical markets, and corporate development. There are a lot of businesses for which the combination of custom software and the iPad form-factor and feature set will be a compelling solution, and they’ll surely be hiring. But in a way, this gets us right back to where the desktop was before the web, with most developers doing corporate or contract work, with code more likely to support a business use than to be something sold directly to the end user.

The idealized “indie developer hero” concept had a nice revival, and it was fun while it lasted. But the dream is already dying on the iPhone, and the iPad won’t revive it.

Chris Adamson is a writer, editor, developer and consultant specializing in media software development. He is the co-author, with Bill Dudney, of the recently released Pragmatic Bookshelf book iPhone SDK Development. He has served as Editor for the developer websites ONJava and He maintains a corporate identity as Subsequently & Furthermore, Inc. and writes the [Time code]; blog. He wrote about writing apps for the iPhone in the second issue of this magazine.