The 'Native vs. Web' Mobile App Conundrum: Handling Offline

It's an eternal back-and-forth tug of war between native vs. Web apps in the mobile development arena. Announcements of major companies switching from one to the other abound. As do surveys claiming to show one approach is currently in favor amongst the coding masses (just pay attention to who conducted the survey and, perhaps, why -- is there "skin in the game"?).

The latest "why we switched" article I read, however, is fascinating to me on several levels, including its highlighting of the Web app offline conundrum -- how do you continue to engage users when there's no Internet connection?

"Goodbye, Native Mobile Apps" was written by the longform journalism producer, The Atavist Magazine, which sells its own Atavist publishing platform -- and which promises a "new approach" to overcome that problematic offline thing.

The article delves into the thinking behind its abandonment of the native approach to move strictly to the Web to service its mobile readers. It states:

Ultimately, whatever small slice of attention we were gaining by having our app on some people's home screens was outweighed by the technical, business, and design considerations that had piled up against it.

Those home screens seem to be almost exclusively on iOS devices, however, as Android was only mentioned once in passing as an app afterthought. And the authors had some critical comments about Apple in explaining their decision, including the typical two-week process of App Store re-approval after app coding changes, whereas on the Web, they can be enacted immediately.

Also, advantages of the native approach that prompted their original decision to start with an iOS app dimmed over the last four years or so as Web technology caught up with the emergence of HTML5. However, it hadn't become mainstream when they launched in early 2011, and, "Outside of the app world, there were also very limited options for offline reading -- this in an era when not all devices tended to be online as constantly as they are now."

But even with more connectivity today, that offline conundrum still faces them. "Of course, the mobile Web isn't perfect: There are still offline reading issues -- we're working on our own new approach to that." I'm anxious to find out what that "new approach" is and have enquired about it, but I hadn't received a response yet (unfortunately, ADTmag isn't longform journalism and deadlines are more immediate). I'll update this article if I get an answer.

So what's a mobile Web app developer to do about that pesky offline problem in the meantime, as we await a "new approach?"

Fortunately, our coding friends at Hacker News have come to the rescue.

"How do you deal with offline support?" a commenter named st3fan asked. "If I'm not connected and I want to read an article, where do I go? Can't open the Web site."

"owencm" supplied a few answers, including Service Workers, Application Cache and the "Add to Homescreen" functionality in certain browsers. Let's take a look at these options.

Service Worker
"Rich offline experiences, periodic background syncs, push notifications -- functionality that would normally require a native application -- are coming to the Web," HTML5 Rocks wrote last December. "Service Workers provide the technical foundation that all these features will rely on."

Service Workers are a new approach detailed in a working draft of the W3C standards body, published in June. The spec, according to the W3C, will let Web apps "take advantage of persistent background processing, including hooks to enable bootstrapping of Web applications while offline."

However, the Mozilla Developer Network (MDN) emphasizes that "this is an experimental technology" in an article about the Service Worker API last updated two days ago. The article explains:

Service Workers essentially act as proxy servers that sit between Web applications, and the browser and network (when available.) They are intended to (amongst other things) enable the creation of effective offline experiences, intercepting network requests and taking appropriate action based on whether the network is available and updated assets reside on the server. They will also allow access to push notifications and background sync APIs.

On GitHub, a Service Workers project explains the technology was developed in response to declarative-only solutions such as Google Gears, Dojo Offline and HTML5 Application Cache that have "failed to deliver on the promise" of solving offline problems. "Each successive declarative-only approach failed in many of the same ways, so the Service Worker effort has taken a different design approach: a largely-imperative system that puts developers firmly in control."

The GitHub project said the Service Worker approach is being developed to answer ongoing issues about the Web platform, including:

• An inability to explain (in the Extensible Web Manifesto sense) HTTP caching and high-level HTTP interactions like the HTML5 Application Cache.
• Difficulty in building offline-first Web applications in a natural way.
• The lack of a background execution context which many proposed capabilities could make use of.

The HTML5 Rocks article emphasized the technology's core feature of intercepting and handling network requests, letting developers programmatically control the management of a cache of responses. Things to note about Service Workers, the site said, include:

• It's a JavaScript Worker, so it can't access the DOM directly. Instead, a Service Worker can communicate with the pages it controls by responding to messages sent via the postMessage interface, and those pages can manipulate the DOM if needed.
• Service Worker is a programmable network proxy, allowing you to control how network requests from your page are handled.
• It will be terminated when not in use, and restarted when it's next needed, so you cannot rely on global state within a service worker's onfetch and onmessage handlers. If there is information that you need to persist and reuse across restarts, service workers do have access to the IndexedDB API.
• Service Workers make extensive use of promises, so if you're new to promises, then you should stop reading this and check out Jake Archibald's article.

HTML5 Rocks, like the GitHub explainer, also noted that the Service Worker approach attempt to address HTML5 Application Cache drawbacks. In the meantime, the Application Cache is another offline option listed by owencm, the Hacker News commentator.

Application Cache
Though described by owencm as being "fully supported in the stable [Web browser] versions for a while now," be warned that this technology is on the way out, though that can take a long time.

According to the WHATWG community "HTML Living Standard" site, HTML offline Web applications let developers specify files to cache for offline use. "In order to enable users to continue interacting with Web applications and documents even when their network connection is unavailable -- for instance, because they are traveling outside of their ISP's coverage area -- authors can provide a manifest which lists the files that are needed for the Web application to work offline and which causes the user's browser to keep a copy of the files for use offline."

However, the site warns: "This feature is in the process of being removed from the Web platform. (This is a long process that takes many years.) Using any of the offline Web application features at this time is highly discouraged. Use Service Workers instead."

The MDN repeats the warning. "This feature has been removed from the Web standards," the site states. "Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time."

Yeah, but what about that Hacker News comment about it still being fully supported and a viable option? Another commenter chimed in: "Application cache is a ____ing nightmare. Service Workers can't come soon enough." Ok then, forget about Application Cache. Let's just move along to:

Add to Homescreen
As noted, this approach applies only to certain browsers. The Chrome version of this technology works only on Android, not iOS. "Since Chrome M31, you can set up your Web app to have an application shortcut icon added to a device's homescreen, and have the app launch in full-screen 'app mode' using Chrome for Android's 'Add to homescreen' menu item," the Chrome developer site states.

"New in Chrome M39, you can define the metadata associated with your Web application in a JSON-based manifest," the site continues. "The manifest provides a way to wrap metadata about a Web application into a single file. Using this metadata in conjunction with Add to Homescreen, you can create launch experiences more comparable to native applications."

Similar "add to home screen" functionality is available on Safari, while others claim it can work just about anywhere, but probably not with the desired offline capabilities.

Although this approach has a limited scope and perhaps uneven offline functionality, the Chrome technology is another offline option. With those limitations, however, we're pointed back to Service Workers, awaiting full spec functionality and widespread support. Until we hear about that "new approach" from Atavist, that is. I'll keep you posted.

Posted by David Ramel on September 25, 2015