Getting started with Progressive Web Apps (part 1)
An evolution has taken place in browsers. It has happened without fanfare, but silent and gradually by the continual development of new browser technologies, culminating in an umbrella term called Progressive Web Apps. In this article series, you'll learn everything you need to know to create modern, offline-ready apps.
In this series of articles on Progressive Web Apps, we'll explore the following topics:
- What are Progressive Web Apps
- Browser support
- The Progressive Web App life cycle
- The Web App manifest
- An introduction to Service Workers
- Frontend Frameworks and Progressive Web apps
- Building your first Progressive Web apps
What are Progressive Web Apps?
A Progressive Web App is a website by any other name. It is not a packaged app, or an app written to be downloaded from the various app stores. It is simply an enhanced web app with some native-like capabilities.
You do not have to make any compromises when writing a Progressive Web App compared to making a regular website. A Progressive Web App works in all browsers, and the experience is simply enhanced on browsers that support the technology. One interesting aspect is that the enhancement does not kick in immediately, but gradually after a certain amount of user interaction. The apps earn the user’s trust so to speak before it enables all of the Progressive capabilities. If the user agrees, the app installs itself alongside the user’s native apps, be they on the mobile or the desktop. On mobile devices, users can tap on the icon on their home screen to open the app in full-screen mode. The user will not see the browser’s user interface, only the app’s user interface. On desktops, the user can start the app from their list of programs, or in the operating system’s task switcher.
There're a few differences between a native app that you can find in app stores such as in the Apple App Store, the Windows Store, Google Play store and so on, and in other closed environments such as Chrome Packaged Apps and Firefox Packaged Apps. These are all great environments for apps, but they all share a few drawbacks compared to regular web apps:
- They must be downloaded in full before use. On contrast, web apps only need to download the core shell before they can be used.
- The app store becomes the facilitator for discovery. Searching for an app in an app store is usually hard, and you often have to know the name of the app before you can find it. It is a lot easier to be found on the web. Furthermore, the apps are not linkable in the native app stores.
- They need to go through a formal verification procedure before an iteration is allowed to be put up.
In short, native apps trade off the fast iteration and linkability of the web for features such as access to native system APIs, install to the home screen, splash screens, push notifications and so on.
For an app to a part of the web, it must adhere to a couple of fundamental principles. First of all, it must be linkable. Second, it must be standards-based and free to implement, without requiring permission or payment to any mediator. Imagine if Google or Bing started demanding payment for listing your app in their search indexes. It could not happen on the web because websites are linkable, and a thousand competitors would pop up with free alternatives.
Progressive Web apps share all these qualities because they are websites at heart. Also, the more the user uses the app; it becomes more useful because it progressively builds a relationship with the user. App data, icons, scripts and so on, is stored on the user`s device for quicker subsequent loads. By the use of a service worker, the app can download and push content to the app, thus making it even more useful. The best part of it is that it is still a website that you can link to and link from, and which doesn`t require the user to download anything from an app store.
According to Google, a Progressive Web app has the following characteristics:
It works for every user regardless of browser choice because it has been built with progressive enhancement from the start, and can take advantage of any features available on the user’s device and browser.
It fits with the device form factor and screen size including desktop browsers.
- Connectivity Independent
It works with low-quality networks and even works offline.
It gives off the appearance of a native app, with app-like navigations and interactions, and is built on the application shell method.
A requirement of Progressive Web apps is that they are served via HTTPS to prevent snooping. This is important because all network requests can be intercepted through service workers.
Identifies as applications thanks to W3C manifests, allowing search engines to locate them. This gives them a huge advantage over native apps.
Allows the user to store apps they find useful on the home screen, with a first-rate home icon.
Does not require a complicated installation procedure or an account with an app store. It`s just a URL.
Has access to the re-engagement UIs of the device it`s running on, for instance, features such as push notifications.
Always up-to-date because it can push new content to the app when connected to the Internet.
It has always been important to use SSL, but it used to be quite expensive and difficult to purchase and maintain an SSL certificate for your domain. A very popular service called Let’s Encrypt has made the process easy and free. The service is backed by some powerful corporations, which is quite a boon given that if you want to publish a Progressive Web App, it is required to be served on a domain over HTTPS.
At the time of writing, the Progressive Web App technology (chiefly, the support for service workers, but also Promises, Fetch, background sync, posting of messages to and from the worker) are limited to the Chrome and Firefox browser on the desktop, and Opera and Firefox for Android. Microsoft is working on support for the Edge browser, but there will be no support for Internet Explorer.
At this point, it is unknown whether Apple will support service workers. Support is still marked as Under consideration, so if they decide to go ahead, it will still take time for it to be implemented in the browser. For now, Safari users will have to make do with the website version of your progressive web apps. However, there is a reason to be cautiously optimistic that the feature will land within the next few years because the WebKit developers have at least talked about adding support for service workers in their unofficial five-year plan.
Fortunately, given the nature of how we develop Progressive Web Apps, it is possible to develop websites that look and work great on browsers that don’t support service workers, and at the same time works progressively better on browsers that do support service workers.
In the next part of this article series we'll take a look at the manifest and introduce the service worker.