Web Apps

Lost in the competition between platforms (iOS vs. Android) is the more philosophical competition between native and in-browser web apps. In the early days of iOS, say, circa 2008-2011, it was easy to conflate these two battles in public debate, because Apple was seen as the primary proponent of native app development, and Google was seen as a proponent of cross-platform web apps. No more. Google today (like Facebook) seems all-in on native apps, at least (again, like Facebook) for post-PC devices. Just a few years ago, I used to see a lot more arguments from web-app proponents that native apps’ dominance on mobile devices would be short-lived. I don’t see so much of that any more.

I think Apple and Google have learned Microsoft’s lessons. Microsoft’s dominance in the PC market was unassailable — until the web appeared. Suddenly, having a Windows PC mattered much less, because native Windows apps became a lot less important. The things people did with their computers mostly happened inside a web browser, not inside a native app.

Apple and Google know that one of the main reasons people buy phones running iOS and Android is their app dominance. You don’t have WhatsApp? I can’t use your platform, sorry. Thus, supporting cross-platform development is against Apple’s and Google’s interests.

Apple, for example, isn’t exactly making it easy for the people who are developing web apps. Web apps pinned to the home screen on iOS have serious issues that prevent them from working like native apps; for example, they often lose their state when the user switches to another app, and reload when they’re reopened. In fact, Apple is actively making pinned web apps worse.¹ Things like the apple-mobile-web-app-capable meta tag are completely broken in iOS 8.

Meanwhile, more and more native apps are actually using web views, either for parts of their UI (like a timeline in a social network), or for all of their UI. If people aren’t told, they don’t notice it. If people do know, their opinions mostly seem to come down to confirmation bias. Today, we’re at a point where web apps, if done right, are virtually indistinguishable from native apps. Brock Whitten points out:

Take a look at the this blog post attempting to expose the advantages of Hybrid vs Native which not only uses Instagram as an example of a Native app but it is specifically used as a example of a GREAT native app and why you might want the performance and smoothness of Native. This is somewhat hilarious, because it is in fact a hybrid application that uses a web view to render all of its content.

There are plenty of companies advertising «native apps» that are really nothing else than branded browsers that run a web app. Put a web app inside a native wrapper, and voilà: you have a native app. This works, because web apps have become good enough that most people don’t have to care about the difference anymore. To them, the difference between a native app and a web page comes down to things like an icon on the home screen, the fact that it appears in the task switcher, and the fact that it can receive notifications. All of these things can be provided by a web app with a native wrapper.

There was a huge story back when Facebook ostensibly switched from a web app in a native wrapper to a «true» native app. But looking at their native app on my phone, and comparing it to their web app, I’m hard-pressed to notice a real difference.

How does the new «native» Facebook app render its timeline? Is it a web view? I don’t know. And that’s kind of the point. How would the user know the difference without looking at the code? And if you have to look at the code to know the difference, why does it matter?

Web apps are already here, they’re here to stay, and you are using them without even knowing it.

Gruber notes:

One reason some people argue in favor of in-browser HTML/CSS/JavaScript web apps is that it’s the last bastion for write-once-run-everywhere. The lament I hear most frequently about mobile development is that if you want to reach the widest possible audience, you have to write at least two apps, iOS and Android. If you include Windows Phone, now you’re up to three. My take has always been: Tough luck. The point of making apps shouldn’t be about making life easier for developers, it’s about making the best possible apps for users.

The plain truth is that development is expensive. If you can afford five developers, and they can either work on two different apps, or on one single app, you will get much better results if they all collaborate on one app. This is not about making developers’ lives easier. This is about being able to focus your resources, and to make sure that all of your users can benefit from all of your effort, rather than some of your users from some of your effort.

Advantages of Native Apps

There used to be three major reasons for going with native code:

1. Performance
2. UX consistency with the host platform
3. Direct access to APIs

Of these three, only direct access to APIs is still a major issue. You can use something like PhoneGap, but you’ll always be lagging behind.

Performance is not an issue anymore. People are now writing real, serious games using web technologies. Browser developers have become really good at optimizing the performance of web technologies.²

Similarly, in-platform UX consistency is effectively dead. The iPhone of 2014 is not the Mac of 1984. Facebook has its own UX. Twitter has its own UX. People are okay with each app having its own separate, unique identity.³

Clearly, neither Apple nor Google can be happy with this development. They like native apps, because that prevents other platforms from entering the market. But for users, web apps a good thing, because they divorce apps from operating systems, and make it easier to choose freely which OS we want to use, based on the OS’s own merits, rather than based on whether it runs the apps we need.

Just as the web allowed the Mac to compete with Microsoft, it will allow other mobile platforms to compete with iOS and Android.⁴ And I don’t think anyone should be against that. Nobody should want another situation where one single company⁵ has dominant control over operating systems for two decades.

In Short

• Doing bad web apps is easier than doing bad native apps,⁶ but web apps are not by definition worse than native apps. You can do bad native apps, and you can do bad web apps, just as you can do good web apps, and good native apps.
• You’re already using web apps in native wrappers without even noticing it. The fact that nobody even notices, the fact that this isn’t a story, shows that, when it comes to user experience, web vs. native doesn’t matter anymore.
• Native apps mainly benefit Apple and Google, not their users. It’s not in anyone’s interest to be locked into a specific platform, except for the platform’s owner.

A final word

Gruber noted that «Lost in the competition between platforms (iOS vs. Android) is the more philosophical competition between native and in-browser web apps.» I think that from developers’ point of view, this has never been a competition. It’s just a choice you make when you develop an application, and each choice has its advantages and disadvantages.

There are apps that need deep hooks into the OS (e.g. a podcast client that does audio transformations), and work better (or only) as native apps (though maybe the part of the app where you discover new podcasts could be a web view). And there are apps that work just fine as a web app, without anyone ever noticing the difference.

It’s fun to have ideological battles over platforms and technologies, but to developers, these are pragmatic choices, not religious ones. Some developers go with native apps, others pick web apps in native wrappers. As time goes on, I think there will be more and more of the latter. The only reason users should care either way is if they don’t want to be locked into a specific platform. And if they don’t, the slow, steady move towards web apps can only be a positive development.

Native apps are good for Apple and Google, but Apple’s and Google’s interests don’t always align with the interests of their users.

1. While preventing other browser makers from truly competing with their built-in browser, something Microsoft never managed to do, though they tried their best.
2. Even though we’re now at a point where you can buy a sufficiently fast phone at under 100 US$ without a contract, as Adrian Stutz points out, there are certain markets where performance can still be an issue. On the other hand, it’s possible to write reasonably complex web games that run even on a first-gen iPad, so web apps can be optimized to target low-end devices.
3. Please don’t compare this to Swing, by the way. Swing was a terrible attempt at mimicking native UIs. We all know that this doesn’t work; it puts you into the uncanny valley of UI design. When using a Swing app, everything feels like a weird nightmare, a slightly warped version of reality. Web apps are not that.
4. On a related note, I just got my first phone running Firefox OS. It’s better than I expected.
5. Or two, which is probably only slightly better.
6. Since you have to make an effort to make a good web app, and get all of the details right. And you have to make an effort to make a bad native app, and replace all of the native UI elements with inferior custom ones.