Your service should work well on all mobile devices. Evaluate your options carefully to find the most suitable solution for your users.
Finding the right approach for your service
Users expect government services to work on whatever device or browser they choose to use.
A responsive website is usually the best way to do this. Compared to native apps, responsive websites:
- do not require the user to download anything, making them easier for the user to find and use - and saving on the user’s data allowance
- are usually easier and less expensive to develop, maintain and iterate because they do not need different versions for different operating systems
- make it easier to measure how the service is used, compared to measuring how an app is used after it’s been downloaded
Building a responsive website
Building a responsive website (or a responsive service that’s part of GOV.UK) means using:
- responsive design to make sure your website works on different browsers and devices
- progressive enhancement, which will also make your service reliable
Building your service in this way means users get the same content and functionality, regardless of how they access your service. And it will help you to meet government accessibility requirements.
Building an app
An app may be the right solution in some circumstances. For example:
- the service only works if it has a persistent presence on the user’s device - for example, some apps designed to help the user live a healthier lifestyle
- the service needs to interface with specific features of the user’s device
- the user needs to collect and store data, but will not have consistent internet access
If you think an app is the right option for your service, you’ll need to show clear evidence as part of your spend request or internal pipeline process.
You’ll show that the need cannot be met by opening up your data via an Application Programming Interface (API) and letting the market meet any need for an app. For instance when Transport for London opened up its APIs, it resulted in the creation of Citymapper - a popular travel app.
Progressive Web Apps
Advances in browser technology have made it possible to do things on the mobile web that you could previously only do with native apps. Services that take advantage of these modern browser enhancements are often called mobile web apps or Progressive Web Apps (PWAs). You should use your alpha discovery and prototyping sessions to explore how they might help you.
The user experience of PWAs on a handset is almost identical to a native app. But, unlike native apps, PWAs have a single codebase that works on the web like any normal website.
A benefit of PWAs over native apps for the government is that there’s no need to maintain lots of different operating system versions of the same app. This makes them relatively inexpensive to develop compared to native apps. It’s also important to remember that you may still need to tailor your PWA to suit specific device features.
If your user research is leading you to consider a native app, you should first look to see if PWAs might solve the problem.
With PWAs, users can access the following native APIs through their browser:
- offline mode
- push notifications
- speech recognition
- file access
- camera and sound recording
- device motion
The site What Web Can Do is a good place to check for the current features available on the web platform.
Users can choose to install PWAs on any device that supports the technology. If a user chooses to install a PWA, they typically take up less space than the equivalent native app.
PWAs cost less than native apps, since they only need to be developed once for different platforms. They are also forward-compatible with future upgrades to operating systems.
PWAs for government services are still in their early stages, and you’ll need to do user research and examine your data to check if they are the best option for your use case. As with any technology, PWAs do have their own drawbacks and constraints - for example, storage on a device can be a limiting factor. For this reason, it’s important to consider how using a PWA will impact your service and users on a case by case basis.
Things to consider before developing a PWA
Before you develop a PWA, you need to be sure you know:
- who your users are
- what platforms they use to access your app
- how your users use any existing websites or native apps for your service
- what kind of connectivity your users have
- how much data your intended PWA will use
- if your analytics data shows adequate support for service workers and the web app manifest
Native apps are apps for specific operating systems that users download onto their devices. Sometimes an app may need access to wider functionality than any web app can currently provide. In this case, you may decide a native app is the best solution. For example, if the offline user data needs to be encrypted - this is currently easier and more secure to do in a native app.
If you’re developing a native app, where possible you’ll need to make sure it works the same way on a variety of operating systems - such as Android and iOS.
If you have a small, closed user group who all have the same device, you’ll only need to ensure it works for one operating system. You’ll still need to understand the implications of being tied to one vendor, and support any updates to the operating system.
What to do if you’re limited by device functionality
If your native app requires functionality that’s only available on a certain number of devices, you’ll need to treat the app as an enhancement to your service.
This means offering it to users who’ve got those devices as the easiest way for them to complete their task. However, you’ll need to provide a way for other users with different devices to complete their task too - and take reasonable steps to make it as simple as possible for them to do so.
You may also find these guides useful:
Updated guidance to include information on progressive web apps (PWAs)
Updated guidance around native and hybrid apps.
Guidance first published