TWA (Trusted Web Activities) at QuintoAndar
How we did it and how was our experience replacing a native application with a TWA on the Play Store
Important: This post is not a step by step of how to create a TWA, this can be found here. Instead, I’ll show you how to deal with the pitfalls we faced during development that are not mentioned in the documentation and how TWA is used in QuintoAndar.
Throughout 2017 QuintoAndar — a residential real estate rental platform born to simplify the lease process from start to finish — decided it was time to redesign its apps in order to deliver a more thought out flowed experience. To achieve this goal we decided it was time to onboard the PWA wave that had already given extraordinary results.
Since then, we developed more than 20 PWAs to meet the needs of tenants, renters, photographers, realtors and internal company tools.
While focusing our efforts to deliver PWAs we still kept our native Android on the Play Store. Since we still had (and have) users finding us on that media we kept delivering a few updates & bug fixes. We had our eyes on TWA and expected that, with it, we would deliver a experience as good as the native app.
For about two years we provided a awesome mobile & web experience and a outdated one on the native app. Then, on January 2019, Google announced the TWA — it meant we could finally provide the same experience of our web apps on the Play Store.
Understanding TWA…
The TWA (Trusted Web Activity) is a Google solution announced in 2019 that allows developers to create an Android app to act like a “shell” for your PWA. In other words, you can publish your Android app on the Play Store and, when users open it, it will run your PWA on Google Chrome (or another browser available).
TWA is fully supported by Chrome since its version 72. On this version or any newer, it has the following functionalities:
- No browser address bar;
- Deep link configuration;
- Access to notifications;
On other browsers or previous versions of Chrome, it will open as a Chrome Custom Tabs or as a normal site, according to the browser.
You should pay attention to the browser version of your users. At QuintoAndar, just a few weeks after the launch of Chrome 72, more than 90% of our users had already adopted the new version.
Seems cool, but how to create a TWA?
Creating a TWA is very simple and does not demand any lines of code. The step-by-step can be seen here on Google’s official documentation:
On this link you can see how to create your TWA in a very simple way, so I won’t cover here. Instead, I will show how to handle unmentioned pitfalls we faced during development.
How to track access and events of a TWA and a PWA without mixing them?
Users behave different according to platform. For this and other reasons, you might want to distinguish PWA’s and TWA’s events. Besides, you might want a slightly different behavior for the TWA, such as an onboarding flow. There is no native solution for that, but it can be accomplished in a variety of ways. The following one we chose at QuintoAndar:
When the PWA is accessed by a TWA, the referrer attribute contains the app’s package name. Thus, you only have to check on the PWA if referrer is the TWA app’s package name. Code example:
TWA asks users on which browser it should open
Imagine this situation: the user has no default browser selected, so every time he tries to open a link on Android, he sees a S.O. prompt, something like:
Now, imagine this same user goes to the Play Store and downloads your app. As soon as the download ends, he tries to open the app and guess what shows up? Exactly, that same box. Seeing this when opening an app that has just been downloaded from the Play Store is not the best experience, right?
But it can get even worse… It is possible to put deep link on your TWA, which means you can configure your TWA to be one of the options when opening links of your domain (you can see more details on how to do this on this Android developers tutorial). Therefore, when trying to open the TWA for the first time, your TWA itself you be there as one of the options to open your TWA. Worse, if the TWA is selected to open itself, it will crash and will never open.
To solve this issue, we must make sure your TWA knows how to act in case your user does not have a default browser selected, so let’s do it:
Change android:name of your activity on AndroidManifest.xml to a Java class you will create. Only one line of the XML must be changed, which replaces Google’s default LauncherActivity solution with yours, giving you freedom to customize it. Your AndroidManifest must be similar to this after the change:
You must create your .java file called LauncherActivity based on Google’s code. Its latest version can be found here:
Using Google’s code as the starting point for your own solution, you just have to use your Java knowledge and handle the problem your own way. The solution we have used is shown on the code here and does the following:
First, we check if the user has Chrome version 72 or newer. If so, we open the TWA on it. If he doesn’t, we check if any browser that supports Chrome Custom Tabs is available. If there is, the TWA is opened on it. If there is not, we open the site on whatever browser is available to the user (every single Android device comes with at least one browser installed, which cannot be uninstalled).
Now we don’t have to worry if the user has a default browser or not. He won’t have to select a browser to open that intent, as the TWA will handle this for him.
I am convinced, I will create my TWA and replace the current app I have on the Play Store. Will I lose my reviews and users from the store?
No! You just have to create your TWA with the same package name and sign it with the same key of your current app available on the store. Therefore, the publishing process will be exactly the same as a regular update of your current app.
Conclusion
The TWA revealed itself as a great option for those who, just like us at QuintoAndar, want to focus on PWA development instead of a native app, without losing the advantage of being on the Play Store.
Naturally, there are some challenges. Perhaps the biggest of them is optimizing the PWA’s performance so it can be as fast as a native app using Android system’s own components.
Also some components or pages fit better on the web than on an app. A home page, for instance, fits a lot better on the web. Therefore design optimizations are required in order to improve the experience.
At last the offline behavior, available to PWAs through the service worker, is essential to make the TWA’s experience look native.
These optimizations (and more) are necessary to deliver the users the experience they expect when purchasing/downloading from app stores. At QuintoAndar we are commit to provide users an increasingly better experience when using our platform.
About me
Computer science student at Federal University of ABC and a software engineering intern in the organic growth team. I was the main responsible on the engineering side for the first TWA developed at QuintoAndar.
Join Us
If you like challenges and you want to work in a startup that is redesigning the entire experience of the rental process. Using technology and design as the core components. Look at our job opportunities on our career page, we’re always looking for talented and eager to learn people.
Thanks to Fabio Hiroki, José Henrique Leite and Phillipe Moreira.
