By Glenn Fleishman

November 27, 2014 6:56 AM PT

Web apps, native apps, and app ecosystems

Note: This story has not been updated for several years.

[Glenn Fleishman writes regularly for the Economist, Boing Boing, and Macworld, and tweets incessantly—oh why won’t he stop?—at @glennf.]

A recent spate of articles caused yet another dustup about the future of the Web (an open publishing medium based on standards that ostensibly works anywhere) versus native apps, which are programmed according to standards for distinct platforms and may (Google) or may not (Apple) be freely distributed without oversight and review.

The Wall Street Journal‘s Chris Mims started it off with “The Web Is Dying; Apps Are Killing It“; Zach Steward wrote a rejoinder at Quartz, “The web is alive and well“; and John Gruber dissected and rejected Mims’ narrative at Daring Fireball, “Native Apps Are Part of the Web.”

I believe there were a couple of missed points among these articles, although I generally favor Gruber’s broader view of the Web’s position within apps. He notes that apps “are alternatives to websites that run in web browsers. They’re just better clients.” Most apps are just thin layers on top of modern Web standards with the added benefit of a potentially superior user-interface experience, because the operating system takes care of more details with greater consistency, and allows a complicated but more reliable adaptation to multiple sizes of devices, whether it’s iOS, Windows Phone, or Android.

A Web browser on mobile and desktop devices isn’t a stable target: creating a responsive site that works well most of the time on most browsers is doable, but difficult; an app imposes more requirements and limitations, but it’s easier to test and ensure results that more likely conform to your design requirements. (Even with Android’s hundreds of screen sizes, this appears to be true, and now iOS designers are dealing with similar issues having many, not hundreds, of screen dimensions.)

But beyond interface flexibility, why put the huge development dollars and/or sweat of one’s brow into a native app, which is necessarily limited to a specific environment and requires frequent updating to meet the ongoing operating system changes imposed by the platform’s owner? The Web changes, too, but more slowly; browser updates don’t typically break features in most Web apps, but offer more improvements to take advantage of.

Some apps need lower-level access to the OS to be effective. Could Marco Arment have programmed The Magazine‘s initial app as a responsive Web site? Almost certainly yes. I’ve seen slick Web-only publications that have most of the spit and polish of Marco’s first app. The most important parts of The Magazine‘s app aren’t in the user interface part, as I’ll explain in a moment.

Could Marco have created Overcast as a Web app? Almost certainly not. For Apps that interact with audio and video, and most games of any sophistication, being able to delve deep and tune performance, latency, and interaction are key.

But most apps don’t offer audio, video, or game elements that need native code. There are so many examples of how browsers that comprehensively support HTML5 and CSS3’s features, and have highly optimized JavaScript, can accomplish a surprisingly large amount of what native apps do. So why bother?

I’d argue that it boils down to several app ecosystem features, rather than native code advantages. When there’s a genuine choice between building a Web app or native app, and when audience and revenue are important, the ecosystem makes the difference.

Let me take The Magazine as an example, since I’ve lived with it for over two years, and most of that as its owner. What does Apple offer (and Google and other platforms as well)?

• Discovery. Newsstand in particular, but the App Store, the Google Play store, the Amazon App Store, and other marketplaces in general, were supposed to provide a focus for connecting users with the best apps or the apps they needed for a particular purpose. Newsstand in particular allows displaying new covers for each issue, one of the selling points of that section and programming approach, to appear in iTunes.

• Payment. Tying into an existing payment infrastructure like iTunes, Amazon, or Google Play is huge. Anything that allows a user to tap and possibly enter a password rather than fill out a credit-card form is enormously more likely to capture payments.

• Notifications. Once an app is installed, a developer can send messages to users. While that’s an opt-in feature and there are a variety of limits, developers can talk directly to their most interested users, and let them know when something’s new; in my case, that’s new issues.

• Background downloading. Once a Newsstand-only feature, background downloading in iOS for apps allows new content to appear and be available offline with no additional effort. This was critical for a publication, but incredibly useful for other apps, such as podcasting ones.

• Offline experience. Apps are typically required to be resilient and cope with a not-always-on world. All code is always available for retrieval, even if necessary data isn’t. Caching and background downloading allows for access without a user having to plan ahead to retrieve items and be sure they’re available, such as back issues. (I have never had as many complaints as when we switched platforms with our 2.0 release, as the 1.0 cache couldn’t be retained. People who had downloaded every issue were peeved that they had to download again.)

• Piracy resistance. Apps are supposedly harder to crack and resell, although in practice there’s less of an advantage. However, tied into the iTunes infrastructure, The Magazine could check receipts before delivering issues or allowing new downloads, which prevented any easy method of bypassing purchasing its content.

• Official imprimatur. Even though all the app stores say that being included for sale or download isn’t an official endorsement, it really is, because the firms put their names behind their stores. This makes an app-based product more inherently credible, even when an unknown quantity, than a Web app-based one.

Can the Web compare on any or all of these fronts? Not entirely. On the five key elements:

• Discovery. The Web is a huge place, and it’s hard to get people’s attention. But, so, too are all the app stores, where poor integration of social-networking recommendations or other cues make it difficult to scan past the first level of popular or top-grossing apps.

• Payment. Amazon Payments is a completely reasonable alternative to iTunes or Play. While Apple has upped the ante with Touch ID payments, bypassing a password, that only applies to a subset of iOS users. Hundreds of millions of people are buying mobile things by entering a password or more. Not everyone loves Amazon or its payments system, which seems like it was designed in 1999 and never examined since. But Kickstarter has built its entire American ecosystem on top of Amazon Payments, both in its desktop and mobile versions, and its growth is strong. (Amazon Payments takes about 3% to 5% in fees, depending on the card type. Any Amazon account can be used to pay.)

• Notifications. This is a key problem, and one I’ve faced at The Magazine. We had a few months of problems with APN (Apple Push Notification), which I was unable to solve. We switched to the TypeEngine platform, which relies on Urban Airship to process APNs, and which is completely reliable. There is no similar mechanism available for the Web at large, although individual desktop browsers—like Safari on the Mac—offer opt-in notifications.

• Background downloading. There’s no way to simulate background downloading in a Web app. The app needs to be active in a browser window. You can imagine why. If a Web app were allowed to download, it could consume bandwidth, storage, and battery life all at once. Native apps are put on various diets and native code has to interact with parts of the OS to negotiate for downloads, mediating whether someone is on a Wi-Fi network, degrading gracefully when the network is intermittent or unavailable, or halting when storage begins to fill up.

• Offline experience. While HTML5 allows for local browser database caching of content, which is powerful and works well, there are limits. Browsers typically only allow a certain amount of data and flush it when limits are exceeded by a given domain or when other domains put pressure on storage; a Web app can’t entirely rely on a database object always being present. That’s a problem for any content, unless it’s extremely stripped-down text. But even then, the cache isn’t reliable.

These factors, more than any other except the cost of development, push developers to and from native apps. Development costs can’t be understated, because it is simply easier to create highly functional Web apps at a lower cost than multi-platform native apps for multiple reasons, including the openness of Web standards and libraries that can be integrated; the lower level of programming expertise or commitment required (I can program JavaScript, perl, and PHP; I cannot write Objective C, C++, or C#); and the lower cost of Web developers compared to the highly in-demand smaller segment of capable native mobile app coders.

I can sit down and in my spare time write a pretty neat, high-utility, database-driven Web app. I’ve done it before and will probably do it again. But I’m not Marco Arment or one of his ilk: I can’t sit down and by dint of hard effort produce a similarly competent and functional iOS app.

For most startups, the choice is simple: multi-platform native apps are required as the point of entry to be taken seriously, more because of the native app’s ecosystem advantages than any particular function. As I look at major startups’ apps, most of them are mostly Web-based experiences viewed, as Gruber has written, with one less layer of intermediation. But being able to carry out background actions, popup notifications, and accept native payments on the platform are part of how they’re evaluated by reviewers, investors, analysts, and users.

Other businesses make more determined choices, in which the app development cost isn’t the biggest part of their budget, and a native app versus a Web app is less about money and more about message or experience. I know some publications are pulling away from the cost of maintaining apps across multiple platforms and returning to the robustness of responsive Web sites, because it’s the only affordable and sane way for them to proceed. Others are adopting platforms to avoid the cost of continuing development of their own apps, as I did at The Magazine as a tiny fish in a big pond.

The future of the Web could be aided by pushing Web browsers to have more native OS features. But because native apps are captive for direct sales and in-app digital purchases, it’s unlikely operating system makers have any interest in going beyond the HTML5 and JavaScript features they’ve already supported. It doesn’t benefit them, even though it might make for a more robust ecosystem, and further blur the line between Web apps and native apps.

[Jason and Glenn discuss many of these issues in episode 7 of The Periodicalist.]

[Glenn Fleishman is a Macworld contributor, Jeopardy champion, and serial Kickstarterer. He's currently working on the book How Comics Were Made.]

If you appreciate articles like this one, support us by becoming a Six Colors subscriber. Subscribers get access to an exclusive podcast, members-only stories, and a special community.