Getty Images
It's the apps. The iPhone and Android conquered the world because of the apps. More specifically, what keeps Android and iOS dominant is the utter lack of those apps on competing platforms. But today, the mobile landscape is significantly different from a year or two ago (let alone five). Today, apps aren't really necessary. In fact, it's easy to envision an excellent, software-rich mobile device that uses the Web instead of apps.
There's currently a litany of problems with apps. There is the platform lock-in and the space the apps take up on the device. Updating apps is a pain that users often ignore, leaving broken or vulnerable versions in use long after they've been allegedly patched. Apps are also a lot of work for developers—it's not easy to write native apps to run on both Android and iOS, never mind considering Windows Phone and BlackBerry.
What's the alternative? Well, perhaps the best answer is to go back to the future and do what we do on desktop computers: use the Web and the Web browser. Updates to HTML apps happen entirely on the server, so users get them immediately. There's no window of vulnerability between the release of a security fix and the user applying the update. So with a capable, HTML-based platform and a well-designed program that makes good use of CSS, one site could support phones, tablets, PCs, and just about anything else with one site.
From the user's standpoint, it would be far better to have access to all those apps through a browser. Most of the reasons are the same as for the developers—nothing to install and automatic updates. Because of this, Web apps take up next to no persistent storage, leaving more room for music, videos, other persistent data and cache.
Currently, standards are advancing rapidly in the area of mobile Web applications as part of the emerging HTML5 platform. The goal, backed strongly by Google and Mozilla, is for websites to be able to do anything that native apps can. If this happens, native apps may no longer be necessary or desirable—right? Would the considerable advantages of the mobile Web (its near-zero footprint, updates performed on the server, and support for all platforms) convince developers and users to target the Web instead of the iPhone and Android? And would Apple allow this to happen?
The current app gap
Historically, the problem with using Web applications on mobile devices is that webpages have not been able to do the things we expect of apps: features like pinch and zoom or leveraging local hardware features such as the compass, accelerometer, and camera. That's changing, however, as mobile browsers provide access to local features. Standards bodies have been hard at work developing interfaces to control graphics, device notifications, data storage, payments, GPS, compass, accelerometer and other sensors, forms, multimedia, and more, and the W3C maintains a roadmap of these standards efforts developed by the recently completed, EU-funded HTML5Apps project. Among the efforts jumpstarted by HTML5Apps was a future W3C Web payments API standard that would define how Web applications interact with mobile wallets and other payment systems.
Obviously, Web applications don't work when there is no network to connect to. A middle ground application model called "hybrid" addresses this, but at a cost. Hybrid apps use a native operating system Web browser control to open a full-screen window, but they look and behave like native apps—including requiring a download from an app store. Hybrid apps get access to the hardware features unavailable to the Web through third-party tools, mostly based on Apache Cordova. Hardware support in Cordova for iOS and Android is excellent but spotty elsewhere.
If there's one big impediment to this view of the future, it's Apple. Through its actions and inactions, Apple has shown itself hostile to the possibility of a competitive Web model for iOS. In January 2015, Apple announced that "[t]o date, App Store developers have earned a cumulative $25 billion from the sale of apps and games." Overall, 30 percent of that goes to Apple as does 30 percent of subscriptions and other in-app purchases.
At the same time, Apple has been slow to adopt the standards that make a powerful mobile Web possible. Three of these—Service Workers, the Vibration API, and the CSS touch-action property—are good examples of functions that programs need in order to give the full app experience on mobile.
Service Workers (a draft W3C specification) are arbitrarily complex JavaScript functions that enable browser tasks to run tasks in the background and react to events. They are a big part of any plan to make Web apps as sophisticated as native apps. As an example, Google provides a simple Service Worker that handles page requests when offline. Nobody implements Service Workers completely, but there is partial support in Chrome, Opera, and Firefox (Firefox support is turned off by default). Microsoft says it is considering it for Edge, but Apple does not support Service Workers and has not announced plans to add them.
The Vibration API provides access to the vibration mechanism of the hosting device. Firefox, Chrome, and Opera support it. Safari, IE, and Edge do not, although Microsoft says it is under consideration for Edge.
Touch-action is (quoting caniuse.com here) “…a CSS property that controls filtering of gesture events, providing developers with a declarative mechanism to selectively disable touch scrolling (in one or both axes), pinch-zooming or double-tap-zooming.” In other words, it allows webpages to control the behavior of the browser in reaction to touch events. (The spec does not support multi-touch.) Touch-action is supported in Chrome and Opera, even in Internet Explorer and Edge. It is supported by Firefox but disabled by default. Safari does not support it whether on OS X or iOS.
Apple did not reply to requests for comment for this story, but none of these three standards are in iOS Safari. There are also more features like this missing in iOS or implemented insufficiently. iOS is certainly not the only browser falling short, but it’s obviously the most important one on mobile. If you want to find out whether you can use specific features on particular mobile browsers, check caniuse.com.
Developer discontent
Further Reading
Op-ed: Safari is the new Internet ExplorerIf devs build a modern Web app ecosystem sans Safari, maybe Apple can move beyond 2010.This state of iOS affairs has created some resentment in the developer community. Recently, Nolan Lawson, a Web developer involved with standards development, created a stir with his hyperbolically titled Safari is the New IE (the piece was reposted on this site). Lawson admits the title is sensationalistic in the service of “made you look,” but he has a valid point.
The comparison to IE makes the case that, just as Microsoft let IE languish for years after version 6, so has Apple let Safari languish. Clearly there’s something to this, but part of the problem comes from other iOS development rules.
Apple goes to great lengths to prevent third parties from implementing all these features themselves. It is against Apple’s guidelines for apps to use their own rendering or JavaScript engines. This means that Chrome on iOS may look like Chrome, but it’s using the same JavaScript engine and the same display routines as Safari, so Google can’t add Service Workers or anything else.
There are many other such limitations. On Android, apps that meet certain criteria can add their own icon to the home screen, a feature that has been available to users in Chrome for some time. The criteria may change over, but currently apps must (says the Chromium blog) “… provide a Web App Manifest, serve all content using HTTPS, and at least partially work offline using a service worker.” Apropos of this, if you use a site frequently in Chrome on Android, for example, it offers to add a link to it on the home screen.
What is a Web App Manifest you ask? It is a JSON file that gives the developer control over how the app is presented to the user and how it may be launched. Manifests such as this have been common in other forms of programming for a while. Web App Manifests are simple, but more controls will be added to them over time.
Dominique Hazael-Massieux, who leads the work on the mobile Web as well as telecommunications such as WebRTC at the W3C (World Wide Web Consortium), told us that Service Workers are just one of the standards for giving mobile websites a good offline capability. There are already many possibilities afforded by well-deployed Web technologies today for caching and local storage, such as the Web Storage API and IndexedDB, although support for the latter is buggy and inconsistent. An older specification, WebSQL, has been deprecated.
These storage specifications raise one, if not the main, legitimate concern of mobile operating system authors. Allowing websites to allocate storage on mobile devices could easily lead to abuse. Systems that support this limit it per domain to levels which could be problematic to Web app authors.
Another feature Hazael-Massieux emphasized is system notifications. It’s now possible in Chrome for a Web app to be awakened based on external events outside the context of the webpage notified. These Web Notifications are also a W3C spec.
Enlarge / Really, Google likes this idea.The difference with Google
I’ve mentioned Google a lot, and you might think that Google has all the same incentives to promote native apps at the expense of Web apps that Apple has. That’s what I thought, but it’s not quite true. Google is at least as involved in the development of these new standards as anyone, and the company is more aggressive about implementing standards in the browser than anyone.
Alex Komoroske, product manager and lead of the Chrome Web Platform team at Google, made it clear to Ars that Google wants to make the Web as "frictionless" as possible on mobile. It all comes out of making the best experience for Chrome users. According to Komoroske, Google sees Chrome users on Android visiting more than 100 sites per month compared to 20 to 25 native apps per month.
Further ReadingHow Google Inbox shares 70% of its code across Android, iOS, and the WebGoogle's open source tools allow it to use Android code on iOS and the Web.Komoroske gave a presentation on the “The next generation mobile Web” at 2015 Google I/O conference, and he made many of these points. Google’s concern is to make things easier for users, and since Android users run Chrome a lot the browser gets a lot of Google’s attention.
Another common concern is performance. After all, Web apps are purely interpreted code and native apps are, of course, native code. Native apps will always be faster, at least in theory if not in practical terms. However, Web apps don’t have to be as fast as native—they just have to be fast enough. It’s happened many times in the development of technology: the move from text mode to GUI, the adoption of HTML itself. All of these become fast enough at some point and nobody cares anymore.
Google’s focus for mobile Web performance is on a framework called “RAIL,” a series of measurements for determining if performance is good enough, which means the user doesn’t notice delays (see 11:00 in the Google I/O presentation):
R – Reaction time, from when the user touches the glass until something happens. This needs to be below 100ms.
A – Animation time, the time to put each frame on the screen. You need to be below 16.67ms, which is 60 frames per second.
I – Idle time, the time for doing other things like image decoding. You can’t be doing these things while the user is interacting, so you need to chunk up idle time into blocks of 50ms or less.
L – Load time. You have less than 1 second or the user’s train of thought may go off the RAILs.
Thanks to features like Service Workers, it is now possible to architect websites with “good enough” performance.
It hasn’t always been this way. In 2012, Facebook gave up trying to write "hybrid" apps for iOS and went native, mostly blaming performance problems. It’s hard to blame Facebook for putting its considerable resources into building the best app, but in the long term the company may move back to a more portable model. (We also asked Facebook for comment on this story and got no reply.)
Computational performance isn’t usually an issue in Web apps, but certainly it’s important to some. If the job is big enough, it probably makes sense to do the work in the cloud, but for high-speed local processing there are several efforts underway, such as asm.js, SIMD, and WebAssembly.
Other developers I spoke to said that performance isn’t really an issue in Safari anymore, and this points to one of the main defenses Apple developers made to the "Safari is the New IE" argument. Apple, says Rene Ritchie, is focusing on user-centric improvements not developer features. These improvements naturally include performance, but they also encompass the addition of extensions and the integration of Keychain and content (read: advertising) blockers.
One of the ways Apple engenders a lack of trust is that it doesn’t often send people to non-Apple developer conferences; Lawson even makes this point. Apple has reasons for this, as described in an Accidental Tech podcast in reaction to Lawson’s article (starting at about 20:45). For instance, Apple doesn’t like to tip its hand on new developments.
The Accidental Tech podcast goes into more general objections that Apple might have to embrace at least some of these advanced Web technologies. Currently, sites are limited to 50MB of local storage and must ask the user for permission when exceeding 5MB. For Web developers this is a pain, but Apple needs to be concerned about arbitrary Web apps using arbitrary storage on the device. With native apps, Apple gets to OK the storage strategies as part of the app approval process.
In spite of those concerns, even if you believe that Apple must eventually get the program and enable rich Web app capabilities in iOS, you have to ask, “what’s in it for them?” Apple wants you to write native apps.
Could there be a good solution to the potential for storage abuse by Web apps? It's a hard problem, especially in as much as the solution has to be invisible to, or at least understandable by, ordinary users. There are standards efforts, the Storage Standard (https://storage.spec.whatwg.org/) and the W3C Quota Management API, to address the problem using storage quotas, but this approach is neither invisible nor accessible to ordinary users.
And problems like this go well beyond storage. iOS is so restrictive because Apple has been very conservative in allowing capabilities that could present security and usability problems.
The other OSes
In theory, as developers move to Web apps, the use of less-popular mobile operating systems becomes more practical. If their browsers are standards-compliant, then they get a lot of new apps. I asked Firefox about its Firefox OS and Microsoft about Edge in the context of this question. As you would expect, Mozilla has been fairly aggressive about adopting these standards. Its strategy is, after all, that the Web is the platform. “…Firefox OS provides developers with a number of APIs through which they can access device capabilities -- sensors, connectivity, camera, location, system resources such as storage, etc. Many of those interfaces are already addressed by W3C standards, to which Mozilla has been an active contributor, and Firefox OS does conform to those standards.” In other areas, Firefox OS is even ahead of the W3C curve, at least for its own hardware.Further ReadingFirefox OS smartphones are deadMozilla announces it will stop development and sales of Firefox OS smartphones.
[Editor’s note: Since this story was filed, Firefox OS passed away after a long battle with irrelevancy. Firefox the browser lives on and is the more likely beneficiary of this technology.]
Microsoft is active in the development of Web standards, and several years ago the company pitched something like this to me. For many applications, especially as displays increase in size, a Web browser is just fine and a native app is not necessary.
And while Microsoft has more urgent matters to deal with in Edge (such as the lack of an extension or plugin model), it has been adopting many of the new standards and considering others. The company maintains a status page for standards support in Edge; it's not running away from these challenges, although the company may not be running toward them fast enough either.
Microsoft is more anxious to push developers toward the Universal Windows Platform, of which Edge is a part. Universal Windows Programs are certainly interesting and kind of cool, but they’re also designed for Microsoft platforms. It’s just not the same thing as writing Web apps that can run cross-platform.
BlackBerry’s browser is based on Webkit, so it's largely at the mercy of Apple’s plans.
Development of these standards is not just to the benefit of mobile users. The charter of the W3C’s Web Applications (WebApps) Working Group makes it clear that they are targeting Web applications “…on desktop, mobile devices such as phones and tablets, televisions, and other devices, as well as non-browser environments that make use of Web technologies.”
Office 365 and other sophisticated Web-based applications benefit from having the most sophisticated UI features that are normally available only to native desktop programs. Imagine the binary desktop version of Office going away—it could happen. Would Microsoft want that? For Office, why not?
To the extent that rich WebApps make desktop operating systems more interchangeable, the picture is less clear. For now, a Chromebook performs a subset of tasks that a Windows computer can, as that computer can also run Chrome. When only the browser really matters, it’s conceivable that Windows as a platform will lose appeal (in theory at least).
Those defending Apple against Lawson also claim that users aren’t asking for Web apps, but this doesn’t wash. Users never know the value of the new features going into platforms. If they knew that quality apps might be universal across platforms and that they didn’t have to update it or go to the store for it (and that it would not consume any persistent storage), users might want that.
So maybe what we all need right now is the killer Web app—a demonstration of a website that performs beautifully, even if only on Android. Maybe that would get users’ attention and, maybe then, Apple’s attention. Google is headed in this direction. And for what it’s worth, Microsoft will probably head in this direction eventually with Edge. That leaves Apple as the big question mark. Does it have too much to lose?
Larry Seltzer is the former editorial director of BYTE, Dark Reading, and Network Computing at UBM Tech and has spent over a decade consulting and writing on technology subjects, primarily in the area of security. Larry began his career as a Software Engineer at the now-defunct Desktop Software Corporation in Princeton, New Jersey, on the team that wrote the NPL 4GL query language.