One of my favourite tweets of recent weeks comes from Jon Lech Johansen (of DeCSS and latterly of DoubleTwist fame): “Next year HTML5 will replace native apps” is the new “Next year will be the year of Linux on the desktop”.
I bet Google’s team wishes that native apps were passé, seeing as it had to claw back a malfunctioning iOS app from the market on Wednesday. If if weren’t for the fact that its customers insist on having a native app – if only they were happy to use a mobile web browser – then no one at Mountain View would be worried about their jobs. But they are.
Jon’s comment is set up like a joke, and like all good humour it works because there’s truth in it that resonates. As software engineers, we’ve learnt that if we put an application on a website we can abstract away the client device and have a single unit of operations that we can directly control.
We don’t have to worry about wrinkles in individual client configurations derailing the process. (Google – we could be writing about your iOS app!) We can change production apps under the covers during business hours without having to “fess up” to the mistake. (Google – we could still be writing about your iOS app!) We don’t need to care whether it’s Android, iOS, Windows Phone, or even BlackBerry. We write one application and deliver it over a generally well-supported open standard.
So native apps – providing they are non-game apps like Twitter, Facebook, Instagram, etc – are anachronistic. They are more client/server than web. We took client/server out to the paddock and calmly shot it in the head many moons ago, didn’t we, so logic suggests we’ll repeat that with native apps on smartphones. So yes, Jon’s comment is an excellent example of geek humour, but deep down we all want it to happen.
So there’s a clear impedance mismatch here. Intuitively we know that the experience of using a native mobile app is more comfortable and natural than using the web-based equivalent, even if we bring all of the snazzy new HTML5 technologies to bear. Google knows this, which is why its teams try to (and in fairness, typically do) put native apps onto phones that key into their back-end services. A web-only play does not get the buy-in from customers that they need.
But as software engineers we also know that we operate in a cycle, part of which is to vacillate between running our software logic on “remote lump of expensive iron” and “inexpensive local device”.
We used to run apps on mainframes, then we moved them to PCs. Then we moved some of the PC logic to the server (client/server). Then we moved composition of the user interface over to the server (web-based intranet/extranet apps). Then the iPhone comes along, and we start building client/server apps again. Interesting point though: we didn’t have to.
As an industry we hassled and hassled Apple to let us build native apps for iPhones. It wasn’t the way Steve Jobs, for one, wanted to play it at all (although there were plenty of others inside Apple – such as Scott Forstall, head of iOS, who did).
But I digress. We know why we dismantled client/server and stopped working that way. Logic suggests a desire to do the same with native apps on phones. Plus the problem is worse today compared to the late 1990s.
Back in the day, we just had Windows to target. Now we have a moving target. If you showed me a company last month targeting consumers that had an Android-only offering I’d have looked at you strangely for not having iOS coverage. In the past three days along that’s changed. With a quarter of the UK population owning an Android phone, not targeting iOS feels more appropriate.
So we abstract. That’s what we as engineers do when we want to raise ourselves up above the platform. We get away from the bare understanding of the target, wrap it with layers that we can swap in and out and build our beautiful thing atop. And now we find there’s a market for this sort of abstraction in the guise of things like PhoneGap, Xamarin and the new appMobi.
But, as Steve Jobs said in his famous public scrap with Adobe over Flash support on iOS: “We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform.”
Another way of saying that is that abstraction and compromise are joined at the hip. It turns out that abstraction holds your customers at arms’ length when you should be giving them a cuddle.
Are we going back?
So are we going to retread the same path we did with client/server – i.e. put down native apps and move everything back to HTML5?
There’s one important difference now compared to the late 1990s: we, as technicians, no longer lead this debate. A business case to junk a client/server app and replace it with an intranet app was always winnable because we had our audience’s ear, and we could build a coherent and rational argument. Organisations typically behave far more rationally than unassociated individuals.
We are now no longer masters of this domain. We have a commoditised market where the consumer is in charge. If you look to connect with your customer a user via a mobile web app (a “handshake”) and your competitor offers them a “cuddle” with a better native app experience, you will lose, regardless of the eloquence of your argument or the sophistication of your engineering. You no longer have a seat on the board.
So, next year might be the year of HTML5 replacing native apps. Or it might not. Suffice it to say that if it does happen, it would have nothing to do with we technicians. We no longer get to be the tail that wags the dog.