Progressive Web Apps (PWAs) represent a new way to approach mobile web development. Through a series of new APIs and development guidelines, PWAs attempt to make mobile web apps feel a lot more like natively installed applications.
Snippets from the Chrome Developer Summit schedule. The conference had four PWA-related talks on day 1.
Why all the hype? PWAs open the door to a lot of really useful functionality for web apps, including the following.
The site pwastats.com includes an impressive list of case studies from companies that have switched to Progressive Web Apps. As the stats show, many of these companies have not only improved performance metrics like load time, but also business-centric metrics like engagement and customer acquisition rates.
For example, Twitter found that users sent out 75% more tweets when they upgraded their web app to a PWA.
The Twitter Lite case study from pwastats.com
And the India-based e-commerce site Flipkart was able to increase its new customer acquisition by 50% using a PWA.
The Flipkart case study from pwastats.com
Why have PWAs been so successful when many other attempts to make the mobile web more like native apps have failed?
One reason is the design of the Progressive Web App APIs themselves, as the two primary technologies behind PWAs—service workers and web app manifest files—were designed with graceful degradation in mind. Meaning, you can start using service workers and manifest files for browsers that support the APIs today, and not worry about breaking your app in browsers that do not yet have support for these features.
This design has been key to the success of PWAs, as iOS—aka the second biggest mobile platform out there—did not support service workers or web app manifest for the years PWAs surged in popularity.
NOTE: Apple recently announced plans to ship support for service workers and web app manifests as part of an the upcoming iOS 11.3 release 🎉.
Yet, despite the lack of iOS support for years, PWAs have been able to succeed where many similar technologies have failed because their APIs degrade gracefully. In fact, many companies saw increased 2017 iOS conversion rates by rethinking their mobile experiences using a Progressive Web App. For example the e-commerce site AliExpress saw a 82% increase in iOS conversion rates with their PWA.
A Google case study showing how the site AliExpress improved their conversation rates with a PWA—even on iOS.
But despite being a well designed technology, PWAs are not the solution for all mobile needs. At the end of the day PWAs are web apps, and as such, they are subject to the same limitations as any web app—such as having limited device API access, and having performance characteristics that are very reliant on the browser they’re running in.
What separates JS-driven native frameworks from Cordova-based approaches is that JS-driven native frameworks use native user interface components, and therefore abandon web concepts like HTML and the DOM. For example, the following gif shows off a sample NativeScript app in action.
UINavigationBar on iOS or a
Toolbar on Android, because you’re using those elements already.
For example, here is how the NativeScript
<ActionBar> UI component renders on iOS and Android.
<ActionBar> component renders a
UINavigationBar on iOS (left), and as a
Toolbar on Android (right).
Using native user interface components also means you can leverage some really powerful native constructs that aren’t present on the web. For example, suppose you want to build an endless scrolling list with tens of thousands of items. On the web you have to concern yourself with non-trivial concepts like virtual DOMs to avoid performance problems. But in native apps, iOS and Android both provide list controls that automatically handle the tasks of memory management for you. For example, here’s how a list in NativeScript performs if you casually throw 50,000 items in it (notice how little the scroll bar on the right moves).
A NativeScript app that lists 50,000 items. You can see the source code for this app and try it for yourself on the NativeScript Playground.
<ListView> works in NativeScript, or how a
<FlatList> works in React Native. And if you want to customize your lists beyond what frameworks like NativeScript and React Native offer out of the box, you’ll have to deal with the not-especially-intuitive iOS and Android APIs that make these controls possible.
For most situations your default platform should be the web, and therefore your default mobile app choice should be a PWA. When compared to native applications, the web is much easier to build for, the web is easier to deploy to, the web lets you reach more users, and the web makes it easier for users to access your apps.
That being said, despite the many advantages the web platform provides, the web is not the best choice for all app usage scenarios. Although there are several situations you could argue native apps are a better fit, there’s one big one—when you need to do something the web simply can’t do.
Whenever I make this argument to web advocates I’m inevitably sent to a site like What Web Can Do Today, which lists an out the various APIs that the web platform now supports.
The site What Web Can Do Today lists a large collection of mobile APIs, and marks the API your current browser supports.
Although the web can legitimately do a lot of things, the web can in no way keep up with what native platforms make possible. On the surface this means that if you want to work with the latest and greatest features that mobile devices offer, which nowadays are APIs like augmented reality, machine learning, and the internet of things, chances are you need to build native apps.
And while that is relevant to this discussion, your average developer isn’t busting out augmented reality to polish their next sales dashboard or checkout form. The more pragmatic discussion is considering just how much more native apps can do with more mundane features that you don’t think too much about. Let me give you a few examples to show my point.
Mobile banking apps commonly use native APIs to add an overlay to the camera, making depositing checks a little bit easier for users.
Because Google Maps is a native app, it has the ability to track a user’s location in the background.
There are countless examples where native does more than the web with the same APIs.
What you should do is consider whether some of the features of native apps would help you build a better app for your users, and if so, take a serious look at what frameworks like NativeScript and React Native can do. And maybe even consider building for multiple platforms at the same time.
Although PWA advocates like to say that all apps should be web apps, and iOS and Android advocates like to claim that all apps are best made with native code, the truth is each platform has a unique set of advantages that complement each other. Luke Wroblewski might have said it best in a 2016 article.
“The Web is for audience reach and native apps are for rich experiences. Both are strategic. Both are valuable. So when it comes to mobile, it’s not Web vs. Native. It’s both.”
No one is going to argue that the web doesn’t have a greater reach. Because the web isn’t restricted to app stores run by companies like Apple and Google, the web is certainly the place to go if you want to reach the most users.
But web advocates like myself often have a hard time swallowing just how much time users spend using native iOS and Android applications. Data from Flurry Analytics, for instance, shows that mobile browser usage in the United States has fallen to a staggeringly low 8% of user’s time.
The time an average mobile user spends on devices in a day, including how much of that time is spent in a web browser. Side note: holy crap, five hours a day is average 😮
Yes, this is only United States data, and yes, most of the user’s time in native apps is spent in a small handful of apps like Facebook, but still—92% versus 8% is an absolutely enormous gap in usage.
But one recent trend we’ve seen is developers increasingly trying to build PWAs and native apps using not only the same language, but also the same codebase. For example the React Native community has React Native for Web, a project that allows React Native users to render their React Native projects as web applications.
The React Native for Web project allows users to render React Native projects on the web.
The NativeScript community has built a number of seed projects that allow NativeScript users to build web and native applications from one Angular codebase. For example Team Maestro’s Angular NativeScript seed provides a number of conventions and CLI scripts that simplify the process of building for multiple platforms.
The NativeScript Angular Seed allows NativeScript users to build web and native apps from one Angular codebase.
From a business perspective these approaches make a lot of sense, as the ability to consolidate your application development to one team and one language has the potential to save you a lot of time and hassle. And although this technique is relatively new, we’re already seeing evidence that it can work for companies building real apps. For example, uGroupMedia Inc’s Portable North Pole app, an app with roughly 1 million users per day during the holidays, was able to save 60% of their code by using NativeScript and Angular to build for the web, iOS, and Android simultaneously.
Which approach you want to use depends on your own application needs. Starting with a Progressive Web App makes a lot of sense unless your apps needs APIs or features of native development platforms. Building for both web and native is growing trend, as it enables you to leverage the best features of each platform.
TJ VanToll is a frontend developer, author, and a former principal developer advocate for Progress.
Subscribe to be the first to get our expert-written articles and tutorials for developers!
All fields are required