This year, in the beginning of April, Safari has moved closer to other evergreen browsers releasing support for web APIs needed to build offline web apps!
A modern web platform as a whole has become more enhanced and feature-rich:
-Browsers have undergone fundamental rewrites of their engines to allow advanced capabilities on par with mobile platforms
-Many technologies were reconfigured with enhanced interfaces to meet the emerging demands of users, developers, and regulators
-No need for 100 Mb binary downloaded on each app update. Just small chunks of actually used functionality, dynamically cached for offline interaction
This opens the door to new user experiences, which, by the way, many companies have been exploiting for quite a while yet.
Here we would like to discuss the current web APIs for developing fully-fledged web apps, along with the business perspective for investing in these types of apps today.
It’s been a long journey for web technologies and HTML to become the foundation for mobile apps. However, at the end of the first decade of the 2000’s, a web platform wasn’t yet quite ready for a universal spread, and investment decisions moved in another direction.
The apps in which users spend most of their time today are made with native Android or iOS interfaces, in Java/Kotlin or Objective-C/Swift.
But the Web never sleeps. Dramatically, a huge change has happened again thanks to a move from Apple. This time with Safari.
Now, you’d be thinking that mobile apps have brought us to a higher level of user interfaces and new experiences. Slick animations, advanced responsiveness to intuitive gestures, and great performance uninterrupted by network conditions. That feels awesome and almost expected by users today. But another change is brewing.
Web technologies have been missing core capabilities required by apps developers. Today, web is getting these capabilities and will bring us to another, more enhanced level.
Web apps or PWA (Progressive Web Apps) can actually shift the ground closer to a new generation of mobile apps built on web technologies. Evergreen browsers are starting to cover the most used native features of mobile apps, further enhancing them with web platform capabilities:
-Web has long superseded mobile apps for discoverability of content
-[Payment Request] (https://developers.google.com/web/fundamentals/payments/) and [Credentials Management] (https://developers.google.com/web/fundamentals/security/credential-management/) APIs have brought one tap and fingerprint confirmations on shopping and authentication flows
-Web Push Notifications API is more developer-friendly
-Complex animations, off-loaded to hardware, allow for greater performance for gesture-based intuitive interactions
All of these features become cross-platform with the web. On top of that, web apps can work with small chunked downloads of the functionality the user actually requires and yet be available offline as fully downloaded mobile apps. These small app chunks are updated at any time, and new features are deployed, avoiding complex app stores reviews.
With the web we can consider any app as made of a few smaller apps, comprising an independent part of functionality.
There are many more web APIs which converge native iOS and Android platforms with browsers. Check out this great compilation of [what the web can do today](https://whatwebcando.today/). You may also find handy examples of using some of the latest web APIs in [this section](https://developers.google.com/web/fundamentals/native-hardware/user-location/) of web fundamentals.
Google’s Chrome team have pushed the development in this field, starting from 2014. The Firefox community kept pace. [Edge] (https://twitter.com/tomayac/status/960963468756180993) with [Safari] (https://twitter.com/addyosmani/status/979606651429822464) were also doing a huge job to align and re-write their engines. Finally, Safari has landed their support for the main underlying technology Service Worker API.
We are finally reaching the highway for offline web apps being broadly shipped!
Thanks to Service Workers, a modern web app provides:
-A home screen icon that opens the web app in a full-screen mode as a native app
-Native dialogs to add the app to home screens with one click
-A fast and interactive app, even with unreliable network connection
-Push notifications to get users back to your app
Service Worker is a type of web worker processing app’s resource requests and server notifications in a parallel thread or in the background, when the app is running in the main thread or is completely inactive. With Service Workers you can arrange background communication with servers and schedule tasks. You may think of it as a parallel web service, running with your app on the client.
A Service Worker intercepts app network requests and makes it possible:
-to use the Cache Storage API for app resources (i.e., HTML, CSS, JS, and image files)
-to make network requests using the Fetch API
-to persist data using the IndexedDB API
-to respond to the intercepted requests with a certain caching strategy
You can respond to any request with the cached resources/data on stable, interrupted, or lost connections. Such granular cache management will be much more complex to implement with native app technologies, and the user needs to download all the app resources upwards. For security reasons, Service Worker cannot access the DOM directly and uses postMessage interface to communicate with the pages under its control to request DOM updates.
Thus, developers can rely on these new features:
-PWAs can pre-cache parts of a web app so that it loads instantly the next time a user opens it
-you can manage multiple caches
-you can minimize data traffic by deciding what gets served from a cache, the local data store, or the network
-you can save offline user-generated data until online again to send it
-it is memory efficient as the browser starts and stops service workers when inactive
To learn more, Google have recently opened to public its [course on PWA] (https://developers.google.com/web/ilt/pwa/), which we recommend as a great overview of the main apps-related web APIs and nice starting point to try them out. Also we’d suggest this [video-series] (https://www.youtube.com/watch?v=z2JgN6Ae-Bo&index=1&list=PLNYkxOF6rcICnIOm4cfylT0-cEfytBtYt) from last month with detailed overview of web apps capabilities.
Let’s now return to the main questions. We could define the most important features users expect from an app as:
-Fast. Smooth animation, jank-free scrolling, and seamless navigation
-Integrated with OS. Launched from the home screen. The user doesn’t have to reach your app through the browser. It uses the full capabilities of the device
-Reliable. Fast loading, works offline and with a flaky network
-Engaging. Sends push notifications to bring users back when it is relevant for them
This is the FIRE concept (as defined by Google). And now web provides developers with all these capabilities.
This brings previously evolved Single Page Applications to the level of native apps, making them the Web Apps.
Front-end is evolving with increasing speed. All of these are possible ways to deliver a web app: SSR (server-side rendering), CSR (client-side rendering), a hybrid way, pre-rendering, cashing snapshots, and streaming. You are definitely going to need a front-end architect today!
According to Google’s data, for native apps 80% of time is spent in each users’ top 3 apps. Just 3 apps! Whereas, Chrome users on Android visit 100 sites per month. Every 2 in 3 purchases on mobile are on the web, not in the native apps! Finally, the cost of acquisition is much lower with web apps, thanks to their discoverability through the web search.
The hardest problem with software is distribution
Many companies have shown that PWAs give a completely new experience in speed of distribution. The goal is to get users to use the service, not to install the app. With the PWA, a user comes from visiting a landing page to an app immediately, skipping the install step.
Companies can provide distant mobile services to their clients without complex app store registration and distribution processes. They can update their apps and release instantly.
AliExpress with their PWA saw a massive uplift in time spent on the site (74%), and two times more pages visited. Further, progress in PWA means that users with limited current browser support still get a meaningful experience, allowing AliExpress to achieve an 82% increase in their conversion rate on iOS (with the old Cache API)!
When you think about proposing a path to integrate offline and new web capabilities, these can be the possible ways:
-Build from the ground up
-Start with another version
-Focus on a single feature
Another e-commerce example is Konga, which operates in Africa, where data usage is costly. They started from scratch, building web catalogue and check-out functionality so they are available offline, focused heavily on minimizing data consumption. Now, comparing data usage to their native app, the initial load took up 92% less data and data usage for the first transaction was 82% lower.
Another approach is to build a second version of a site or even a single feature to improve on a specific section or user journey. Air Berlin couldn’t start with a site-wide PWA, so they focused on the post-booking experience. Their busy users at the airport require quick access to itinerary details, boarding pass and destination information. Now, when you fly Air Berlin the load times for this information is under a second, even without internet. It is a fast, engaging, reliable experience.
Twitter has become the classic example of a company exploring offline web app features for a couple of years now with their Twitter Lite PWA. Their apps sizes range from 24 Mb for Android, 214 Mb for iOS, and 0,6 Mb for web app. And web is also most used with more active monthly users than any other Twitter client.
Want more? Check which sites you’ve visited in Chrome that use Service Workers - navigate to this URI: chrome://serviceworker-internals
It’s all done and ready then? Not yet. For now the main issues are:
-There’s still no Web Push or Background Sync on iOS (and it will take time). Safari have yet to resolve quite a few bugs, including app reloading after being in an inactive state. But their latest commitment makes us think it won’t take years to do.
-Web apps storage cannot be so big as for a native app. You need to manage responsibly the device storage your app uses.
-Integration with mobile operating systems needs still to be deeper so we get further convergence of apps-related web APIs and native interfaces.
-Of course there is no such thing as the ideal development setting. All of these APIs are not yet fully implemented and equally aligned with the specs in all evergreen browsers. You need experience to avoid the pitfalls.
As a reference, there is a good compilation of [Service-Worker-based APIs statuses] (https://jakearchibald.github.io/isserviceworkerready/) by Jake Archibald. Additionally, you can find here a recent review of [testes on iOS and Android] (https://medium.com/@firt/progressive-web-apps-on-ios-are-here-d00430dee3a7) and a discussion of issues to overcome.
Browsers are poised to take their share on mobile home screens.
If you have further questions regarding the PWA development, reach out to the K&C team as right now we’re actively working in this field