PWA - Cheap Native Apps.

Just a decorative image for the page.


If you’re working with software that runs on mobile devices - otherwise known as “apps” - you’ve probably come across the term “PWA”.

But what is a PWA - and why should you care?

Table Of Contents


Developing software for Android and iPhone (iOS) is expensive. You have to support two different platforms, programming languages, and APIs. You also have to understand the different look and feel and capabilities.

Native app development is expensive. You will need at least 2 - better 4 engineers for a moderately complex application. That puts a price tag on it of around 150k-300k USD. Wow.

But you already have a web developer. Wouldn’t it be great to let those developers just build web applications that also run on mobile devices?

Unfortunately, a web application (aka html pages) is usually not enough. You need deeper integration to access the camera, QR scanner, payment methods, notifications, and enable a good “app-like” offline experience.

This is where PWAs come in.

With PWAs, you can write traditional web applications that render html. But these can also be “extended” to support deep integration with mobile phones looking like real Apps.


Caching and Offline Capabilities

This is one of the core parts of PWAs. They allow you to specify which files need to be available for offline use via service workers.

This is especially important if you have a spotty connection (very common in the mobile world).

You also have the ability to automatically resume a job (e.g. sync) when the connection comes back online. Even if your PWA is no longer started via the Background Sync API.

Access to Device

Native apps are deeply integrated into the phone. We take it for granted that apps can send us notifications, open other apps, or scan QR codes even when the app is not running.

Web pages cannot do that. But the PWA specification allows them to.

Some examples:

PWAs can do much more like [speech recognition, barcode scanning and so on] (

Danny Moerkerke has created a nice demo of all the features. A great place to play around with PWA features:


Support by Mobile Phone Vendors

PWAs need browser support.

That’s not much of a risk on Android because there are many browsers, and Google’s Chrome supports and drives PWAs.

But Apple is a different story. In February, out of nowhere, Apple decided to stop supporting parts of the PWA Specification on Short Notice on all iPhones and iOS devices. After an outcry, they backed down from that decision.

This is a risk to be aware of. And if you don’t want to take that risk, you need to write real apps - either natively or with frameworks like Flutter or React Native.

Not Understanding How Mobile Works

Just adding a few APIs to a web page doesn’t make it a real and good mobile experience. Your product owners need to understand the capabilities, opportunities, and challenges of mobile devices.

Otherwise, you’ll just frustrate your users with a very bad experience.

If you have enhanced your web applications with the PWA specification, but usage does not increase, then you need to investigate:

  • Maybe my users don’t need a mobile application.
  • Or is my PWA experience so bad that I am driving them away?

Don’t jump to conclusions!


Depending on your mobile needs, PWAs can be a great, cost-effective way to extend the reach of your Web applications. PWAs allow you to integrate deeply into your users’ mobile devices. PWAs can look and feel like real apps at a fraction of the cost.

But PWAs are still not true native apps - and they are not for everyone!. True native apps have more capabilities and options. For example, you can customize the look and feel of notifications much more deeply with native apps. And if that’s important to you, then PWAs are probably the wrong choice for you.


Related posts