Circling the iOS Wagons
Since iOS 7 was announced something’s been troubling me about the way in which some very high profile iOS developers, and others very firmly in the iOS camp, have been responding.
It probably began with Marco Arment’s Fertile Ground post:
I don’t think most developers of mature, non-trivial apps are going to have an easy time migrating them well to iOS 7. Even if they overcome the technical barriers, the resulting apps just won’t look and feel right. They won’t fool anyone.
This is great news.
iOS 7 as a challenge. iOS 7 as a forest fire, wiping the slate clean. A meteor clearing out the dinosaurs. You know, those dinosaurs who’ve invested enormously in the iOS platform, who’ve in many cases staked their business, perhaps their family’s future on the iOS ecosystem. I’m sure they are not thinking “This is great news”.
But snarkiness aside, think about this supposedly ideal platform. Every 3 to 5 years, a “fire” sweeps through. Established developers, users, basically the entire ecosystem except “those with the least to lose” are upended. Is this a platform as a developer would really want to dedicate an enormous chunk of their energy to? Indeed as a user, do I really want to go through a Permian Die Off of many of the apps I rely on to organize my life? What happens to my data?
But that’s all ok, because Arment believes
Anyone can march right into an established category with a huge advantage if they have the audacity to be exclusively modern
Anyone. Right.
iOS 7 as Defense
Then in the last couple of days, a related meme has emerged, the idea of iOS as a barrier to entry, a Cordon Sanitaire, against imitators, those who might dare to not use “native” tools. iOS as an impediment to those who don’t dare to dive deeply and lovingly into the Kool Aid, but who might want to reach as broad an audience as possible, including, but not exclusively the hundreds of millions on iOS phones and tablets.
Again, this reasoning is perhaps best summarised by Arment, in a post titled iOS 7 as Defense, perhaps unwittingly capturing this sense of iOS developers against the world:
iOS 7 is … going to be a problem for cross-platform frameworks. Fewer assumptions can be made about the UI widgets and behaviors common to all major platforms. And any UI targeting the least common denominator will now look even more cheap and dated on iOS 7, since the new standard on the OS is so far from the old one.
Ironically, Arment has this caveat:
Very little of this article applies to games. Games usually build entirely custom UIs shared between platforms, they’re more financially viable than non-game apps on Android, and cross-platform game frameworks are so good that it’s relatively easy to maintain iOS and Android versions simultaneously.
So, one of the few areas where developers actually make any money on the platform doesn’t actually count for the argument (in April 2013, by way of example, the top 5 revenue generating apps for both iOS and Android were all games).
In a similar, though less circumspect vein, we have Alan Pike, in a post titled Catch me if you can, quoted favourably, it almost goes without saying by John Gruber: ‘Try copying this, assholes’
. He notes regarding the new UI features of iOS 7:
bringing to life these blurs, animations, and dynamics with HTML and JavaScript isn’t yet possible. You need the latest hardware and the most efficient software to make something feel like this. Further, you need thoughtful APIs so developers can take it to its full potential. In short, the browser vendors have their work cut out for them
And this is somehow a good thing? (I’d also take issue with the assertions in the article at a deeper level. Many CSS features now pass their calculations off to the GPU, essentially meaning no performance difference between a browser based or native app, and I’m currently exploring how many of these features such as translucency can be done with today’s web technology.)
Circling the Wagons
Is it Apple’s intent to create higher barriers for other platforms which would copy their UI? Or to make it more difficult for developers using cross platform technologies to make the grade on iOS? Who knows. And in a sense, it really doesn’t matter. But it’s interesting that this idea has struck such a chord with such high profile commentators and developers as these. There’s almost a sense of glee that developing for iOS is going to become harder. Because developing I guess should be hard. Which is why Gruber’s latest project is built in part using a technology that mimics CSS (to co-opt a term folks like to use about non-native apps). Because you know, native is better. And stuff.
I associate this with the enthusiasm with which so many “native” enthusiasts deride the ‘jankiness’ of scrolling in apps built with web technologies, and celebrate events such as Facebook’s walking back their use of HTML5 to build their iOS apps. But you know what? We who focus on the web get it. We really do. A great many of us are iOS users. Almost all of us recognize there will be cases where a native app, in the broadest sense, one that can tap directly into device APIs
But we realise the world is much much bigger than iOS. It’s much much more interesting (IMHO) than just iOS. At the end of the day, the app model is decades old. It is a constraint on our imagination. It is in Scott Jensen’s wonderful analogy, a local maximum.
Afterall, the app most used across all users on all platforms is of course, the browser. And, in many many cases, native Apps are essentially specialised browsers for a paticular silo of information, from Facebook, or Twitter, or Instagram, all sent over HTTP, often as HTML, or XML, or JSON.
Local Maxima
When we focus obsessively on the superficial, we limit ourselves as to what’s really possible. We stay at our local maximum.
The web’s been here before. Twenty years ago, hypertext experts saw the web as anemic, under-powered, capable of so little that was state of the art for hypertext systems at the time. In 1991 a paper on the World Wide Web by Tim Berners-Lee was rejected for HyperText 91, the peak conference on hypertext in the early 1990s. Why? Here’s a critique from the time.
- Links in hypertext must be bidirectional. WWW’s are one way only.
- WWW servers aren’t aware of each other and there is no inter-server communication.
- All WWW servers are equal. There should be a concept of hubs.
- WWW servers don’t keep state. They are completely unaware of their previous interactions.
- It’s obvious that whoever wrote the hypertext engine doesn’t understand SGML. This HTML is done all wrong.
- Finally, he’s giving this away for free. That means it has no value at all. We have our own version and a strong licensing partner.
To me, the ongoing argument as to the superiority of native platforms over the web sounds awfully similar to this.
This early critic of the web saw many of its features (statelessness, a network architecture without hierarchies, its simple linking system) as bugs (I’ll tell the truth, I was there at the time, I developed a pretty sophisticated hypertext system, I agreed with pretty much all these points at the time. I was wrong.)
We continue to see many of the features of the Web as bugs. Just as in 1991, what currently appear to be its weaknesses, may well end up as its great strength—its reach. Both as a platform for people to consume content, but also as a creative platform, which gives the rivalled ability for genuinely almost anyone to reach the world. Yes, the great unwashed can write janky scrolling apps for iOS. I see this as a feature.
And it’s also not an ecosystem that will be razed and built anew every few years. Yes, its slow and somewhat unsteady development, at times steps forward, at times seeming back, frustrate many. Bug for some. For me on balance a feature. A stable foundation for now just those with the least to lose, but for all.
These things are in the nature of the web, are the nature of the web. And to me these are among its essential, defining features.
Great reading, every weekend.
We round up the best writing about the web and send it your way each Friday.