In our last 3 blog entries, we took a deeper dive into the essence of hybrid and cross-platform builds, the benefits they could deliver and even identified some frameworks that could serve you well, especially when native development is not an option.
Those entries were designed to give you an outlook on alternatives to native application development and to extend that topic, we’ve decided to cover the subject of Progressive Web Apps, which seems to be ignored by some of our competitors and worshipped by others.
We’re no strangers to this matter either. There were several instances when some of our customers would require Progressive Web Apps (further as PWAs) as an alternative to native, hybrid or cross-platform development. For each of them, circumstances were different and we had to defend or argue against PWAs – depending on the scope issues we had to solve.
In the base of those experiences, we’d like to share some of that knowledge and hope it would prove useful for those who did not find a hybrid, cross-platform or native build as a viable solution to their business model issues. With these in mind – let’s proceed and see if PWAs are worth your time, efforts and investments.
What is a PWA and how does it work?
First PWAs can be traced back to 2005 before bootstrap and responsive designs emerged. At the time, they were deemed as underperforming, running slower as their native counterparts, requiring an active network connection and performing low-level or basic tasks. Consequently, most developers shifted their focus to Java and Objective-C since native applications delivered significant advantages like offline usage, high availability and snappy interfaces as compared to PWAs.
De Facto, the Progressive Web App term did not exist until 2015, when Alex Russel (a Google Chrome engineer) introduced it as a notion, describing these apps as ones that “aren’t packaged and deployed through stores, they’re just websites that took all the right vitamins.”
That meant users could have their cake and eat it too: no immediate decision to install an app is required. Since PWAs are inherently progressive they could benefit from a flexible web experience through a native-like interface. Quite the win-win scenario.
As a standard definition, Progressive Web Applications are a collection of native APIs, design concepts and technologies that enable a native-like UX within the user’s mobile browser. Simply put: It’s your website’s mobile version on steroids that is acting as any mobile application would.
In essence, PWAs require a React-based website (one based on Handlebars, jQuery with some CSS/SVG animations could also work, as long as it’s a JS standard resource) and compiles it into web views (quite similar to the hybrid development approach) with the help of a progressive enhancement library (like Isomorphic JS).
Arguably, one can enable a PWA in 3 steps (considering your web app follows JS standards). I haven’t written a line of code in a while, but for the sake of the example #challengeaccepted:
STEP 1: according to our front-end team, I must adjust my Web App’s Manifest.json to define the PWA’s purpose, the way it appears on the home screen and the way colours are rendered within the UI:
STEP 2 – To make use of that manifest, I must link it in the head of my HTML, and to make things prettier, I can also set a theme colour, that would define my app’s header look (mostly related to recent versions of iOS and Android):
The same script manages the cache programmatically, enables push notifications and running separate JS threads – delivering more power and control as compared to relying on headers/server/push/prefetch calls. Usually, a well-built web application already has the service-worker.js in its root folder (so is mine). Thus, all I had left to do was to register it in the manifest.js file:
Once I was done registering, I needed to “inform” our worker about required paths to be used as cache:
Now, to add a bit of failsafe in caching, I tweaked some lines in the service worker file to force all those paths and their containing files to cache more often (if you’ll attempt this – you’re on your own – so be careful):
This allows the service worker to go through a loop and fetch content via a network, for every single root declared via that FilesToCache variable. Now, to make sure offline requests updates the cache, I’ve added another JS bit in the service-worker file:
The above one is a simple caching strategy that makes sure any requests can be answered via cache right away. If the request cannot be completed via cached content, the app will fetch data via available networks to render a particular web view. Depending on the situation and the app’s complexity – you might add some extra lines of code.
Now, as proven above, even an enthusiast with a long-forgotten coding skill can build a PWA with as little as 40 lines of JS code and some configs. By the way, here’s the result:
In theory, you can run your web app on a mobile device, delivering public users an APP-like experience, without having to upload anything to app stores.
One might even categorise PWAs as cross-platform. However, there’s a lot more to consider, especially since web technologies still have a lot to accomplish until PWAs could replace native or hybrid builds altogether.
Are there any pros and cons to consider before building a PWA?
As in the case of native vs hybrid builds (including cross-platform), there is a lot to consider before going with a PWA, especially when we’re touching particular business models.
To put it short: if your build requires anything more than integrations related to geolocation, camera and push notifications, PWAs are an upfront no-no, otherwise, PWAs might actually be a good idea to save a buck and enable an almost-native experience for your web users. To give you a better perspective, let’s take a look at a set of pros and cons a PWA can deliver.
1. Less data usage
This benefit might weigh more for some businesses and less for others. Since nowadays mobile data is so cheap, this advantage might serve locations where mobile data is relatively expensive or 3G/4G coverage is poor.
As compared to a full-fledged web app, PWAs use cached content for longer periods, fetching recent changes instead of reloading the entire resource, therefore – such a solution might aid particular businesses in developing countries.
2.App-like experience with engagement benefits
In addition to getting an almost native-like experience for end-users, you could improve overall engagement by using a PWA.
About 53% of end-users leave your website if it takes more than 3 seconds to load. Since PWAs make use of progressive enhancement libraries (like Isomorphic JS) loading fewer resources as compared to a traditional web app makes them even snappier (in some cases) than native apps.
On top of that, since PWAs look like mobile apps but act as websites they can be optimized for search engines. A PWA is inherently SEO enabled and since it drives high engagement, it’s a perfect recipe for screening benefits.
3. Low development cost
As in the case of hybrid or cross-platform builds, PWAs are 40% cheaper as compared to a native build considering the scope.
If you just want a place on your user’s home screen, the cost can be even lower (as per our example). Don’t get me wrong though: a lower cost is not always better, especially when talking about PWAs.
4. Do not require an install
This advantage is a two-sided blade and could go either way (particularly this is why we’ve screened it as a disadvantage too).
The bright side here is that you can deploy a PWA without Google’s or Apple’s approval and you will not need to pay anyone to host your app on a store. Despite that, you still get a place on your user’s home screen and your app still looks like a native one…
Actually, for users that would rather not wait for an app to download and install (especially in developing countries where traffic is expensive), this is bliss. All they have to do is hit “Add to Home screen” and they have a ready-to-use-app.
5. Use standard web technologies
Strong Disadvantages of a PWA:
1. Limited browser support
Considering that 46% of Android devices still run on KitKat, Lollipop and Marshmallow, there is a 20 to 30% chance that your PWA might not work with their default web browser. Under these circumstances, you must ask yourself if you’re ready to slash 30% of your Android users.
On the iOS side, the story is a bit brighter, but you still risk having a PWA that would not work for at least 20% of users (devices running versions earlier than 11.3). Even though PWAs are supported by the most recent versions of iOS, they tend to crash quite often. Apple’s Web.app process (that enables progressive apps) is buggy and causes lags or freeze times on iOS (including version 12) – so until they decide to fix it, it’s better to stay away from PWA builds.
2. Considerable limits on device feature integration
As compared to hybrids and cross-platform, since PWAs uses the device’s hardware and OS features as a browser would, there is a strict limit to what you can make use of on either Android or iOS terminals.
If you’re focused on gaining access to geolocation, camera and push notifications, you are in luck – anything more than that and you’re stuck with a light version of what a native app should’ve been. In other words, if you run a business model that fits ok on the web, PWAs might be a good idea, but if you need to integrate native features such as Apple or Google pay, native is the only way to go.
3. High on GPU, Battery and Resource usage
Since there is no direct access to hardware or features PWAs consume trice the resources compared to a native build, draining your battery faster and running your GPU at crazy levels. The good thing here is that limited scopes consume fewer resources – which makes hardware load time invisible to the user’s eye.
4. No presence in the app store
As mentioned, this is both: an advantage and a drawback. While it’s nice to have no obligations to store owners, the lack of Google’s or Apple’s vetting might place your application in the untrusted box (at least from the user’s perspective).
5. Limited accessibility options
Again, if your end-users have some kind of physical imparity and your scope is oriented towards them, accessibility options would be missed in your build. Not even cross-platform would help out here. If you want to build an accessible app, the only way to do it is by making use of native development.
Bottom line: are PWAs worth your investment?
Yes – especially if you’d like to supply a lighter version of an existing native build. Considering the pros, this strategy could get you more users and better engagement, especially if you focus on audiences that are reluctant to upgrade their devices.
PWAs are also a good idea for online marketing platforms, newsletters or any other publishing services that require nothing more than features like push-notifications and access to geolocation services. This way such businesses could make PWA’s benefits work for them and even increase returning visitors count.
However, if you decide to build an app that requires more access to a device’s hardware, we’d strongly advise on going with a cross-platform or even better: with a native build. Despite the benefits delivered by PWAs, you should always remember – it is not a swiss knife (at least not yet).
With that in mind, we hope you have a complete set of alternatives in matters of mobile builds and if you have any questions left – we’re here to cover them.