Rewind, July 2008: Native Apps, the great leap backwards?

Panic, developers of Transmit and many other fine software products are folks I’ve long admired.

It’s probably not well known these days, but I started my journey on the web as a Mac app developer and used the web to distribute software, which lead to my focus on web technologies, and CSS in particular, and in the absence of a decent CSS tool, Style Master, which I developed for many years.

Panic has, for 20 years, been a really successful indie app developer.

Every year they publish an annual report where they talk about their year, what they learned, their successes and challenges. Now Panic is about as successful an indie Mac development house as there is or has been, so you’d think if anyone could make a go of iPhone and iPad apps, it would be them. So it was sobering to read of their forays into iOS development.

Trying to do macOS quality work on iOS cost us a lot of time for sadly not much payoff. We love iOS, we love our iPhones, and we love our iPads. But we remain convinced that it’s not — yet? — possible to make a living selling pro software on those platforms. Which is a real bummer!

So why mention this at all? Well, over the years, I’ve addressed the issue of web versus native, admittedly often quixotically, though the need of late has been less great. Which is the better path to go down for a developer? Are native experiences inherently better? Can the web survive the onslaught of native apps? Wired magazine certainly doubted it, some years back:

But, despite the millions of apps in app stores, despite the ubiquity of apps in our consciousness, despite Apple funding a reality show — a sort of Apprentice for app developers called, appallingly, Planet of the Apps — on average, smartphone users download 0 (yep, zero) apps on average a month.

They spend most of their time in just three apps. This is a winner-​takes-​all economy, where companies spend hundreds of millions of dollars a year just marketing their games.

While apps will be a significant part of the mobile experience for years to come, they won’t be the apps you or anyone like you builds. The economics are broken.

But here’s the thing, and hence the title of this post. The economics were always broken.

I wrote about this in 2008, (with a follow up to continue the conversation) and if you look at the comments then (yes, back then people commented on blogs) people overwhelmingly thought I was wrong, and that iOS native apps and the app store particularly heralded a bright new day for developers.

I think my initial analysis holds up remarkably well, and I’m interested in other people’s thoughts as we look back over that time.

But if I were to refine a deeper underlying point that I didn’t make well there, or even perhaps as well understand at the time, iOS and Android platforms have, to differing degrees, incentives that are only fortuitously aligned with those who develop for the platform.

All the while, the web evolves.

Key drivers of its development are, of course, browser developers and large corporations with deep pockets, but also individuals and small groups of passionate “users” of the web. The development of new approaches like srcset by the Responsive Images Community Group, approaches that were initially resisted strongly by the more established and influential WHATWG, demonstrates that standards development can take place in very democratic ways.

Compare this to the development of APIs on, say, iOS. One afternoon, usually in May or June at Apple’s WWDC, after being developed in secret for years, they are unveiled to developers. Take it or leave it. Yes, closed commercial platforms can seem to move more quickly, when we see the results of years of work at one stroke, unlike the seemingly painstaking efforts of standards developers, out in the open.

These are two fundamentally different approaches to the development of a platform: one autocratic and one more democratic (albeit with with many of the same flaws that political democracies have: the influence of money, interest groups, and of course those willing and able to devote disproportionate amounts of time to driving the development of the standards).

To use an analogy from Artificial Intelligence, these are two hill climbing algorithms.

One, the closed approach, looks to optimise around a local maximum, to continue to polish and refine the core of the platform, with diminishing returns.

The other, the open approach, focuses more on exploring a far broader landscape, allowing us to explore potentially fear higher peaks that lie disconnected from our current place on the map.

It may be that apps are the optimal human experience of computing, though since they emerged due to the constraints imposed by limited hardware, and from paradigms of Human-​Computing Interfaces decades old, the odds are that they aren’t.

Which is why the more open-​ended — dare I say it — anarchic approach to exploring the landscape of possible computing (to get all Brian Eno album name style on you) is to me the more interesting and I believe the most fruitful.

And to be honest, the web seems to continue to be the best way to make a living building things with code.

Comments are closed.