Tips how to prepare a web application for installation on a mobile device

Being a co-founder of Solidstudio, Paweł has got to see all the development phases. He’s a skilled professional with years of experience, both in the software and in the eMobility worlds.

Paweł Głogowski

, almost 50 percent of total Internet usage in the UK comes from mobile phones. Similarly the United States and Europe. Various reasons account for that, but essentially it's because accessing the web using a smartphone or tablet is handy and convenient, particularly for specific sorts of applications. Before I reach the clue of this article - how to add a web page to a mobile device as a Progressive Web Application - I want to clarify some related matters regarding Progressive Web Application.

And why should you be one? The term mobile-friendly has begun to appear in the media more and more often with the growing boom of these handy portable devices - smartphones, tablets and their subsequent variations. For many, initially, mobile-digital was considered just another quirk, but over time it has become a permanent fixture in the canon of being customer friendly. Creating and developing mobile versions of websites, e-commerce and marketplaces became a standard. Simply, because this meets online users' expectations. Plus, from April 2015 Google uses mobile-friendliness as a ranking factor. In a nutshell, becoming mobile-friendly, or even mobile-first is beneficial for all parties. For users means better adoption, for business increased visibility & profits and being on the cutting edge of the Internet - mobile-friendly solutions are essential.

Taking a mobile-friendly approach, or becoming mobile-first cannot be achieved without one more factor - Responsive Web Design.

Responsive web design is an approach to web development presented in 2010- five years before PWA was introduced to the world. The general idea is that design responds to the user’s device - size, motion, and orientation. Responsiveness is achieved with the use of fluid grids, flexible images, and media queries. The approach excludes time-consuming development phases which were earlier needed to fit the different screen sizes on the market. Flexibility and the speed of development of responsive websites became a common practice. Now, almost every website you visit is responsive in its nature.


What does PWA have to do with a mobile-friendly approach?

Building a custom application for multiple platforms is usually time- and resource-consuming. In the era where most of the information search and purchases is done online, and the majority of smaller businesses must meet the market demands at the most inexpensive charge. That's where Progressive Web Applications (PWAs)  and responsive design come with help. PWA generally allows you to easily convert your web application into a native application or at least something which is more or less similar to it. PWA, thanks to its fast performance and compatibility with multiple browsers, ranks highly in Google search results. Hence, solves Google's search engine algorithm ranking issue, being mobile-friendly. Websites based on Progressive Web Application appear higher in search results. In this article, I'm going to show you how to add a web page to a mobile device as a Progressive Web Application.

How to build a Progressive Web Application?

Your application needs to meet specific criteria:

It's served over HTTPS for security purposes.

Responsive web design - it needs to look well on various mobile devices.

It should work even when there's no internet connection or at least show an information screen about the lost connection.

It includes "manifest.json," allowing us to add a shortcut to the mobile screen.

It should work well with slower connections.

Let's focus on the manifest.json file, which is required for adding your application to the device's home screen. It basically contains information about the icon's starting address. Let's take a look at the following example of manifest.json file:

yourApplicationName

Making your application usable in case of the lack of an internet connection isn't going to be a part of this article. Instead, we will focus on enabling users to install your application for both iOS and Android applications.

How to "install" your website on a mobile device?

Before we begin, note the huge difference in the attitudes to Progressive Web Applications. In general, Google supports PWA and wants to increase its popularity, while Apple prefers users to install native apps bought in the Apple App Store. However, due to the popularity of PWA, Apple began to support this from version 11.3 of iOS. Starting from version 12.2, PWA works quite well but is still not as stable and fast as on Google Chrome. Let's take a look at how to install your web application on Android devices.

First of all, you need to use Google Chrome because other browsers don't support PWA yet. Google Chrome fires the "beforeinstallprompt" event, which can be handled in a customized way. To do so, add the code shown below on a high level of the application. For a React application, that can be the App.js file.


Without that, you'll see a Chrome embedded info bar with a message like "Add This App to Home Screen" along with the dismiss button. When dismissing this window, expect it to pop up once again in a couple of weeks. You may ask: why bother with a custom solution? Well, first of all, you can create your own solution - it could be an info bar, a banner, or whatever else you want. It can also be customized in terms of colors and layout. A custom solution will significantly improve the user experience. In the above example we use a snackbar to inform users about the possibility of installing the application.

It's basically will show a banner like this

Keep in mind that you should declare deferredPrompt as a global variable. If you fail to do so, the prompt window won't open once again after clicking the cancel button. I believe that the rest of the code is self-explanatory.

Also, you can easily determine if you're using PWA mode. That can be useful because you don't want to show the info bar to users who are already using the PWA. You can do it using the following code:

How to add a PWA to the home screen in iOS?

Unfortunately, accomplishing the same in iOS is far more complicated. Basically, we need to do it manually. The only thing that can be done from the application perspective is showing some kind of information on how to do it. At Solidstudio Software House, we use a snack bar widget that appears at the bottom of the application with a short instruction about how to add it to the home screen. Also, keep in mind that adding a PWA to the home screen in iOS is available only on Safari, and the event "beforeinstallprompt" isn't fired on iOS.


The only challenge here is determining whether the actual device is controlled by iOS. We can do it by analyzing the user agent string. Unfortunately, starting from iOS 13 we can't identify whether it's an iPhone or iPad - instead, it will always show as "

." This is tricky, because we need to recognize if the device is a phone or a tablet. Also, we need to indicate if the current browser is Safari (it doesn't make sense to show that bar on other browsers than Safari). As it turns out, that's not easy, because all browsers on iOS are wrappers on Safari. Consider the following examples:

We search for an iPad, iPhone string in the user agent string for the older version of the iOS system. Analyzing the user agent string, we notice that Safari agents have no references for 'CriOS' or 'FxiOS'. So in the newest version of iOS, you have to determine if the device is a mobile one. At Solidstudio, we use a simple but effective solution to determine it by the width of the screen. Since iPads has 1024 screen width, we can use the following code:

Despite challenges, PWA can be beneficial

Like many solutions, there are some cons. It requires a lot of research and development for a custom solution, but once an effective mechanism is created, it encourages users to install applications on their mobile devices. We worked with the PWA technology in our project for 

. We blend top technologies to offer users native experience and increase engagement with the app. Since PWA may cause some disruptions, here we wanted to share some insights from our experience. Some more solutions, when we are struggling with the auto-refresh of the application in standalone mode, soon will appear on our blog as a follow-up to this article. To stay updated, make sure to subscribe to our newsletter!

Learn how to make usable Progressive Web Application on mobile device.

Pro tips how to overcome common Progressive Web Application challenges

Common challenges with PWA can be fixed in a variety of ways. In this article, I want to share some practical tips and solutions on how to resolve common issues of Progressive Web Applications. Refreshing, service-worker configuration and updating to save time and achieve smooth flow and be ahead of your users' needs.

This is the second part of our series about PWA. If you’d like to learn how to change your web page into a Progressive Web Application, be sure to check out our previous 

 application that can be served as a Progressive Web Application. We follow a 

 approach to enable quite frequent changes in the product and ensure that our users get the latest content of the application.

 is heavily cached, serving the latest content to users can be challenging. It’s not possible to refresh the application when you’re in standalone mode so we have to do it differently. We spent some time preparing a user-friendly solution that would allow users to get the latest version of the application quickly.

Different ways to refresh your application

Developers can approach the problem of refreshing the application in different ways. 

The easiest way could be adding a fixed refresh button that is available only on the 

 version. It might be the easiest way since it doesn’t require any interaction with service workers. However, it’s not very user-friendly. Users may not be aware that the latest version of the application is already available and ignore that button.

The second approach could be informing users when the application is showing on the screen. So once the new version is available, users will see some indicator bar with a refresh button. That way, they will know that there’s new content to fetch from a server. Let’s take a look at how that’s indicator bar could look like.

We can achieve the above effect by using 

. Take a look at the following code to see how to achieve it. To get the best result, you should show this bar only to users in a standalone mode (PWA) - we discuss this in our previous article (link) so make sure that you generate that bar only in standalone mode. Additionally, you can style your snack bar to suit your application best.

You can see two handlers in above code - let's see how they can looks like:

We don’t want to allow refreshing the application because we notice some unexpected behavior on iOS - it tends to fail randomly or behaves in an unstable way after some refreshing, so we encourage users to kill the app and reopen it. However, refreshing seems to be stable on Android and Chrome, so for Chrome users, you can change the bar and show the refresh icon so users can refresh the app to get new content on their own.

From the programmatic perspective, nothing interesting is done here - we just show a bar and allow the user to close it. The more important thing here is how we indicate that a new version of the application is available to the user. To do that, we need to define a proper callback for updating service workers and force them to be updated. More on that in the next part of the article.

How to update Custom Service worker callback?

Let's take a look at the service-worker configuration generated during the development of a React application.

I have highlighted the most important parts of that code snippet. As you can see, we add a listener on the state change of service worker. It will be executed when changes occur in the service-worker. It might be misleading that we’re watching for the ‘installed’ state. But the existence of the controller property indicates changes in the service worker. What we need to do is to pass the config object with the callback onUpdate function. We usually need to register our service worker in the index.js file. Here we pass the object with the onUpdate property which is a callback function.

How to skip waiting for a new service worker?

However, it's not enough for the configuration of service worker. Because we want the new service worker to take over the old one immediately, we need to configure it to skip waiting. If we don’t do this, the new service worker will be available after the user navigates the refresh current page. It's not always an option since we observe some major problems with refreshing the page in the PWA mode. Visit the following 

 to understand the service worker lifecycle better.

To configure the service worker to skip waiting, we need to add some code to the default service worker implementation which is provided when we generate a sample project. To do so, we will use a tool called 

. So we first need to add a proper dependency to the package.json file along with the modification of the build command. It should look like this:

Note: The following example is valid for React application, but it will look quite similar for application build in other technologies.

You need to provide code for your custom service worker. For now, it will be very simple and will only contain the service worker skip waiting logic. This code will be appended for the actual service worker code.

It's not much code, but right now we can be sure that the new service worker will take over the old one.

How to “update” Service worker, i.e. check the availability of the latest version?

So far, it all looks quite straightforward, but we need the most important piece of the whole picture - we need to know when the changes to our web application occur. In order to do this, we need to force our service worker to “update”. The name for that operation may be confusing because it’s not update itself - rather, it’s checking whether the new version of the application is available. Let's take a look at this piece of code:

This will download the newest version of the service worker file from the server and compare it with the current version to detect any differences. It will fire an event that we can handle by 

 which was described previously. You may ask how the application “knows” that there were changes in code. When you take a look at the build directory, you can see a file like this.

If you see the content of this file, you will notice something like this:

When any file changes, then in precache file there will be different revision numbers and name of precaching file hash ( in the name ) changes. This file is included in the service worker file so if the name is changed, then the service worker file changes so the service worker can notice that change.

How to add a Progressive Web Application to the home screen in iOS?

The last thing we need to cover is determining when to check for the update. Of course, using the setTimeout() feature available in React allows to periodically check for updates of the new version. But this approach can cause some unexpected issues and unnecessary performance costs so we believe that it’s not enough.

We decided to take advantage of the PWA lifecycle and web API visibility change feature, so once users display the main screen of the application, we catch that event and force the service worker to update. Let's take a look at the following code:

Note: This approach may not work on Google Chrome. If you’re using Chrome, consider different events like scrolling or clicking a button.

We can catch the visibility change event which is fired when the application is displayed on the user’s screen. However, this event is fired when the app is shown and when it’s hidden so we need to check what the value of the hidden property is to determine if it’s displayed.

So now we have all the pieces fitting together and the final flow looks like this: The user opens PWA --> PWA catches the visibility change event and forces the service worker to update → the service worker checks if a new version of the application is available → we handle the update event by showing the refresh bar to the user → The user restarts the app (iOS) or refreshes it (Android) to get new content.

You can see that there are some differences between iOS and Android. To help you understand that better, let’s take a look at the following table.

As you can see, there are a lot of different pieces involved in the process of refreshing your PWA. But in the end, it will be very beneficial for your users. At Solidstudio Software House, we followed this approach in our product 

 to make sure that users have the latest version of the application. In our experience, Chrome seems to have a more stable and reliable environment when it comes to supporting PWA and we still need to fix some unexpected issues for iOS.

Learn how to overcome common Progressive Web Application challenges

The challenges of Progressive Web Apps

Serveless testing - tools and techniques.

Serverless architecture was one of the hottest topics in 2018. Just take a look at Medium articles and the number of threads and discussions on Reddit, Twitter, and other social media. It’s becoming more and more popular - and some well-known companies have started to use serverless architecture in their projects (Netflix or Coca-Cola, for example). However, popularity also serves to reveal some drawbacks and challenges of introducing serverless architecture. One of the biggest challenges is testing which is much different than in “traditional” applications. In this article, I would like to share some hints and tips about testing a 

The obvious difference between a traditional and serverless application is that it requires a lot of collaboration with external services - in the AWS world, it can be API Gateway, Dynamodb or S3, for instance. It’s often hard or even impossible to integrate with real services. Fortunately, there are some useful tools that can help with emulating some external services to help with writing tests. Let’s talk a little about possible tests that we can perform in the serverless world.

Firstly, to speed up every local development developers should be able to invoke code locally. At Solidstudio Software House we choose NodeJS to write our lambda functions because it’s lightweight and it’s easy to execute your code locally. We also find the serverless framework very handy as it that allows us to execute NodeJS code with some input parameters that can be really helpful.

Let’s imagine that our lambda subscribes to AWS S3 event for further processing. It thus has to consume the S3 event. It could be very helpful if we could use that event and invoke lambda as if it was consuming a real S3 event. We can easily capture the real AWS event and save it in a local JSON file. We can later use it for input of our lambda without actually using our infrastructure.

Of course, invoking lambda locally for several scenarios every time we want to change a single line of code isn’t very efficient. That’s why we need to write some automated tests. The most basic and easiest type of tests is, of course, unit testing. It's a must-have in all kinds of projects and the serverless environment is no different. The good thing is that serverless functions are "well-modularize” and so can be unit tested easily.

Like in any other system, we need to have decent code coverage in unit testing. We need to simply mock every interaction with external services. If we want to simulate some AWS events, we can use the captured AWS events discussed earlier. Every modern programming language has a framework to write and mock unit tests with. For NodeJS, we can use Mocha or Jasmine which offers a very easy way to simulate external events. Building and running tests must be a part of building a deployable package.

Once you have your code well-tested locally and are confident that the code is working correctly, you should deploy it to the development environment. This process need to be automated to avoid the potential risk of manual deployment. In serverless development, it’s crucial to test your function on the real environment because of some configurations like IAM permissions or AWS lambda limitations that don’t occur in the local environment like memory, disk space, timeout, payload size. Sometimes we forget about these limitations and something that works well on our local machine may fail in the real AWS world.

When our code has successfully reached the dev environment, you can check its behaviour by emitting event that particular functions are subscribed to. You can, for instance, upload a file to the target bucket and check if particular lambda behaves as we expect. Obviously, it's just a technique to debug and improve the development process - and testing cannot rely on it. We need some automated tests to make sure that all our functions work well after every change. We should run the entire test suite after applying changes to a single function.

Integration testing in serverless application

In a serverless project, we also need to have a decent integration of the test suite to make sure our application works as expected. Each lambda usually handles one event and most of the time we need several lambdas to cover our business story. Creating a user by the REST API can trigger events that will be consumed by several lambdas that will handle adding a user to DynamoDB, uploading photos to S3, or sending greeting emails. So, one integration test must make sure that all these three lambdas are invoked and done their job properly.

With a serverless framework along with Event Gateway, we can very simple hook up our functions to particular events and trigger our functions. Then we need to have code that will verify whether the lambdas have done their job well. It's good to write tests in one language rather than mix several techniques. The programming language should work well with AWS and update their SDK quite often so it works with the newest version of services.

Each test suite has to start with an emitting event and wait till lambdas react on it. That could be challenging as there’s no easy way to indicate whether a lambda is complete. One approach could be invoking some lambda and waiting for some fixed calculated time before testing - for instance, we could take lambda timeout as our wait time. However, it's not a good idea since delays may happen or some lambdas will finish before that time - its either risky or inefficient.

The best approach is checking periodically if some condition is fulfilled - if we expect an object to appear on S3 then we can check whether it’s there, as well as check for data in our storage (DynamoDB, RDS etc). We can then finish the test as soon as the lambda has finished its job, or fail if the outcome is not what we expected or the lambda hasn’t finished its work in a reasonable amount of time.

At Solidstudio Software House, we’ve started our latest project in a fully serverless architecture. We noticed that it requires a significant mindset change, but developers who have in microservice architecture should be able to move to serverless quite smoothly. As serverless architecture becomes more and more popular, they can take advantage of reliable and easy-to-use tools. We find serverless framework and event gateway as the best technology choice.

 If you’d like to stay in touch, please sign up for our newsletter: no spamming, just information about the latest content.

Read this article to get familiar with serverless testing.

Introduction to serverless testing

How to start continuous delivery at your company.

 I discussed the benefits and drawbacks of Continuous Delivery (CD). Hopefully, I was able to convince you that CD is a must have if you’re striving to be a modern and innovative company. The next question on your lips, of course, will be: how do I start introducing CD into my organisation?

Continuous Delivery is more about cultural than technical change

Firstly, you need to change your entire team’s way of thinking. Usually there are developers, QAs, DevOps and managers in among the mix. They all have different responsibilities, but the whole team is responsible for successful deployment. And, when something goes wrong, it’s counterproductive for team members to start pointing the finger. Instead, teams need to learn to concentrate their efforts on getting delivery working again.

CD also ensures that QA and IT Operations staff are closely involved in working on the needs of the software. Discussing all the decisions, early on, with the entire team allows everyone to be on the same page in terms of architecture and risk. There’s nothing like preparation and CD allows infrastructure changes and code deployment to be tackled with relative ease when a firm plan is in place.

Due to the cultural changes and adjustments required to introduce Continuous Integration/Delivery processes, it’s crucial that your company has strong organisational basics in place to meet these needs.

First of all, treat CD as a process that can be approached in small steps. Your next action should be to analyse your build process, write down all the steps and then focus on two things:

Which are the most error-prone and involve manual intervention most often?

These are the best candidates to automate first.

Once you have determined the steps to automate, you must build pipelines on your CD servers that will automate a trigger building process after each change to the master branch in your source code repository. In the beginning, make your pipeline as simple as possible. It is more important to have the whole process implemented and working so it can be improved and extended rather than focussing on each step independently and attempting to integrate it at the very end. This approach is favoured because you will face infrastructural issues during deployments or executing tests; it’s better to address the resultant issues right away, otherwise you will end up with an integration nightmare. Once your build process is automated and well-established, then it’s time to add tests to the pipeline. AtIn Solidstudio, we aim for over 90 percent coverage for unit tests, but it’s not a must in the beginning.

The next step is to add more and more tests to the build process. Starting with the unit, you should quickly introduce higher level tests, like api tests for REST services, end-to-end tests with various scenarios for web and mobile applications and a regression suite to ensure that nothing is broken. Finally, you may want to introduce performance tests for individual and crucial parts of the application.

With all the various tests in place, you may be confident that your application is working correctly and that your software is ready to be deployed at any time without major risks. Tests are a crucial part of CD, so it’s very important not to bypass writing proper tests during the development phase.

Of course, the whole process will be much easier if you are about to kick-off a new project instead of implementing it into an existing and complex application. However, even when starting afresh, it still requires a lot of discipline to introduce good practices to the project.

CD is a process and, as you know, there’s always room to improve 

 process. In order to be able to improve anything, however, you need to know:

How much in terms of resource is consumed by the process?

In these cases, you need to monitor and analyse the data that comes from your CD servers. Once you identify any problems, work to address these issues. It will improve the whole process by reducing the time and costs of releases.

Despite some of the technical challenges and necessary tools, CD is more about the collaboration between individual people and teams. A team needs to feel like a team, there needs to be a shared concern about the quality of the project. With that in place you can be sure that team-spirit will increase and stress levels will drop among whole team. The final bonus is that your customer will love the shorter release cycle and constant evaluation of the product.

How to start continous delivery? Read our quick guide.

How to install a Progressive Web Application on a mobile device?

02 JUNE 2021 • 14 MIN READ