When Will The Web Replace Native Mobile Apps? (Part II)
By: Sam Dods
Tags: Mobile App Development, Engineering, Progressive Web App, Mobile, Web Development

Let’s dive into a bit more detail on each of the considerations above.

1. Limited device integration

It’s not only iOS that restricts hardware and OS integration. The web is always playing catch up to device hardware. Google promotes the development of PWAs, but, given the large number of device manufacturers, it’s not always the case that the hardware, OS and website play nicely together.

There are still features that a web app can’t access even on Android. NFC, biometrics, geo-fencing are a few. Access to some OS features such as composing messages is also unavailable, although support in this area is evolving rapidly.

2. Limitations of data storage and cache

Like all aspects of PWAs, data storage and caching are handled differently per browser and are restricted to a percentage of device capacity, which makes them difficult to rely on. Most browsers allow enough data to be stored for the majority of use cases (e.g. up to 5GB on 128GB device), but Safari places stricter limits. Up to ~500MB of database storage is allowed, but cache is limited to ~50MB. Both may be cleared by iOS at any point, so must be treated as a temporary and not relied upon.

For developers to rely on PWAs to provide the best user experience, they need to know they can rely on data storage when needed. This is particularly important for apps that download and store locally lots of large files, such as images, videos, audio or PDFs.

Furthermore, I think the offline ability of a PWA is a gimmick. Even most native apps require an internet connection to offer much value, and promising your users offline availability will only lead to disappointment when they discover parts of the app that are not cached.

3. Restricted background functionality

Chrome allows PWAs to wake up in the background to carry out network activity and processing. However, other browsers do not support background processing and even on Android with Chrome, background functionality is not as extensive as it is for native apps.

For example, accessing the user’s location is not supported in the background.

Maintaining Bluetooth connections is not possible in the background (or even between page loads), regardless of operating system or browser.

Voice-over-IP does not integrate with the incoming call facility like it does for native apps.

iOS prevents any background processing at all. This means local notifications aren’t supported, background audio is not supported, and background network activity and other processing is not possible.

4. Impact on user interface

There remains an issue of responsiveness of web vs. non-web. By non-web, I mean native apps and apps developed using other cross-platform technologies beside web. And by responsiveness, I mean the speed with which you feel the result of any interaction.

Delays might be seen when reloading previous screens (pages) when navigating back, or controls might become unresponsive at times. Animated transitions, which are often used to maintain orientation within context, are not as prevalent or are jerky in web apps.

All new “screens” (or “views”) are loaded in place and standard browser forward/back navigation is supported. However other app navigation techniques, such as modal presentations/overlays, are not supported in the same way as they are by native apps. (Although, admittedly, this is the web, so anything is technically possible.)

5. App sales and in-app purchases not possible

A big one is monetisation. App Store distribution, whether on iOS or Android, has given developers an easy way to make money from paid apps and in-app purchases. Users already have an account setup that removes the friction of paying a developer for their software. They can easily pay for an app at point of download, or later to unlock premium functionality.

Paying for a digital product on the web is not so straightforward. It requires a developer to implement their own payment mechanism, albeit through a third party. It will also most likely require some sign up process to verify in the future that a user has paid. Apple’s App Store and Google’s Play Store handle all of that, making it simple for the developer and the consumer.

This will be a major blocker for businesses that make money directly from the software (rather than using their software as a platform for the sale of physical goods).

6. Lack of watch, widget or peripheral integration

It’s not currently possible to provide an Android widget as part of a PWA and, as you might expect, the same is true for iOS. It’s also not possible for a PWA running on iOS to interact with the Apple Watch, nor can a PWA running on Android interact with an Android Wear app. Because Bluetooth connections cannot be maintained in the background, it’s also difficult to work with third-party devices from PWAs.

If integration with watches, providing widgets, or possibly integrating with other devices (think: eyewear or in-home technology) is part of your user experience, then a PWA will not be suitable at this time.