Progressive Web Apps (or PWA) in layman’s terms are web applications that act a lot like native applications, providing many of the same features — such as working offline, bluetooth, push notifications, device position, gyroscope etc. PWAs can be added to a mobile device’s home screen, can be opened like native apps and will always be easily accessible to the user.

For more details about what native capabilities PWAs are able to utilize, see:

https://whatwebcando.today/

The usual user acquisition flow with PWAs for Android is shown below:

User visits your site A popup asking the user to add the app to their home screen is displayed User accepts the offer by pressing ‘Add to home screen’ on the popup The application is added to their home screen

What do PWAs mean to you as a business owner?

PWAs make it possible to create applications which work better than usual web applications, while allowing the user to download it their phone, giving users the impression that they’re using a native app. Previously, the only other means of achieving the same result was to build your web application and native iOS and Android applications separately.

You have to develop and maintain a single application

Traditionally, you would need separate code bases for web, iOS and Android applications. Each platform you support has to have their own business logic, as it’s not possible to share that code between the platforms (with the exception of React Native, Xamarin etc). Each platform has their own bugs and needs to be maintained separately, which also means testing each platform separately. In general, time spent on developing, maintaining and testing is substantially greater.

Building PWAs is cheaper than building native apps

Developing and publishing native applications takes a lot longer than building a PWA compatible web application. When publishing a native application, you first have to buy a developer’s license in one of the respective stores (App Store or Google Play Store), then you have to build and digitally sign the application, set up all the images and texts for the app stores and when you finally upload and submit the application, you have to wait for it to get reviewed by the app store officials.

Even though app stores provide testing capabilities (ie internal tracks or TestFlight), sharing access and publishing new versions to the testers is cumbersome. In the case of PWAs, an initial version can be launched in just a few minutes, using tools such as Netlify. Sharing the application to the public or internal testers is just a matter of sharing a link.

PWAs support most native capabilities

It’s easier to find developers for PWAs

A quick glance at the most popular technologies shows that it’s a lot easier to meet a JavaScript developer than an Objective-C/Swift or Java/Kotlin developer. It’s extremely likely that most developers you encounter have at least some experience with JavaScript.

PWAs conversion rate is proven to be higher

As opposed to the native application conversion flow show on the image above, PWA conversion flow is a lot shorter: user lands on the URL and presses ‘Add to home screen’ on the native PWA popup. Permissions to native capabilities are asked when the feature is actually required, meaning your users are already committed at that point. Keep in mind, that downloading the PWA is not mandatory to get the added bonuses — PWA also provides all the capabilities inside the mobile web browsers, without the user adding it to their home screen.

Setting up and developing PWAs is quicker compared to native apps

Both Android and iOS native applications require you to download large, platform specific, IDEs. Native applications also require compiling the source code into byte code before installing or publishing the app, which starts consuming more and more time as the project grows. Once your application is ready to be released, you still have to wait for Google and/or Apple to review the application.

In the case of PWAs, the developer can choose whichever text editor or IDE they desire to develop the apps. The code does not need to be compiled, but is often transpiled and bundled. Transpiling and bundling JavaScript and CSS takes immensely less time than compiling source code into byte code. PWA development flow is often accompanied by Hot Module Replacement, which means you can see changes on the fly, without having to rebuild and restart the application. Publishing the app to the public is just a matter of serving the files on a web server and having it tied to a domain name. No-one from Google or Apple will need review it.

PWAs are minuscule in size next to native apps

Native applications tend to be very bloated — the average size for an Android app is 15 megabytes and for iOS 38 megabytes. (Source: https://sweetpricing.com/blog/2017/02/average-app-file-size/)

With PWAs, it’s reasonable to expect apps smaller than 1 megabyte. Quick maths tells us the download time is at least 15 to 38 times faster and requires no installation, giving PWA an even better advantage in terms of setup speed.

As an example, Twitter’s PWA is only 0.6 megabytes while their native Android app is 23 megabytes. If it takes one minute to download the native Android app, you would get the PWA in just 2 seconds.

Another example is Uber: their PWA is 50 kilobytes. On a 2G network, it would take 3 seconds to download. Compared to the average app size of 23 megabytes, it would take more than 20 minutes on the same network.

Ease of business

Google’s Play Store charges a one time fee of 25$ to be able to upload apps to the Play Store. The transaction fee for selling either the app or payments made within the app through the Google Play platform have a transaction fee of 30%.

Apple’s App Store developers have to pay 99$ per year for their right to publish and maintain applications. Apple also takes a 30% cut in selling both the app and in-app purchases.

Case studies from major app companies

Uber managed to make their mobile application only 50 kilobytes in size, while providing the exact same functionality as the native application.

See case study: https://eng.uber.com/m-uber/

Tinder cut their application size by 90% compared to the Android counterpart when making the PWA. Their load time was reduced from 12 seconds to just under 5 seconds.

See case study: https://medium.com/@addyosmani/a-tinder-progressive-web-app-performance-case-study-78919d98ece0

Pinterest

Alibaba increased their conversion rate for new users by 104% with their PWA and increased pages visited by twofold.

See case study: https://developers.google.com/web/showcase/2016/aliexpress

Twitter saw a 75% increase in Tweets sent in their PWA.

See case study: https://developers.google.com/web/showcase/2017/twitter

Google’s internal metrics showed a 5–6x increase in conversion rate with PWAs compared to native apps.

See case study: https://medium.com/dev-channel/why-are-app-install-banners-still-a-thing-18f3952d349a

More examples:

Problems with PWAs on iOS

PWAs have three major downsides that have yet to be addressed by Apple on iOS.

No push notifications

Apple has not yet indicated when and whether push notifications will become available on iOS. From some viewpoints, it seems as if Apple does not want PWAs to become commonplace and want to force people to develop native applications.

No “add to home screen” banner

Android supports showing a native “Add to home screen” popup on websites that qualify as a PWA. On iOS, there is no option for a native popup. However, you are still able to detect whether the user has installed it on their home screen and display a tooltip indicating that your web application can be downloaded and show the user how. See this example:

Poor state management

Apple has decided to put a weird state management solution on their PWAs added to the home screen — every time you navigate between some other app or home screen and return to the PWA, the application gets reloaded. However, the developer can work around this issue by persisting all the application state into the local storage.

Conclusion

There’s never been an easier and faster way to develop and publish mobile applications. Building native mobile applications has always been complicated and time consuming for all platforms, but with the advancements made in web browser capabilities, a web application that provides the same functionalities as a native application can be created in just a fraction of the time.

All things considered, you get more value from building PWAs compared to native apps, while having a lower budget and shorter deadlines.