The hype of Tiny applied to Android applications with TWA
Introduction
At Peaksys, we develop digital solutions for Cdiscount, a major e-commerce company. To successfully serve more than 10 million clients, manage commercial events, adapt to shifting customer trends and incorporate changes in legislation we have to stay flexible. A key problem we face is the divergence of our many frontend applications: each one is based on different technology, making it difficult to keep their design and features coherent.
Here we explain how we factored two of these supports by migrating our React Native Android application to an app based on our mobile website using Trusted Web Activity (aka TWA).
To summarise our solution in a few words: a TWA app consisting of a full-screen browser tab displaying our mobile website, wrapped into a small native Android application available on the Playstore. It fits almost all our use cases and we have even gained some features that were not available on the original React Native app. Bonus: we are still able to incorporate features specific to native APIs.
What have we gained by doing that?
- We have divided our APK size by 6
- We have 10 times fewer crashes than before
- We have kept all business figures constant
- We can bring all Cdiscount web features to the app
- We have removed thousands of lines of code (i.e., less maintenance)
- We have reduced our time to market
A PWA published on the Playstore
Since the first iPhone in 2007 and the first Android version in 2008, embedded applications lead the game on mobile devices and were the only way to use specific native features, publish the app in stores and provide a decent UX experience. By using only JavaScript you were limited: no localization, sensors, or notifications… But JavaScript is a big boy now: it’s 25 years old and it can display an offline app, talk in HTTP3 with your server or even deal with cryptos.
Today, Web APIs allow us to handle most of our common use cases without requiring native code anymore. We can create smooth UX with web technologies. With Progressive Web Application (PWA), users can easily install shortcuts to their favorite websites and launch them in full-screen. However, it lacks a bridge with native APIs and the possibility to ship these web apps to the stores. That’s why Google came up with a new approach: Trusted Web Activities.
Trusted Web Activities is an API from Chrome for Android and its first version appeared in February 2019 with Chrome 72. Since this release, many other browsers have followed the guideline and are now compatible.
Good news: since it’s an API from the web browser, it does not rely on an Android version and has been compatible since Android 4.4.
A word about Custom Tabs
To understand a TWA, it is important to be aware of another Android web browser feature: Custom Tabs. It’s a browser tab opened by an external app and integrated into it. To keep it simple: the user believes they’re still in the application but in fact, they’re using their web browser. The behavior is close to a WebView, but the performance is better and it’s more secure. You have probably already used them by clicking on a link in an email, for example.
Getting back to our subject: TWA. In fact it is a Custom Tab in full screen, meaning the user feels as if they’re browsing a native application. Note that there is a small security process between the website and the application to be sure they are both owned by the same person. You have to expose a json file containing your Android application signature on each domain that you want to display in full-screen. If not, your application will simply display a custom tab with the URL bar visible.
So what exactly is a TWA? An App or a Website?
TWA is an Android web browser API callable from other apps, so you still need a native application to use it. Unlike PWAs it requires to be packaged, as well as signed and deployed to the Playstore.
This wrapper can be very small and we will see that you even have tools that let you generate these small APKs from your PWA manifest file.
It has many advantages in comparison to a classic native application:
- Easier to ship (less native code)
- Smaller APK
- Less battery consumption
- Session shared between browser and application
And since your content is now based on web browser technology:
- All web performance metrics provided by Google
- All the latest browser security patches (unlike WebViews)
- The flexibility of a web release: fast and under YOUR control.
- Deploy when you want and with the frequency you need.
- Enhanced security: thin clients are safer (less code means less vulnerabilities, easier to maintain and monitor)
At Peaksys, the technology subsidiary of Cdiscount, we decided to make a hybrid application for our customers: driven by the website but with certain native features callable from the web page or when the app is booting up. We now have all features and design evolutions from our website available, but we are still able to respond to our business needs, such as “can we have an AR viewer to see our products in 3D?” or “we need to integrate an Android native authentication module”, no problem with a hybrid app.
Why make a hybrid app?
We call it a hybrid app because it’s a native Android app, with embedded SDK, config and some native screens but 95% of the content is served through the website via the TWA.
Why should you keep control of the native part of your application?
To improve default TWA experience
By default, AndroidBrowserHelper will try to find all TWA-compatible browsers installed on the device. If the preferred browser of the user is on this list, it will use it.
We have found that browser compatibility with the TWA API varies widely: sometimes it displays a URL bar, it does not delegate permissions or fails with a multi-domain website… After many attempts, we came to the following conclusion: there is no better TWA user experience other than that using Chrome.
These issues are sometimes acceptable on old devices because the proportion of users impacted is limited and users does not stay locked. However, we still enhanced AndroidBrowserHelper behavior by forcing Chrome when installed on the user’s device.
To keep existing native features and SDKs
We don’t want to leave Android completely behind: it is impossible to say you will never need native APIs. We must keep a foothold here and maintain this flexibility.
With this approach, we have 2 entry points in our code to trigger native features:
Boot sequence
To launch the application, the user starts an Android Activity and while it displays a splash screen we can start some services in the background before handing it over to TWA.
Deep links
In the case of an existing application, you could ask yourself which dependency you would break by using a TWA app. One of them is deep links: you could have emails, notifications, QR codes or even other applications based on these existing deep links. With the native part of your app, you can easily catch and map these deeplinks to a standard web URL that you will be able to open with TWA.
Do not forget that in TWA your Android application does not have control, the web browser does. So it is a good strategy to have the experience driven by the website since it owns the user session, cookies, consents, etc…
To have a cross-platform project
Keeping a native part of your project gives you the opportunity to use TWA API through a cross-platform technology. Nothing prevents you from using React Native or Flutter to make a hybrid TWA application. But TWA is only an Android browser API so you will have to find solutions based on WebViews to handle the iOS devices.
The challenge of the migration
We already have an Android app with many active users and good visibility on the Playstore. The main challenge is to keep the transition transparent for them.
So the plan was to migrate to a TWA-based app by overriding the existing app and shipping the TWA one using a standard update.
You will encounter a number of issues when you want to “override” your app with a new one that are worth bearing in mind:
- Keeping the same application Id and signing the app with the same key
- Remaining compatible with your existing deep links
- Remaining compatible with existing UserPreferences or other data that could still be stored on the user device
- Losing your existing opt-ins for your push notifications. To address this particular issue at Peaksys we embedded the native SDK in addition to the web one. Users migrate from one to the other at the first launch so they don’t miss any notifications.
- Don’t forget to draw up a rollback plan
More specifically for TWA:
- When you have many environments for your website, prepare a way to display them (through a dev menu)
- Don’t forget to handle customer consent relating to GDPR, CCPA, and others for both sides: native & web
Where should I start?
Once you checked that your website is a good PWA, you can move on and try to build a TWA-based app shipped onto the Playstore.
There are a number of ways to create a TWA-based application:
- Generate it from PWABuilder.com
This website will show you how to improve your lighthouse score and publish your web app to the store (as a TWA app using BubbleWrap).
https://www.pwabuilder.com/ - Generate it using a CLI
BubbleWrap is a CLI that helps you to generate a small TWA wrapper project from your PWA manifest. It will create an Android project skeleton for you.
It requires a few more dev skills but it’s the best way to start a TWA-based application. It takes only a few minutes and gives you the opportunity to add native features later.
https://github.com/GoogleChromeLabs/bubblewrap/tree/main/packages/cli - Directly import AndroidBrowserHelper
It’s the Google library used to generate the Intent that opens CustomTabs, so you can use it directly in your application.
That what we used at Peaksys to keep control of the boot sequence and launch TWA with custom options.
https://github.com/GoogleChrome/android-browser-helper
You can always do better
We did it! We shipped a TWA application in production and we are very proud of that. Business figures are good, so too our user reviews.
It was an awesome journey and it’s not over yet. We always try to improve our website experience, and strive to go one step further now this experience is shared with our Android app.
Another aspect we are working on is the feel of interaction. Our website must look more like an app and less like a webpage. We have to look closely at every interaction, every button or link and add a smooth transition or visual feedback on each one. Good news on this point: Google have announced a new Web Metric: “Interaction to Next Paint”. In short, the metric will highlight the responsiveness of your user interface.
We have already started work on it because we think that it’s a valuable metric for our TWA app and could also have a positive impact on our SEO in the future.
What you should remember
If you have to remember something, it’s simply this: TWA is a web-browser API that allows you to launch a tab in full-screen. It’s not a WebView, it’s not a PWA, it is safe and it is only available on Android for now.
