Going all-in on the mobile web

In this world of Android vs. iOS – with a smattering of Windows Mobile and Blackberry – I find native apps somewhat annoying. In the beginning, iOS was actually not going have any third-party apps on the phone and everything would run through Safari on your iPhone. Developer backlash due to worries about performance, though, helped lead to Apple changing its position on native apps on iOS.

I think this is a shame. I appreciate that web apps embody SLICE (Secure, Linkable, Indexable, Composable, Ephemeral, and I have heard it suggested that Updatable get tossed in). I also appreciate that the web embodies a common denominator platform that is cross-platform (I’m not naïve enough to think the entire web platform is cross-platform thanks to differences in what APIs are implemented at any given time by the various browsers). Why do developers need to choose whether to launch on iOS or Android first or exclusively on one platform? Why can’t developers simply launch simultaneously and instantaneously on all platforms through the web?

The answer is that many can, but they choose not to for various reasons (some legitimate, some not).

What leads to requiring a native app? #

What has traditionally set native apps apart from web apps on mobile phones? I would argue it’s the following:

  1. Performance (varies between browser releases and phone generations, but low-level stuff like controlling socket connections outside of WebSockets or SIMD for GPU calculations isn’t possible)
  2. Offline access (being solved thanks to Service Workers as AppCache is not pleasant to work with; actual storage space can also be an issue)
  3. Periodic background processing (Service Workers could do it if the task scheduler API gets accepted)
  4. Notifications (w3c spec for text-based notifications, plus there is a new Push API for Service Workers to work in the background to push notifications to the user)
  5. Sensors (stuff like geolocation are available, some other things are not)
  6. OS-specific features (e.g., intents on Android)

As you can see, a good amount of features have either just landed in browsers – Service Workers arrived in Chrome 40 – or are coming very soon – the Push API for Service Workers is coming in Chrome 42. Unfortunately not everything is actively scheduled to land in a browser – scheduling a Service Worker to run isn’t planned for any browser yet – and OS-specific features like intents are typically off the table since they are not OS-agnostic and thus won’t work in a browser no matter what OS it’s running on. In terms of raw performance, it’s a constantly fluctuating thing that’s always being discussed, e.g. Mozilla, Google, and Intel looking into SIMD in JavaScript. In other words claiming the browser is “slow” doesn’t hold a-priori.

Making myself a guinea pig #

How many apps do people use that lack a mobile web version but which actually could get away with having one (either full-featured or with some degraded UX)? Taking stock of what I have on the homescreen of my Android phone, I have the following list of applications grouped by category which I use almost daily and looked at whether they could have a web app experience of some form that was still useful. Anything in italic means that a web experience of some sort is possible today, and if something is bold then someone actually implemented a mobile-friendly browser experience.

Out of 20 categories, 19 could have a useful web experience but only 11 do (and 3 of them would require changing who provided me the service to get a web experience). I would be really curious to see a study done that evaluated if doing a mobile web app for Android and iOS – or even just one of the platforms – led to more or less work than doing a native app. But my point remains that just because someone provides a native app doesn’t mean a web app wouldn’t also work for the same use-case.

 
42
Kudos
 
42
Kudos

Now read this

My experience creating caniusepython3

Having been so heavily involved with the creation of Python 3, I’m constantly trying to figure out ways to help more of the community make the switch. While doing what I can to make Python 3 an obviously superior version to Python 2,... Continue →