Web Application to Progressive Web Application Migration Guide
Cyril Schmitt – Swisscom Digital Technology SA Florian Maffini – Swisscom Digital Technology SA
In collaboration with Service de l’informatique et des télécommunications de l’Etat de Fribourg (SITel)
March 20th, 2020
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 1 / 66 Table of Contents
WHO IS THIS DOCUMENT FOR? ...... 4
PROGRESSIVE WEB APPLICATION ...... 5
1 HISTORY ...... 5 2 CORE IDENTITY ...... 5 3 USER EXPERIENCE ...... 6 4 MARKET ...... 7
DEFINE BUSINESS NEEDS ...... 10
1 BUSINESS NEEDS ...... 10 2 USER JOURNEYS AND BUSINESS RULES ...... 10
GATHER WEB CAPABILITIES AND CHECK FEASIBILITY ...... 12
1 STATE OF THE WEB ...... 12 2 BROWSER SUPPORT ...... 16
EVALUATE PWA MIGRATION KNOWING MAJOR DECISION VECTORS ...... 21
1 TECHNOLOGY ...... 22 2 FUNCTIONAL COVERAGE ...... 22 3 DEVELOPMENT COST AND EFFORT ...... 22 4 PERFORMANCE ...... 23
IMPLEMENT FOUNDATIONAL REQUIREMENTS (LEVEL 1) ...... 24
1 WEB SITE IS SERVED OVER HTTPS [B1] ...... 24 2 PAGES (I.E. URLS) SHOULD LOAD OFFLINE [B2] ...... 25 3 WEB APP METADATA FOR HOME SCREEN INSTALLATION [B3] ...... 26 4 RESPONSIVE WEB DESIGN [E1] ...... 27 5 CROSS BROWSER SUPPORT [E2] ...... 28 6 FIRST LOAD FAST ON 3G [E3] ...... 29 7 SEAMLESS PAGE TRANSITION [E4] ...... 30 8 ONE PAGE = ONE URL [E5] ...... 31 9 USE COMPRESSION FOR TEXT RESOURCES [E6] ...... 32 10 ELIMINATE RENDER-BLOCKING RESOURCES [E7] ...... 33
IMPLEMENT ADVANCED REQUIREMENTS (LEVEL 2) ...... 35
1 INSTALL PROMPT BANNER SHOULD BE USED WISELY [O1] ...... 35 2 INTERCEPT PROMPT AND DIFFER DISPLAY AT A CONVENIENT TIME [O2] ...... 36 3 DETECT AND INFORM USERS ABOUT DISCONNECTION [O3] ...... 37
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 2 / 66 4 AVOID JUMPING CONTENT/IMAGE AS IT LOADS [O4] ...... 38 5 RETAIN SCROLL POSITION ON PREVIOUS PAGE [O5] ...... 39 6 NO OVERLAP BETWEEN KEYBOARD AND TEXT INPUTS [O6] ...... 40 7 AVOID FRAGMENT IDENTIFIER [O7] ...... 41 8 CONTENT SHOULD BE EASILY SHARABLE [O8] ...... 42 9 EXPLAIN USER ABOUT PUSH NOTIFICATIONS CONTEXT [O9] ...... 43 10 DIM THE SCREEN WHEN REQUESTING PERMISSIONS [O10] ...... 44 11 NOTIFICATIONS MUST BE TIMELY, PRECISE AND RELEVANT [O11] ...... 45 12 PROVIDE A NOTIFICATION SETTING PAGE [O12] ...... 46 13 ALLOW INDEXATION OF PAGES [O13] ...... 47 14 METADATA FOR SEARCH ENGINE AND SOCIAL NETWORKS [O14] ...... 48 15 CANONICAL URLS [O15] ...... 49 16 SEAMLESS CROSS DEVICE LOGIN FLOW [O16] ...... 50 17 USER CAN PAY USING NATIVE TRUSTED FUNCTIONALITY [O17] ...... 51
IMPLEMENT QUICK WINS (BONUS) ...... 53
1 CLEAN UNUSED CSS [QW1] ...... 53 2 USE OPTIMIZED FORMATS FOR IMAGES [QW2] ...... 54 3 MINIFY JAVASCRIPT [QW3] ...... 54 4 TEXT SHOULD REMAIN VISIBLE DURING WEBFONT LOAD [QW4] ...... 55 5 STATIC ASSETS MUST BE SERVED WITH AN EFFICIENT CACHE POLICY [QW5] ...... 55 6 BACKGROUND AND FOREGROUND COLORS MUST HAVE A SUFFICIENT CONTRAST RATIO [QW6] ...... 56 7 LINKS SHOULD HAVE A DISCERNIBLE NAME [QW7] ...... 56 8 LISTS SHALL ONLY CONTAIN
DEPLOY AND TEST ...... 59
1 ANALYTICS ...... 59 2 A/B TESTING ...... 62
FORECAST ...... 63
GLOSSARY ...... 64
SOURCES ...... 65
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 3 / 66 Who is this document for?
This document is addressed to any software engineering team, developer, project manager or product owner maintaining a Web-based product, publicly available, and willing to move forward in the adoption of the Web standards in order to deliver a great user experience to its users.
Basically, this document describes how to migrate from a classic Web app to a so-called progressive Web app (PWA), considering business needs and technical requirements.
This study has been performed end of the year 2019. Consequently, by reading this guide, you have to consider that standards, specifications, API, browsers support and market shares might have evolved ever since.
Finally, this document originated from a collaboration between SITel (Service de l’informatique et des télécommunications de l’Etat de Fribourg) and Swisscom Digital Technology SA (Open Web Technology) in an effort to evaluate PWA technology for its cyber-administration portal. The goal of the project was to enhance the interactions with the citizens at a suitable cost perspective. This document is the result of the previous mentioned evaluation aiming to make the methodology followed available to any other administrative district or citizen looking forward to new web technologies.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 4 / 66 Progressive Web Application
What is PWA in 2020?
1 History
Web has grown very fast over the last years, starting from static web pages rendered on the servers to fully dynamic client-based web application. The apparition of the smartphones (especially Apple iPhone) promoting the web as the next platform for App developers, forced the Web standards to move forward. Particularly by adapting the technology to fit the diversity of device screens’ size.
Lot of handful features came into play enabling the Web app to access the hardware’s screen size and therefore let the developers adapt the rendering of the app based on this information (e.g. CSS3 and media queries). This approach is being called responsive Web design (RWD).
Today, RWD is considered as a “de facto” standard in Web development. As the web evolved and its needs alongside, Web actors continued toward the direction of adapting Web app to their running environment by leveraging hardware capabilities. This evolution gave birth to progressive Web apps. The term “progressive” is all about providing a native app-like user experience limited only by the underlying eco-system on which the app runs. This means PWA will gracefully degrade its functionalities on device/OS with fewer features and capabilities (e.g. small screen, no GPS, no connection) but also enrich whenever the device/OS offers much more (e.g. big screen, 4G bandwidth, bio-authentication, ...).
2 Core identity
Implementing PWA is all about following principles (or pillars) that ensure the app is providing the best possible user experience on the strength of the latest Web standards. Here are those principles:
• Progressive: work for every user, regardless of the browser chosen because they are built at the base with progressive improvement principles. • Responsive: adapt to the various screen sizes: desktop, mobile, tablet, or dimensions that can later become available. • App-like: behave with the user as if they were native apps, in terms of interaction and navigation. • Secure: exposed over HTTPS protocol to prevent the connection from displaying information or altering the contents. • Updated: ensure information is always up to date thanks to the data update process offered by service workers.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 5 / 66 • Discoverable: ensure they are identified as “applications” and are indexed by search engines. • Re-activable/Re-engageable: make it easy to reactivate the application thanks to capabilities such as web notifications. • Installable: allow the user to install the app with the corresponding icon on the screen of his mobile terminal (home screen) without having to face all the steps and problems related to the use of app stores. • Linkable: ensure content is easily shared via URL and app state is recovered thanks to deep linking. • Connectivity free: avoid usual error message in case of weak or no connection. Instead the UX is designed so the app adapts with a limited content and feature scope. This principle is built on the fact that, if the app feels working good even in low network condition, it will deliver best in class performances under normal or good condition.
By considering those principles in every change you perform in our Web application (if not building it from scratch), you ensure to deliver the best of the Web, without compromising the user experience.
3 User Experience
Modern PWAs are indeed capable of native-like features such as offline usage or push notifications but also, they are able to capture from cameras, authenticate with biometrics and many more. Let’s have a closer look to a few concrete scenarios and how they bring the Web apps to a new level:
• Behaves like a native app
When installed on the home screen, the app looks and behaves like a native app, without browser frame. Transition from screen to screen is immediate and smooth to allow the users for a seamless interaction flow while navigating the app.
• Offline and low network capable
Even in the worst network condition or offline you can reach some critical features of the app. Advanced scenarios are the ones about writing data. In such a situation, the app simply writes the information entered by the user locally on the device and postpone the delivery to the server to a later time (basically when network connection is back). Opening a new case and taking notes even in a train tunnel or a lost forest become possible on the Web.
• Web push notifications
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 6 / 66 Push notification have always been a feature of mobile applications and now they made their way to the standardized Web. It is a huge improvement to reconnect with its users. Coupled with proper deep linking, the user can be brought to the right place/screen within the app when opening the notification. Definitely a good tool for event-based scenarios.
• Biometric authentication
It allows for a better security against identity theft and by protecting credentials. It will be the unavoidable companion of the secure Web. Such a feature enables scenarios like password-less authentication, allowing seamless UX and increase of the adoption.
This is a set of what the Web is able to achieve. It now allows much more than those previous features, but they are the foundation, and at the same time a goal, when considering migrating to PWA.
Even if it looks promising, you have to keep in mind that the whole feature set availability is directly driven by the level of support provided by each browser. It may be different from device to device, due to the diversity of operating systems and actors out there on the market. Nevertheless, standardization is moving at a high speed and should bring most of these features (if not all) to all devices in a near future.
4 Market
Here is the market segmentation based on platforms, or device types (November 2019 - Switzerland):
Platform repartition
Mobile (37.5%)
Tablet (4.8%)
Desktop (57.6%)
Today, we have 3 main types of device that browses the Internet: mobile, tablet and desktop. Desktop is still the most used platform in Switzerland whereas the mobile took the lead considering the worldwide data. Mobile usage is growing for more than a decade now and will be the first used platform, market share wise, in every country in the near feature. Hence, the hurry for Web standards to bring convenient ways of integrating the Web into a mobile UX.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 7 / 66 Digging a little bit more, we can have a look at the market segmentation for Mobile and Tablet platforms based on their operating systems and browsers (November 2019 - Switzerland): Mobile OS repartition Tablet OS repartition
Android (53.2%) Android (23.2%)
iOS (46.4%) iOS (76.6%)
Others (0.4%) Others (0.2%)
Mobile browsers repartition Tablet browsers repartition
Chrome (40.5%) Chrome (20.7%) Samsung (11.7%) Firefox (1%) Firefox (1%) Safari-Webkit (72.4%) Safari-Webkit (44.9%) Others (5.9%) Others (1.9%)
On iOS, all the browsers are actually built on top of WebKit. For example, Chrome for iOS is actually using Webkit and is part of the Safari-Webkit market shares.
Regarding the mobile segment, Switzerland is a specific market where Android and iOS engaged in a very balanced fight. They both managed to impose their main Web browser (resp. Safari-WebKit and Chrome) sharing equally a major part of market. However, it is important to highlight the performance of Samsung Internet browser, which has penetrated the market by reaching 10% of the shares. It can be explained by 2 reasons. First, it is the default browser of the Samsung smartphones. Secondly, Samsung Internet browser is actually using the Chrome engine behind the scene (Chromium, Blink), which is bullet proof and one of the most achieve engine, regarding Web standards adoption.
On the tablet segment, the situation is quite clear with the monopoly of Apple with Safari- WebKit. It indicates where critical tablet’s scenarios have to be properly designed, developed and tested. Interesting fact about mobile and tablet segments is that they are barely comparable in terms of browsers support. This means a given browser will behave and provide the same level of support on mobile and tablet, reducing development effort.
Market segmentation for Desktop platform based on their operating systems and browsers (November 2019 - Switzerland):
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 8 / 66 Desktop OS repartition
Windows (67%) MacOS (30.2%) Others (2.8%)
Desktop browsers repartition
Internet Explorer (8.7%) Edge (9.1%) Safari-Webkit (17.5%) Chrome (46.9%) Firefox (15.6%) Others (2.2%)
Edge is dropping EdgeHTML for Blink (Chrome engine), jumping from version 44 to version 78 (happening early 2020), spreading and increasing market shares on Desktop segment.
Desktop wise, the leader of the segment is by far Google Chrome with almost half of the market. The 2 other big players are Mozilla Firefox and Apple WebKit that have to be considered too while developing a Web app. Add in Microsoft Edge in the mix and the user coverage hits almost 90%. In 2020, supporting Microsoft IE is an option and can be left apart to avoid any over complexity, additional cost and ultimately poor UX.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 9 / 66 Define business needs
What are my business needs? PWA migration requires various components to be successful and complete. Among them, it is important to differentiate the needs coming from the Web itself and the needs coming from the business. The Web platform needs are basically the minimum technical changes absolutely necessary to migrate towards PWA, they represent the foundation. These Web requirements will be explained in detail in a later section in this guide.
What comes from the Business → What the business wants you to implement? What comes from the Web → What the Web want you to implement?
The business needs on the other hand, are all the requirements leading to the implementation of new functionalities within a Web app. Let’s see how to proceed to gather and define your business needs for your future PWA.
1 Business needs
The definition of the business needs can either start based on your current Web app functionalities or from scratch for brand-new functionalities. Either way, it is recommended to create the complete list of business needs, the user journeys covering those business needs and their business rules attached.
For instance, in the case of a PWA migration, you could have a look at your current offering and spot new opportunities to improve it; an easy example would be the migration of the login towards PWA to leverage the biometrics capabilities. The business need here would be: “As a user, I would like to login using my biometrics when possible/applicable”.
On the other hand, if you want to create a new functionality, you could start by having a look at what the Web platform offers in order to ideate around them and your potential customer’s needs (for a full list of Web features, see table in this section). An example of a new business need could be the following: “As a hunter, I wish to report my kill, as stated by the federal law, wherever I am”.
This last business requirement will be used throughout the whole guide in order to explain each step that are recommended to follow so it can be delivered as a new functionality within a Web app.
2 User journeys and business rules
Once your business needs identified, it is important to add context to each of them; this will ensure a good contextual understanding to not forget any detail. This action can be performed by defining the user journeys and the associated business rules.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 10 / 66
The user journeys will detail each step the user will have to take to reach his/her objectives. In the case of the hunter, the journey starts when he/she is just killed an animal in the forest and ends once the kill data are uploaded. The business rules will define the canvas and at the same time the limitations in which the app’s UX can progress to ensure the fulfilment of the goal.
Reach hunting Shoot animal Open app Log in Fill in information Upload information section
Hunter is walking Hunter open the Hunter identifies Hunter access the Hunter fill in hunting Hunter’s killing data are
in the forest, find app right after him/her-self on the right app feature to details and upload uploaded.
Story a prey, shoot it the kill. app. declare the kill. data. and kill it
Even without Even without Even without Even without network, As soon as the network network, the network, the hunter network, the hunter the hunter should be is back, the data are hunter should be should be able to should be able to able to submit hunting uploaded. able to load the log in the app. load needed pages data (incl. welcome app to reach the hunters geolocation). Business rules Business page. section.
Proceeding step by step, we end up with the above scenario, which respect the business rules and answer to the given business need.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 11 / 66 Gather Web capabilities and check feasibility
What Web capabilities support my business need? Is it technically doable?
1 State of the Web
Considering each business need, you have to find what Web capability can support you in answering it.
This is a close work between product owners, designers and technical experts to find out what is the best match between a functional requirement and a Web capability in order to deliver the best UX. From that Web feature or capability come the technical context, described by the standard itself.
Web standards are specified and edited by consortiums named W3C and WHATWG. Below is an exhaustive list of what the Web can do in 2020 alongside with the maturity of their standard (updated December 2019).
Standard Status ID Group Feature Scope Remarks Recommendation (W3C or WHATWG)
Available factors Multi-factor authentication: biometric (e.g. Web are different from 1.1 Recommendation finger or face), USB token, Bluetooth, NFC OK
Authentication browser to token. browser.
Credential Store and request user credentials allowing 1.2 Authentication Management Working Draft automatic sign-in capability without providing OK
API any password.
Geolocation Read and watch position of the device 2.1 Recommendation OK
API depending on a requested accuracy.
Define geographic areas and receive notifications when the device Working Group
2.2 Geofencing API enters or leaves these areas without the need to periodically query NOT OK Note the Geolocation API.
Determine the static orientation of the user's device in all the three Device 2.3 Working Draft dimensions, expressed in degrees of divergence from the "natural" OK
Orientation API northbound lie flat position.
Generic Sensor Expose sensor data to the Open Web Platform 2.4 Working Draft OK
API in a consistent way.
Obtain information about acceleration applied Geolocation & Position & Geolocation 2.5 Accelerometer Working Draft to the three primary axes of a device that OK hosts the sensor.
Monitor the rate of rotation around the 2.6 Gyroscope Working Draft OK device’s local three primary axes.
Proximity Detect whether there is a physical object near 2.7 Working Draft NOT OK
Sensor the device.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 12 / 66 Access streams from the device's audio and video capturing Media Devices Candidate 3.1 interfaces, i.e. to use the data available from the camera and the OK
API Recommendation microphone.
Attempt to Media Device Candidate Describe device's capture interfaces (id, kind, unify/standardize 3.2 NOT OK
Info API Recommendation label, ...). information about capture devices.
Audio/Video Capture Audio/Video Media Recorder Record audio and video media streams (local 3.3 Working Draft OK
API or remote).
Web SQL Database specification is no longer being Web SQL Working Group Client-side database that can be query using 4.1 maintained and NOT OK
Database Note SQL. support may be dropped in future versions.
Client-side key-value store for hierarchical Indexed 4.2 Recommendation objects. The database maintains indexes over OK Offline Database API records.
Candidate Store responses received from the network 4.3 Cache API OK Recommendation per origin (available offline).
Middleware component acting between the client page and the Candidate
4.4 Service Workers network to leverage requests and responses behavior depending on REQUIRED Recommendation the network conditions (e.g. offline support).
Subscribe the user for the remotely sent messages that can trigger
5.1 Push API Working Draft displaying a notification to the subscriber even if the Web app is not OK currently in foreground.
Apple has its own Safari Push Apple proprietary implementation of remote standard only 5.2 OK
Notifications push notifications. working in Safari Notifications Desktop.
Triggers the display of local notifications when 5.3 Notification API Living Standard OK Web app is in foreground.
Define name, icon, full screen behavior, Basically, defines
6.1 Web Manifest Working Draft theme, appearance, ... when added to home the identity of the REQUIRED screen. PWA
With Permissions
API the app can list the permissions Query for the permission status for the
6.2 Permissions API Working Draft granted by the OK features that might require user consent. user without Installable actually triggering the feature itself.
Primary reason for Page Visibility Proposed Detect whether the Web app is in background 6.3 that is to reduce OK
API Recommendation or foreground. the battery usage.
Web Allow Web apps to not rely on having stable internet connection and Draft Community
7.1 nd Background defer network-related operations to the moment the connection is NOT OK Back grou Group Report
Synchronization available.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 13 / 66 Task Scheduler Working Group Schedule task at a specified time whether the 7.2 NOT OK
API Note application is active or not.
Apple also
includes support Payment Candidate Delegate the payment checkout process to 8.1 for Apple Pay on OK
Request API Recommendation the operating system.
Payment compatible devices.
An Intent is a user-initiated action delegated to be performed by a service. Web Intents Working Group Non-standard
9.1 Web Intents provides a declarative syntax allowing services NOT OK Note solution. to list the Intents they handle and data communication between Web app and OS.
Sharing 9.2 Web Share API Editor's Draft Trigger platform-specific share mechanism. OK
Web Share Draft Community 9.3 Register a Web app as share receiver. OK
Target API Group Report
Web Bluetooth Draft Community Discover and communicate with Bluetooth- 10.1 NOT OK
API Group Report enabled devices and services.
Draft Community Interact with the Universal Serial Bus- 10.2 WebUSB API NOT OK Group Report compatible devices available in the OS.
Draft Community Access and exchange data with the Near Field 10.3 Web NFC API NOT OK Group Report Communication devices, such as NFC tags. Communication
Candidate Send and receive streaming real-time video, audio and data to/from
10.4 WebRTC OK Recommendation remote peers, without relying it through the centralized server.
Read Access to OS file system without sending 11.1 File API Working Draft OK files to server.
Working Group Still an experiment
11.2 Contacts API Read Access to OS contact and address book. NOT OK Note at this time.
Native Working Group 11.3 Messaging API Read and send SMS/MMS using OS. NOT OK Note
Storage Quota Persistent storage per origin and quota 11.4 Living Standard NOT OK
Estimation API management.
Network Draft Community 12.1 Read current network type and quality. OK
Information API Group Report
12.2 Vibration API Recommendation Triggers device's built in vibration. OK
Battery Status Candidate Get information about device's power source, 12.3 OK
API Recommendation battery level, time of charging/discharging
Device Get the class of the device by the size of the RAM memory installed. Device Memory It might be used to identify the lower-end devices to provide the 12.4 Working Draft NOT OK
API reduced, lightweight experience of the website for performance reasons.
Ambient Light Access the light intensity level measured by Experimental for 12.5 Working Draft NOT OK
API the device's light sensor. now.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 14 / 66 Touch Events Handle hardware agnostic pointer inputs from 13.1 Recommendation OK
API devices such as mouse, pen, touch screen, ...
Pointer Events Handle one or more points of contact with 13.2 Recommendation OK
API touch-sensitive surface.
Speech Draft Community Incorporate speech recognition and synthesis 13.3 NOT OK
Inputs Recognition API Group Report capabilities.
Speech Draft Community Incorporate speech recognition and synthesis 13.4 OK
Synthesis API Group Report capabilities.
13.5 Clipboard API Working Draft Read and write the OS clipboard. OK
Discover available VR/AR devices, establish a Legacy API. Should
14.1 WebVR API Editor's Draft session with the device, read the device- be replaced by NOT OK specific geometry data required. WebXR.
WebXR Device Discover available VR/AR devices, establish a session with the device, 14.2 Working Draft OK
API read the device-specific geometry data required.
Present the website or part of the website in
14.3 Fullscreen API Living Standard full screen mode, without browser and OK
window UI elements.
Outputs Read the screen orientation type and angle, to be informed when Screen 14.4 Working Draft the screen orientation changes, and to lock the screen to a specific OK
Orientation API orientation.
Candidate Prevent some aspect of the device from entering a power-saving
14.5 Wake Lock API NOT OK Recommendation state (e.g., preventing the system from turning off the screen).
Allow Web app to use the presentation display mode. The display Presentation Candidate 14.6 used to present may be the same that the browser is using but may NOT OK
API Recommendation also be the external display device.
As you can see, most of those standards are not finalized yet. Nevertheless, it does not mean they must not be implemented. Indeed, the maturity of a standard has to also be correlated with the welcoming of the Web community regarding that standard. Most of the time, Web browsers feature adoption is ahead and influence back the inner specification of the standard, thus directly driving browsers support.
The last column of this table considers these “community” factors. It takes into consideration if the standard is most likely to be adopted in the long term; thanks to the specification progress and recent activity, to the community smell/feedback, to any communication or forecast provided by Web browser integrators (see Chrome Status), without forgetting the current state of Web browsers support. In the end, we obtain a pretty strong recommendation built out from those factors, that you can rely on during your migration process.
In the following section, you will find a detailed table showing how those same features are supported in the different Web browsers of the market.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 15 / 66 2 Browser support
When the match is found and you are looking forward using a new Web feature, comes the time to evaluate the support of such a feature among the Web browsers out there on the market. Again, this guide provides with an exhaustive list of Web capabilities with their level of support in the different Web browsers (updated December 2019).
Mobile / Tablet Desktop Platform (37.5%/4.8%) (57.6%)
Android iOS Windows macOS Operating System Cross-platform (53.2%/23.2%) (46.4%/76.6%) (67%) (30.2%) (macOS, Windows, Linux)
Safari- Safari- Chrome Samsung Firefox IE Edge Chrome Firefox Web Browser Webkit Webkit (40.5%/20.7%) (11.7%/0%) (1%/1%) (8.7%) (9.1%) (46.9%) (15.6%) (44.9%/72.4%) (17.5%) Last Major Version 78 10 68 13 11 44* 13 78 70
ID Group Feature Supported as of version…
1.1 - Web Authentication 67 0 68 13.3 0 18 13 67 60 Credential 1.2 Authen tication 51 7.2 0 0 0 0 0 51 0 Management API
2.1 Geolocation API 18 4 6 3.2 9 12 5 4 3.5
2.2 Geofencing API 0 0 0 0 0 0 0 0 0 Device Orientation 2.3 18 4 6 4.2 11 12 0 7 6 API 2.4 Generic Sensor API 69 0 0 0 0 0 0 69 0
2.5 Accelerometer 67 0 0 0 0 0 0 67 0
2.6 Position & Geolocation Gyroscope 67 0 0 0 0 0 0 67 0
2.7 Proximity Sensor 0 0 15 0 0 0 0 0 15
3.1 Media Devices API 47 10.1 33 11 0 18 11 47 33
Media Device Info 3.2 55 6.2 39 0 0 18 0 55 39 API Capture
3.3 Audio/Video Media Recorder API 47 5 58 0 0 0 0 47 58
4.1 Web SQL Database 18 4 0 0 0 0 3.1 4 0
4.2 Indexed Database API 18 4 6 8 10 12 7.1 11 4
4.3 Offline Cache API 43 4 39 0 0 18 11 43 39
4.4 Service Workers 40 4 44 11.3 0 17 11.1 40 44
5.1 Push API 50 4 44 0 0 17 0 50 44 Safari Push 5.2 0 0 0 0 0 0 9 0 0 Notifications
5.3 Notifications Notification API 18 10.1 6 0 0 14 6 5 4
6.1 Web Manifest 39 4 68 11.3 0 0 0 39 0
ble 6.2 Installa Permissions API 43 10.1 46 0 0 0 0 43 46
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 16 / 66 6.3 Page Visibility API 18 4 10 7 10 12 6.1 14 10
Web Background 7.1 - 49 5 0 0 0 0 0 0 0 Synchronization
Back 7.2 ground Task Scheduler API 0 0 0 0 0 0 0 0 0
8.1 Payment Request API 61 6.2 0 12.2 0 18 12.1 61 0
Payment
9.1 Web Intents 0 0 0 0 0 0 0 0 0
9.2 Web Share API 78 ? 0 12.2 0 0 12.1 0 0
Sharing 9.3 Web Share Target API 71 0 0 0 0 0 0 0 0
10.1 Web Bluetooth API 56 6.2 0 0 0 0 0 56 0
10.2 WebUSB API 61 0 0 0 0 0 0 61 0
10.3 Web NFC API 0 0 0 0 0 0 0 0 0
Communication 10.4 WebRTC 23 4 22 11 0 15 11 23 22
11.1 File API 18 4 6 6 10 18 6 13 3
11.2 Contacts API 0 0 0 0 0 0 0 0 0
11.3 Native Messaging API 0 0 0 0 0 0 0 0 0 Storage Quota 11.4 52 ? 51 0 0 0 0 52 51 Estimation API Network Information 12.1 61 0 31 0 0 0 0 61 0 API 12.2 Vibration API 30 4 11 0 0 0 0 30 11
12.3 Battery Status API 38 4 52 0 0 0 0 38 0
Device 12.4 Device Memory API 63 ? 0 0 0 0 0 63 0
12.5 Ambient Light API 0 0 0 0 0 0 0 0 0
13.1 Touch Events API 22 4 18 13.2 0 0 0 22 18
13.2 Pointer Events API 55 6.2 0 13.1 10 12 13 55 59
Speech Recognition 13.3 25 4 0 0 0 0 0 25 0 API Inputs 13.4 Speech Synthesis API 33 5 49 7 0 14 7 33 49
13.5 Clipboard API 66 10.1 63 0 0 0 0 66 63
14.1 WebVR API 0 5 0 0 0 15 0 0 55
14.2 WebXR Device API 0 0 0 0 0 0 0 0 0
14.3 Fullscreen API 18 4 10 12 11 12 5.1 15 10
Outputs Screen Orientation 14.4 38 5 18 0 11 12 0 38 18 API 14.5 Wake Lock API 69 10 0 0 0 0 0 69 0
14.6 Presentation API 48 6 0 0 0 0 0 48 0
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 17 / 66 Basically, version 0 means the API is not supported for the given Web browser. version X gives the first version of the corresponding Web browser which partially or fully support the API.
Depending on the business scope size, the goal here is to focus first on Web features/APIs with the best coverage among the Web browsers. Hopefully, the most basic requirements of PWA are well supported (like Service Worker API or Cache API).
Since PWA are “progressive” and the migration does not require to be performed at once. Keeping not so well supported APIs at the end of the migration (later versions) is a good strategy. First because support might evolve in between and also because your functional needs might evolve too, release after release.
Let’s jump back to our hunting example. After listing all of our business needs with their user journeys and associated business rules, we can now look for Web capabilities and check feasibility. In the table below you can find all the groups of Web features (i.e. Web API) involved in each step of the user journey to cover the business needs.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 18 / 66 Reach hunting Shoot animal Open app Log in Fill in information Upload information section
Hunter is walking Hunter open the Hunter identifies Hunter access the Hunter fill in hunting Hunter’s killing data are
in the forest, find app right after him/her-self on the right app feature to details and upload uploaded.
Story a prey, shoot it the kill. app. declare the kill. data. and kill it
Even without Even without Even without Even without network, As soon as the network network, the network, the hunter network, the hunter the hunter should be is back, the data are hunter should be should be able to should be able to able to submit hunting uploaded. able to load the log in the app. load needed pages data (incl. welcome app to reach the hunters geolocation). Business rules Business page. section.
- Offline - Offline - Offline - Offline - Offline
- Installable - Authentication - Geolocation - Device Groups
- Intercept hunting - Test network submission request to conditions*. store it*. - Check for hunting data Out of scope Out of scope Out of scope marked as not
checks uploaded*. Feasibility Feasibility - Perform request with hunting data*.
User should have User should have Depending on the If autocomplete Network detection can at least opened logged in at least architecture (SPA vs suggestion needed be tricky, so it works once the PWA. once before. MPA), the user (animal list), prior data reliably cross browser might need to have loading and caching is and OS.
accessed this specific required when online. While in background, page before – MPA; OS might not give not required for SPA. resources to perform the task.
Limitations If app is killed, probability of OS resources allocation to perform the task is even smaller if not null.
As a workaround, the - user needs to manually
re-launch the app to Work around trigger the upload.
Fill in information - Intercept hunting submission request to store it *
• Service Worker has registered to capture request to /api/hunting/kill endpoint. • When such a request is intercepted, the data is stored in IndexedDB (animal information, date, time, permit number, …) as a new record. • User Interface is updated to explain the user his hunting request has been saved and will be submitted as soon as the network is back online.
Upload Information - Test network conditions *
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 19 / 66
• The network is checked thanks to the Network Information API and/or online & offline events and/or long pulling technics (alternatively, see Offline.js). • Mixing ways improves reliability and browser support.
Upload Information - Check for hunting data marked as not uploaded on device *
• If online, the SW performs a query against IndexedDB to look for eligible record for upload (a flag can be used on the records to detect them).
Upload Information - Perform request with hunting data *
• Request is forged (payload built from the matching IndexedDB record) and sent to the hunting API endpoint. • IndexedDB record is updated and marked as “processed”. • UI is updated accordingly to the API response.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 20 / 66 Evaluate PWA migration knowing major decision vectors
What are the important things to know before migrating to PWA? Here is a comparison of the different technologies used to create mobile apps:
Native App Hybrid App Progressive Web
(Android + iOS) (web/native) App iOS (Swift) Flutter, React, Angular, ReactJS, Technologies Android (Java) Xamarin, Cordova VueJS
Functional coverage Complete Close to complete Partial
Technical complexity Medium Medium High
Dev. effort High Medium Medium
Dev. cost High Low Medium
Dependencies bottleneck Low High Low
Performance High Medium High
Portability Low High Very High
From this table, we can build up some pros and cons regarding PWA technology.
Pros
• Development cost is reduced thanks to a single code base to support all platforms. • Deployment is faster, clients are automatically on the latest version. • Does not rely on a store like the Apple App Store or the Google Play Store. • Portability is maximum thanks to the Web standards. • Feeling about performance is similar to native thanks to the progressive approach. • UX is seamless, no friction, non-blocking features.
Cons
• Complexity is higher due to cross browser/platform support and diversity of scenarios to be progressive.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 21 / 66 • Still a new technology – all browsers don't support it fully yet. • Limited hardware access.
1 Technology
Technology wise, there is a plenty of good Web frameworks that can be used for PWA. The major ones such as Angular, ReactJS and VueJS supports it even if they are not PWA-ready out of the box. However, a special mention to Angular which that comes with a strong awareness of PWA principles with some useful default implementations, scaffolding tools, and also PWA-related documentation for Service Worker for example (offline support, see sources).
2 Functional coverage
Regarding the functional coverage, there are two limitations that drive it. First, the capability of Web APIs to cover the desired use case (e.g. accessing Wi-Fi access points for display, is not possible in the current state of the Web platform). Second, when supported by the Web APIs, hardware actually needs to be accessible (e.g. some devices might not have GPS, or OS does not allow access to it). When building a native app, there is not such hardware restrictions because the provided SDK is meant to give access to it. For hybrid, whenever facing a hardware access issue, there is always the possibility to bridge to the native APIs.
3 Development cost and effort
The first thing that comes in mind for the development, is the shared code base. A single code base (= unique technology) thanks to the Web that unifies the platforms providing a maximum portability. Nevertheless, even if the Web standards are properly specified, it is not necessary well supported among the different Web browsers. Implementations or behaviors might differ from one to another, and you might need to adapt. That is where the first development effort has to be placed.
The second effort take place from all the shades of scenarios introduced by the nature of PWA. Let’s take the offline support as an example. If your most fundamental business requirement is to force the user to login before using the app, you have the cover all the possible scenarios considering the network states (no connection, slow connection, fast connection, low latency connection). Meaning you need a technical answer for each of those scenarios: how do I authenticate without network? What do I display if the login request takes too long? Everything becomes more complex since you have to forecast any possible situation that the user might be facing, and provide a non-blocking/no-friction UX.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 22 / 66 This is caused by the diversity of ecosystems on which PWA can run. They are a complex combination of device, operating system, web browser, and environmental/external variables. That is why, building PWA is a high complexity challenge compared to the native approach, where most of the conditions are known in advance.
Bottom line: even if some development cost is spared while using a unique technology, complexity in the design, the implementation and the support have to be considered too.
4 Performance
Performance is all about the relative feeling the user perceives while using an app. Unfortunately, the Web platform, by offering so many possibilities tend to lose the developers, requiring an important effort to ensure minimum performance. To deliver performances you have to invest in a good and strict code architecture as long as a great UX.
Technical architecture is what will deliver the raw performance of your Web App. Main things to consider is optimizing resources (images, CSS, Javascript and fonts) by using tricks like compression, minification, deferred/lazy loading and others. A complete list of recommendations is available in this guide, in the section below, and might also affect the server side.
Regarding the UX, common concepts around this topic are non-blocking interactions, navigation friction, optimistic UI which are partially covered in that same section.
To reach such a performance level, the development effort might be important. It could be assimilated to the pareto principle. Given that 100% is when all the recommendations of this guide are implemented, the implementation of last 20% represent the major part of the total cost of the Web app.
If all the PWA principles are properly followed, then the perceived performances might equal performances of native implementation, but it will never overpass it. Native apps do not require this extra effort to deliver performance; Their raw performance is the best.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 23 / 66 Implement foundational requirements (level 1)
What makes my WA become a PWA? The following recommendation list covers the minimal changes to operate on your Web app, so it becomes a PWA.
Each recommendation has to be estimated by the development team considering all dimensions of the recommendation. The most important are the mentions in scope, technical complexity and actions list.
Depending on the workflow and internal process, each recommendation can lead to the writing of a user story that would be split up in several tasks in order to dispatch the work among team members (business vs technical tasks).
1 Web site is served over HTTPS [B1]
All the resources (js, css, json, html, …) of the Web site must be served and Description retrieved though HTTPS by the Web Browser.
Group 4 – Offline
Scope Any resources (documents, scripts, stylesheets, fonts, images …)
Technical Normal complexity
Gains/Benefits Blocker
Actions list • Configure the HTTP termination and enable HTTPS for all endpoints
HTTPS becomes the « de facto » standard for any kind of resources. Still using Remarks HTTP exposes to security breach, incompatibility and blocking content policy.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 24 / 66 2 Pages (i.e. URLs) should load offline [B2]
When a user accesses a page, it should load even without network Description (e.g. airplane mode), URL responding with a 200.
Group 4 – Offline
Critical pages (login, profile, help) Scope Finest granularity is the URL, meaning 2 pages (or states) with the same URL have to be considered the same.
Business priority P1
Technical Very hard complexity
Gains/Benefits Blocker
• Setup a service worker for the home page (e.g. /) • Add relevant pages in the Cache Actions list • Provide a default offline page for pages that will not be available, or found in cache
You may not always need to support a functionality while offline. Sometimes it is technically impossible, sometimes not relevant. A set of mandatory pages has to be defined by the business (cf. Remarks scope). For implementation details regarding Service Workers, we suggest Workbox.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 25 / 66 3 Web App metadata for home screen installation [B3]
A manifest holds the Web app metadata that define colors, icons, Description title, orientation and much more to support home screen installation.
Group 6 – Installable
Scope 1 manifest per Web app
Technical Normal complexity
Gains/Benefits Blocker
Actions list • Add a manifest for root URL path
Remarks Follow Implementation guide.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 26 / 66 4 Responsive Web Design [E1]
Ensure the Web app displays properly and reasonably on mobiles, Description tablets and desktops.
Group 14 – Output
Scope All pages
Technical Very hard complexity
Gains/Benefits Enabler
• Set the viewport with proper initial scale and zoom capability • Use media queries and devices orientation to adapt display Actions list • Take benefits from UI Frameworks like Bootstrap, Foundation, Semantic or Materialize to handle layout for different screen sizes
Remarks Follow Implementation guide.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 27 / 66 5 Cross browser support [E2]
Description Ensure the Web App can be used in any major browser/environment.
Group
Scope All pages
Technical Normal complexity
Gains/Benefits Enabler
• Support IE 11 • Support Safari (evergreen) Actions list • Support Chrome (evergreen) • Support Firefox (evergreen) • Support Edge (evergreen)
Browser support directly drives adoption which is a key parameter when expecting end-users to change their behavior and usage for a Remarks new Web app. Going PWA might significate to abandon Internet Explorer support for cost and maintainability reasons.
WA to PWA Migration Guide | SITel - Swisscom Digital Technology SA 28 / 66 6 First load fast on 3G [E3]
Description Time to interactive must be less then 10 seconds over simulated 3G network.
Group Performance
Landing pages Scope Login page is considered as a landing page
Technical Hard complexity
Gains/Benefits Enabler
• Enable compression for text resources (e.g. GZip) [E6] • Implement asynchronous JS loading opportunities