What are Progressive Web Apps? — The Pros and Cons and How They’re Different from Native Apps
It’s much easier to find and visit a website than it is to install an application. Just launch your browser, type in a URL and you’re good to go.
Sharing is simple too. You can share a simple URL link with your friend and as long as they have an up-to-date browser and internet connection, they will be able to access the website as well.
Imagine if you had to download the Amazon app if you wanted to browse or if anyone wanted to share a product with you through your phone. The user experience is doable, however, it takes much longer. Thankfully, we can open Amazon through our phone’s browser and share products with URLs.
However, despite a long process to download a native app, they are better integrated with the device’s operating system. This allows developers to do create seamless user experiences and take full advantage of all the native APIs that the platform offers.
For example, iOS developers can configure their applications to send and retrieve push notifications for their iOS applications, make use of MLKit and ARKit, connect with your Apple Watch and much more. These are things that websites, even when visited through a mobile device, cannot do.
That’s where Progressive Web Apps (PWAs) come in and are looking to solve the problem of bridging the gap of what is possible with a website and a native application. It gives us the ability to create web apps that can match certain features that used to only be reserved for native applications.
These “certain features” are not a static list of features either. As the community and support for PWAs grow, new features and APIs are created to further grow the list of native app features we can imitate with a PWA. For example, with the release of iOS 13 and 14, Apple updated their support for PWAs so that they can work on iOS Safari.
But before further comparing progressive web applications and native apps, let’s get a clearer understanding of what a progressive web application is.
Defining Progressive Web Apps
Progressive Web Applications are web applications that make special use of Service Workers, Web Manifest files and other Web-platform APIs to provide a user experience that is indistinguishable from a native application.
A Service Worker is just some Javascript that runs in the background of your web browser and is the backbone of progressive web apps. Without service workers, we could not create progressive web applications. This is because, without some background worker, the user’s browser couldn’t process incoming network requests or even be able to cache the application.
Web Manifest files contain meta-information (information about your app) about your application. For example, what the name is, a description of what it does, what the start URL is and much more.
One common and important piece of meta-information is a link to the application’s icon. Since progressive web apps can be added to the home screen of a phone, the app icon is what will be used.
If you’re curious about all the different fields that Web Manifest files accept and what behavior it causes, check out this guide.
Finally, PWAs include the word “progressive” in their name because they can be run on older browsers with fallback support. Essentially, the feature enhancements are “progressively” upgraded to match what the user’s browser can do.
So now that we have a better understanding of what a progressive web application is, let’s get back to the question of how exactly do they differ from native applications?
Native Applications vs. Progressive Web Apps
Every day, what is possible with a PWA is expanding as more work is done, however, there are still certain key differences that you should be aware of.
Programming Languages
For starters, native applications are generally written with languages such as Swift (for iOS), Java or Kotlin (for Android), C# (for cross-platform development with Xamarin) and many others. They can be found and downloaded directly to the user’s phone through some dedicated app stores such as the Apple App Store or the Google Play Store.
On the other hand, PWAs consist of more familiar web languages such as Javascript. This means that your React web application can become a PWA as well. They can be found through a web browser with the option of “adding” them to your home screen (note: not all browsers and platforms will prompt the user to add the web app to their home screen).
Depth of Features
Native applications are generally going to be able to access more of what the operating system offers to developers. On the other hand, a PWA is going to be limited to whatever is supported at the time.
For example, just recently with the release of iOS 13.3, partial support was introduced for the Web Authentication API, which allows for developers to access authentication systems of the operating system. This meant that developers could now allow users to log in to their web app using Touch ID or Face ID. Before the release of iOS 13.3, you would have to make a native application to allow users to log in with Touch ID or Face ID.
Similarly, there are other features that are supported natively, however, have yet to be supported through a web browser.
Furthermore, companies, like Apple, can choose to allow certain features to only work through native applications and not through a browser. For example, on iOS, there is no support for push notifications through Safari. However, if you built a native iOS app, you would have the ability to integrate push notifications.
Platform Reach
If you take the route of building native applications, you’ll have to build a native application for each different platform: iOS, Android, etc. There are JavaScript frameworks such as React Native or Flutter that allow you to create cross-platform applications with a single codebase, however, those frameworks have their own downsides as well.
On the other hand, a PWA is accessible to both desktop and mobile users all through a single codebase without having to use some fancy Javascript framework to build a native application.
The only difference will be which platform your target audience will use to reach your app. For a native application, they will be found and distributed through some app store whereas a progressive web app will be found and distributed by a browser and URL.
So ultimately, there are still trade-offs between building a native application and a PWA. For example, if your application requires too many features that are not yet supported by PWAs, it would be better to build a native application.
However, if you still believe that a PWA is something that you would like to build and is the best route for you, let’s take look at how PWAs work.
How Progressive Web Apps Work
Progressive web apps need three main components: an HTTPS connection, a Web App Manifest file and a service worker.
HTTPS Connection
First of all, PWAs require an HTTPS connection. Your web server must provide an SSL certificate, which you can install for free these days with Let’s Encrypt.
This is needed because unlike a native app, which is packaged as some file on an already secured app store, your PWA is served from some web server that you control. In order to ensure security while delivering the app, an HTTPS connection is required.
Web Manifest
Next, you need to define meta-information about your app using a Web Manifest file. The Web Manifest file is just a simple JSON file that has keys for all the necessary meta-information (ex. the app’s name, language, icon, start URL, orientation, scope and much more).
By changing the values in the Web Manifest file, you can tell the user’s browser how to handle your application. For example, by editing the value of background_color , you can change the color of the splash screen which is shown when your PWA is launched from the home screen.
Service Worker
Finally, and most importantly, we have the service worker. As stated before, this is a Javascript file that runs in the background of the user’s web browser. It is what provides all the core functionality of a PWA.
Generally, developers tend to use service workers to control how the browser handles network requests and caching. This allows for background syncing and running the app offline.
Now that we understand the three main components needed for building a PWA, we need to understand the architecture of a PWA so we can understand how each piece fits together.
The Application Shell Architecture
A well-architected PWA generally follows the “shell” architecture.
The “shell” architecture advocates for caching a “shell” of your application so that it can be run offline. The app “shell” is the bare minimum HTML, CSS and Javascript required to power the user interface.
A shell can consist of empty state components to show a default user interface when the app runs offline. You can also cache data in your shell so that you can build a user interface with real data as well.
The first time that the app is requested from a user’s browser, your web server will return the application. A service worker on the user’s browser will then cache your app’s “shell”.
Now, when the visitor comes back to your app, the service worker on the user’s browser will intercept the request being sent to get your app and return the cached shell of your app. This allows the user’s browser to quickly load a user interface without any network calls. Even if data is ultimately going to be pulled to power certain parts of the user interface, quickly showing a user interface can increase perceived performance.
The “shell” architecture approach relies aggressively on you, the developer, caching the shell. However, you must carefully consider what should be cached since it comes at a cost: storage.
You cannot cache too little or else you’re not taking full advantage of what you can do offline. On the contrary, you cannot cache too much or else your app can end up taking up too much storage.
Once the shell has been loaded, generally the dynamic content will then be loaded in once a response is received. For example, an app that has cached the app shell with some data can quickly display a user interface with the cached data when the screen first loads up. At the same time, a network request for more data can be made to update the user interface with the latest data.
By following the “shell” architecture, you are able to quickly load up a basic user interface for your application even when offline. This is just one benefit that a PWA offers over a traditional website.
Let’s further explore what benefits PWAs offer over traditional websites along with the downsides and what to look out for.
Benefits and Downsides of PWAs
With anything in life, there are pros and cons and PWAs are no different. Although there are some downsides, PWAs do have nice benefits that can make it worth the time to build a PWA.
Benefit 1 — Immediately Update the Application
When updating a native application that is distributed through an app store, you will have to generally submit your update for review. How long the review takes depends on which company is handling it, what time of the year it is and many other things out of your control.
For a company that needs to push out updates quickly, maybe even multiple times a day, they can’t really afford to wait that long.
However, with PWAs, developers can update the application immediately. This is because the application is hosted directly from some web server that you control. With a proper CI/CD and QA pipeline, a company could confidently push out multiple updates to their application without having to wait on external factors.
Benefit 2 — Runs on Multiple Platforms
When building native applications, if you desire for your app to be on multiple platforms, you must build one native app for each. Each app store will need to have its own version of the app which can double or triple the amount of development work needed to be done.
Imagine that you’re a startup looking for a product-market fit for your mobile app. If the decision is made to build native mobile apps for both iOS and Android, then you will have to make two versions of the same app. One for the iOS App Store and one for the Google Play Store.
The iOS app will need to be coded in Swift and if you would like to test it out on a real iOS device, you’ll need a Mac. As for the Android app, you’ll either use Java or Kotlin, however, you can test your mobile app on a real Android device from either Mac or Windows.
But you’re essentially building the same app twice. That’s a lot of extra money and what feels like duplicate labor for the startup.
PWAs can help with that because they run on all platforms and browsers. It doesn’t matter if the PWA is visited from an Android device or an iOS device because it will behave the same. Any updates you push as well will be applied for all platforms too.
That can help save a huge amount of time, energy and money for a small startup just looking for product-market fit.
Benefit 3 — Offline Support and Background Sync
Service workers allow us to cache a shell of our application along with any live data that we would like accessible offline. Whenever the application is then launched offline, the cached shell is retrieved from memory and used to render a user interface. If we also cache live data, we can display some content on the app while offline as well.
For example, news organizations using PWAs have readers’ browsers cache a set amount of stories that can be viewed even when offline. Furthermore, at a set interval, the news app can download new stories in the background to keep the content fresh even if the app is launched when offline.
This mimics the behavior that native applications have since they can generally run even offline, even if just limited capability.
Benefit 4 — Push Notifications
Imagine if you could ask your website visitors to receive push notifications from you. From there, for the ones who accepted, anytime you publish a new blog, you could send them a push notification. It would be great for marketing, however, regular web applications don’t allow us to do that.
Fortunately though, with PWAs, we are able to send push notifications…on certain platforms. As mentioned before, Apple chooses not to allow for push notifications for PWAs. However, this does not mean that you cannot configure push notifications for users that use Chrome or Android.
I recommend this Medium article to get into the technical details for implement push notifications for your PWA.
Now onto all the downsides and things to consider about progressive web apps.
Downside 1 — Not as Powerful as Native Apps
Since PWAs are lightweight compared to a native application, they are generally not going to be as capable as a fully native application. Despite the growing community and support, there’s still work to be done for bridging the gap.
Certain features like camera access, geolocation and authentication have officially supported web APIs that your PWA can use. Other features such as Bluetooth support are currently only available for a limited number of platforms.
Taking some time to design out what your application needs to do can help you decide whether or not you should build a PWA or a native app.
Downside 2 — iOS App Store Traffic
Currently, Apple does not allow you to publish your PWA to the iOS App Store. This means that you could potentially be losing out on potential downloads that come from the traffic on the iOS App Store.
If you expect a good chunk of your business to come from iOS App Store traffic, a PWA may make it hard for you to gain traction. It’s important to keep the business goals in mind before jumping into building out a PWA.
Downside 3 — Lagging Browser Support
Despite growing support for what PWAs can do, there are always going to be some browsers and devices that don’t fully support all the bleeding edge technology.
If a large set of your target audience favors a particular browser over another, it may be smart to think which Web API features are supported by the browser.
Conclusion
Websites are easy to access and share, however, limited in their capabilities when compared to what native applications can do. Progressive Web Applications aim to help bridge that gap.
With the use of Service Workers, Web Manifest files and other Web API features, your mobile web application can start to behave more like a native mobile application.
PWAs give you many advantages over a regular web application, including:
- Ability to update your app immediately since the code is served from a web server that you control, not some other company’s app store
- Being able to run the same app on any device and platform that has an up-to-date web browser installed
- Providing offline support and background sync so that users can access content even when disconnected or have a spotty internet connection
If you’re looking to start building a PWA with React or convert an existing React app into a PWA, I would recommend checking out this Medium article that goes over the technical process.
As support grows for progressive web apps, we can expect the capabilities and potential features to grow. Learning how to build progressive web applications now could potentially set you up for doing something brand new that can provide tons of value to your customers and your business or employer.
