An explanation of Progressive Web Apps for the non-PWA crowd

For starters, imagine that once you release a PWA, you can change it constantly without having to republish your application.

Since all the code is hosted on a server and not part of the APK/IPA, any change you make happens in real time.

If you have ever used an application that relies on a network connection, you are familiar with the frustration of not being able to do anything.

With PWAs, you have the ability to offer an offline experience to your users in case of network issues.

And to add the cherry on top, there is an ability to prompt the user to add your PWA to their home screen.

Something that native applications do not possess.

ComponentsThere is a standard regarding a PWA, and you must adhere to it if you want to publish one.

Each PWA is built from the following components:A web app manifestA service workerInstall experienceHTTPSCreating an APKLighthouse auditThe ManifestThis is purely a configuration file (.

JSON), enabling you to change various settings of your PWA and how it will appear to the user.

Below is an example of one:manifest.

jsonYou must set either a name/short name key.

When setting both, short name will be used on the home screen and the launcher.

The name value will be used in the Add to Home Screen experience (or, application install prompt).

Display can have four different values:fullscreen – this allows your application to take up the whole screen when it is openedstandalone – your application looks like a native application, hiding browser elementsminimal-ui – provides some browsing controls (only supported for Chrome mobile)browser – like the name says your application’s look will be identical to a browsing experienceYou can also set the orientation of your application and the scope of the pages considered to be within your application.

Don’t forget to add the manifest to your main html file by putting the following meta tag inside of your head tag:Photo by sol on UnsplashThe Service WorkerA service worker is a component running in the background of your website on the browser.

It has a wide set of functionalities including, push notifications, caching assets and providing them for an offline experience and the ability to defer actions until the user has a stable connection to the internet.

A service worker can be a whole Medium article on its own, so I won’t delve into the inner details of how it works.

But, I will supply a vanilla example of one for you to use in your PWA.

It is customary to save the code related to the service worker in a file called sw.


✋ The location of the service worker is important since it can only access files that are in the same directory or subdirectory as itself.

A service worker has a lifecycle that can be summed up to the following phases:RegistrationInstallation/ActivationResponding to various eventsPay attention to the comments to understand where to place the different lines of codeInstall ExperienceOne of the unique features of a PWA is its install experience.

What this translates to is prompting the user to install your application.

To allow us to present this ability to the user, we will need to listen in on an event called beforeinstallprompt.

Below is a code sample demonstrating the flow from presenting the user with the option to add the application to activating logic based on their choice.

Install Experience FlowPhoto by James Sutton on UnsplashHTTPSNot too long ago, websites could still use the all too common http protocol.

Due to recent changes in security and in Chrome, all websites that do not operate under the https protocol will be marked as not secured.

Even if your website does not handle user data or sensitive communication, it is still good practice to switch over to https.

And like I mentioned earlier, if you want to be able to release a PWA, it has to use the https protocol.

If you don’t want to get into the hassle of acquiring a domain, finding a proper host for it and then enabling SSL, you can go for the easy option of Github.

If you have an account, you can open a repository and set up a GitHub Page.

This process is fairly simple and straightforward and the bonus is getting the HTTPS built in as part of Github.

Creating An APKIn order for our PWA to be available inside the Google Play Store, we need to create an APK.

You can use the popular tool, PWA2APK, which will do the hard work for you.

But if you prefer to learn how to do it yourself, keep reading.

Google has introduced a new way to integrate your PWA into the Play store using what is called a Trusted Web Activity, or TWA.

With just a few simple steps you will learn how to create a TWA, which you can then upload to the Play store.

Open Android Studio and create an empty activityGo to the project’s build.

gradle file and add the jitpack repository3.

Go to the module level build.

gradle file and add the following lines to enable Java8 compatibility4.

Add the TWA support library as a dependency5.

Add the activity XML inside your AndroidManifest file between the application tagsReplace the android:value and android:host with your URL6.

We need to create an association from the application to the website using a digital assets link.

Paste the following inside your strings.

xml fileChange the site value to point to your URL7.

Add the next meta tag as a child to your application tag inside the AndroidManifest.


Create an upload key and keystore9.

Use the following command to extract the SHA-256Remember the details you entered when generating a keystore and your upload key10.

Go to the assets link generator, supply the SHA-256 fingerprint, the package of your application and the web site's domain11.

Place the result in a file named assetlinks.

json under the location /.

well-known in your website’s directory.

Chrome will look for this destination specifically.


Generate a signed APK and upload to the Play storePhoto by Aaron Burden on UnsplashLighthouseBy now, I am sure you have already lost track of what is required from your PWA so it will be valid for publishing.

There are so many things to take into consideration, that it is easy to lose track of what the requirements are.

Luckily for us, Google has created Lighthouse.

It can be found in the Chrome Developer Tools (from Chrome version 60).

It can be accessed easily by right-clicking inside the browser and selecting inspect.

When the new pane opens, you will see an Audits tab at the far right corner.

The Audits TabLeaving the settings in this tab as they are, you can now run an audit by clicking on the “Run audits” button.

This will take a minute or two, but by the end of it, you will receive an informative, graphical presentation of where your PWA ranks in respect to three properties:PerformanceAccessibilityBest PracticesEach property has a breakdown of where your application passed the requirements and where it didn’t.

This lets you see where you need to make adjustments and where you are meeting the standard.

If you are interested, you can find a breakdown of the checklist here.

PWA it upWe are at our journey’s end and hopefully you are feeling better prepared to navigate the world of PWAs.

This article was inspired by the process I went through when creating one recently.

You can check it out below:Android Menu XML Generator – Apps on Google PlayGenerate any type of menu you need for your Android application.

Choose from an Options, Context or Popup menu and…play.



. More details

Leave a Reply