When Will The Web Replace Native Mobile Apps? (Part I)

What does the future have in store for mobile app development?

With iOS developers everywhere getting excited by the latest WWDC announcements, it’s as good a time as any to consider the future of the good old native mobile app.

Steve Jobs, at the 2007 launch of the iPhone, announced that there would be “no SDK required” to bring apps to the iPhone. He continued:

“If you know how to write apps using the most modern web standards, [you can] write amazing apps for the iPhone today.”

A few moments later, Scott Forstall began:

“Not only am I going to show you how you can build great applications for iPhone using web technologies, but also how your applications running on the iPhone can take advantage of all the built in native services as well.”

Highlights of iPhone app development were displayed as:

• Web 2.0 and AJAX
• Integrate with iPhone services
• Instant distribution
• Easy to update

So where did it all go wrong? Will Apple’s original vision for iPhone apps one day become a reality?

“Write amazing apps for the iPhone, using modern web standards.” — Steve Jobs, 2007

Fast forward 13 years and it seems Apple is actively trying to stunt the progress of web capabilities on iOS.

However, with a global recession causing budget constraints like never before, will businesses still consider it necessary to offer a mobile app when a mobile-optimised website would suffice?

Advancements of web technologies and increased capabilities of progressive web apps (PWAs) are making mobile web a feasible replacement for apps.

But before considering an alternative to apps, it’s useful to contemplate why Apple’s original vision was not realised.

Why apps in the first place?

What changed since Jobs’ 2007 announcement? Why are we so content with websites on desktop, yet prefer to break out of the browser on mobile?

From the developer’s perspective, it might seem nonsensical at first. If we encouraged users to visit our mobile-optimised website, they wouldn’t have to spend time downloading software and we wouldn’t have to force them to update when we have new features or fixes to roll out. But instead, we constantly push them to our mobile app, even if they don’t yet have it installed.

But that’s an important point — installation. It’s not nonsensical for the developer, because once the user has downloaded and installed your app, they’re invested. That user has shown their loyalty and now you must repay them with a superior user experience.

So what about for the user? It only makes sense to download an app if the user believes they’ll be rewarded with a better user experience than that of the mobile website.

It ultimately boils down to user experience. Users don’t want apps. They want to get a job done: check the weather; pay a friend for lunch; rent a car; order a taxi.

Users don’t want apps. They want to get a job done: check the weather; pay a friend for lunch; rent a car; order a taxi.

Why are apps not as popular on desktop?

If apps enable users to achieve their outcomes more effectively than a website, why don’t we encourage users to use apps on desktop like we do on mobile?

1 — For historical reasons

Apps had to exist because mobile web offered a far inferior user experience than desktop web. When smartphones surfaced at the end of the Noughties, responsive web design was in its infancy and very few websites were mobile-optimised. Mobile data speeds were slow and heavy sites designed for desktop took a long time to load.

In October 2007, four months after the initial iPhone launch, Jobs announced that an iPhone SDK would be provided the following spring. Native apps would offer an experience that web apps would not be able to compete with, and, once downloaded, they would launch in an instant. Mobile web had a lot of catching up to do.

2 — Serving different needs

It’s also in part due to differences in how we use mobile compared to desktop. A mobile device has an abundance of hardware features to make it the useful device it is: accelerometer; camera; GPS; microphone; biometrics; NFC; Bluetooth; etc. Websites were historically unable to make use of such components, meaning apps were a necessity in order to make the most of the handset.

There are also operating system features that an app can access, such as contact information, calendar events, message composing and voice assistants. Many of these features are unavailable from mobile websites.

That was then, this is now

Mobile apps had to exist because smartphone technology out-paced mobile web technology.

Mobile serves a different purpose to desktop, and the amount that a developer was able to do within website code was insufficient to the needs of mobile users.

So does the continued evolution of progressive web apps change things?

PWAs aren’t new. The phrase was coined in 2015 and Google has promoted PWA development for Android since then. PWAs have been somewhat supported by iOS since 2017.

PWAs are also heavily endorsed by Microsoft for Windows 10, which runs on several mobile device families, such as Microsoft’s own Surface and PC market-leader Lenovo’s ThinkPad.

PWAs are also supported by desktop PCs and Google recently added support to Chrome to allow PWAs to be launched when your computer starts up.

PWA capabilities per platform

A PWA’s power — and therefore its ability to compete with a native mobile app — is dependent on device manufacturer and operating system version (and also browser, but it’s not so relevant).

(This is just a summary, as there are lots of resources already available that go into great depth.)

Android

Some PWAs on a modern Android phone will be on par with a native Android app. Many of the aforementioned hardware components can be accessed from mobile websites, such as the accelerometer, camera and Bluetooth. PWAs load fast and can cache content for offline use, and there is support for push notifications to keep users engaged.

An app can be “installed” either through the Google Play Store or by adding to the home screen upon visiting the site in the mobile browser. Installing a web app actually generates an APK (Android Package Kit) in the background, which makes it equivalent to any other installed app (although it is still limited to the capabilities of the browser).

Android is leading the pack when it comes to supporting PWAs as “first class citizens” on a user’s device and we can expect continued evolution that sees the gap narrow between web apps and native apps.

Windows 10

The fact that Microsoft is promoting PWA development is important. Windows has almost 80% market share of desktop PCs, which increasingly double-up as mobile devices. Models such as the Surface Pro and ThinkPad have the benefit of many of those hardware components that define a mobile device. Depending on the type of app, e.g. a work-related productivity app, there could be a good business case to support Windows 10 via a PWA.

Microsoft has taken a step to simplify app discovery/distribution by automatically importing web apps to the Microsoft Store when they are indexed by the Bing web crawler. The reason Microsoft is eager to support PWAs to their full extent is because fewer developers build native apps for Windows.

I’m not suggesting that Windows will be a competitor for Android or iOS any time soon. (Windows Phone 7, anyone?) But being promoted by Microsoft means we’re sure to see continued, rapid evolution of PWA development.

iOS

And finally, iOS. Despite Steve Jobs’ original vision for iPhone apps to be developed in “modern web technologies,” Apple now seems reluctant to support progressive web apps to the same extent as Google and Microsoft.

Despite broadcasting to the world that web apps would “integrate with native services,” iOS prevents web apps from interfacing with most of the hardware and operating system. Push notifications are also not supported — they have historically been tightly controlled by Apple even for App Store apps, so whether they will ever be allowed for web apps is unknown.

iOS support for PWAs is limited: web apps can take advantage of caching in order to load faster and store limited data for offline use; and the ability to “install” to the home screen means that a web app is given its own app-like housing, free of Safari. This means it is shown full screen, without the address bar and browser controls, and appears separately in the app switcher.

Steve Jobs cited the benefits of web-based apps as “instant distribution” and “easy to update.” However, Apple is now infamously precious about the kind of apps that may be distributed through the App Store. Unlike Google and Microsoft, it’s hard to imagine Apple ever allowing unvetted web apps into the store — and they can never be vetted, because web apps are dynamic; they could be changed entirely after review.

So where to from here?

Giving an existing website the capabilities that make it fall into the “progressive web app” category isn’t trivial, but it’s not nearly as costly as developing separate iOS and Android apps — or even Windows apps.

The user can still “install” the app, and even just having the app on their home screen ties them in with some level of commitment.

For many use cases the user experience can be pretty close in comparison to a mobile app, but there are also many use cases for which PWAs aren’t suitable, especially if targeting iOS is important.

I’m a native iOS developer, so I should be advocating native development — and I still do, for now — but I also think web advancements will make native development less and less necessary over time.

Of course there will still be professional productivity software that will always be better as native apps, in order to take better advantage of the device’s performance. For example, professional video or music editing, 3D modelling or graphic design products.

However, for businesses providing a service, such as retail, banking, transport and energy, which currently maintain a website as well as a mobile app, the need for a non-web app is guaranteed to reduce as web technology advances.

In Part II, I’ll go into the limitations of PWAs that are preventing me from advocating them over native apps, for now. I’ll also predict innovations we’ll see in the next few years that could make Apple’s original vision a reality — as much as they might now oppose that.