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.

• Alarm (Timely): not possible as a web app due to lack of background scheduling and the ability to force a web page to appear to play some alarm constantly
• Podcast player (Pocket Casts): they have a web app, but it isn’t mobile-optimized
• Navigation (Waze): would require keeping the app upfront, but there is no reason a navigation app couldn’t exist through a browser
• Email (Inbox): Inbox doesn’t have a mobile web app, but Gmail does
• Local search (Maps): Maps has a full-featured mobile experience
• Messaging (Hangouts, WhatsApp, Cord, and Facebook Messenger): a degraded experience until the Push API is available is possible when the web app is running upfront; Facebook has Messenger as part of their mobile web app while Hangouts does not and the way WhatsApp is designed simply won’t allow a web experience that doesn’t require the native app without better storage guarantees in the browser
• Phone calls (Hangouts Dialer): WebRTC shows that making phone calls doesn’t require anything special from the browser on your phone
• Check-in (Swarm): A degraded experience that doesn’t tell you about when your friends are nearby is totally doable in the browser
• Learning a language (Duolingo): already works on the desktop, so no reason not to work on mobile
• Lists (Keep): Keep has a mobile web app
• Membership cards (Stocard): Geofencing would let you get deals pushed to you, but scanning barcodes in a browser and showing them later is totally doable
• Streaming (Netflix and Play Movies): Netflix is obviously on the desktop, so as long as mobile browsers have the DRM support necessary it should work in mobile browsers
• Movie/TV info (IMDb and Series Guide): IMDb works fine on mobile – albeit with some missing features, like custom lists – and Series Guide can store its data in Trakt which has a mobile web site
• Music (Play Music and Sonos): Sonos requires special socket access so that’s not doable, but Play Music could totally be done in the browser
• News (News & Weather): Google News has a mobile website
• Social media (Google+ and Facebook): Google+ and Facebook both have good mobile websites
• Feeds (gReader Pro backed by Feedly): Feedly lacks a mobile site, but The Old Reader does not and gReader can read from either as a backend service.
• Read later (Pocket): Pocket has a desktop site, there is no mobile site; Instapaper does have one, though
• Calendar (Calendar): might not be able to raise event reminders, but Google Calendar is available on mobile
• Passwords (Oplop and Dashlane): Oplop has been mobile-friendly for years while Dashlane is not (nor is LastPass)

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.