What are instant apps

Usually instant apps are small parts of bigger apps. It is like a demo mode for the whole application, so in case of games it can be just the tutorial or a few levels. For a non game app it can be just one flow out of many to give the users an impression what they can expect from the app. A good example of instant apps are games like Clash Royal. If the search is done in Chrome or via Google Now then there will be an entry where a Try now button is visible.

There are various ways to provide an Instant App to users. Those ways are categorized in two experiences, basic and enhanced. The basic experience provides instant apps via the Try Now button or web banners. Enhanced experience allows instant apps to be provided via Search, ads, messages and many more. To get an overview over the possibilities read here for more information. It depends on the type of the app and its size which experiences are supported.

For non game apps there are 3 limits:

• >10MB → App size has to be reduced
• >4MB and <10MB → Try now button in the play store and web banners are supported (basic experience)
• <4MB → Search, ads, messages etc are supported (enhanced experience)

For game apps, there are just 2 limits:

• >10MB → App size has to be reduced
• <10MB → Search, ads, messages etc are supported (enhanced experience)

What is actually necessary to provide an instant app?

New project

If the project is started from scratch, there is a checkbox during the configuration that asks if the app should support instant apps. If it’s selected → Voilà, it is almost done!

Existing project

If there is already a project which contains just a single module and it’s below 10MB the change is simple.

<dist:module dist:instant="true" />

This snippet has to be added within the Manifest Tag → Done 🙂

For apps that are bigger than 10MB the effort to provide instant apps is higher. So be prepared to get your hands dirty.

Reduce app size below 10MB

If the app contains just one flow which should be provided as an instant app, it is necessary to investigate what causes that the app is larger than 10MB. There are a couple of possibilities:

• Size of images
• Unused languages
• Unused resources
• Unused libraries

Size of Images

The best approach is to use vector drawables. Vector drawables have many advantages, unfortunately changes in the app’s code are necessary to support vector drawables. Check here how to use vector drawables in Android. Another approach is to use WebP files. It is possible to convert PNGs to WebP files easily. This can help to reduce the size of the app’s drawables significantly. See here how to convert a PNG to WebP. The big advantage of using WebP files is that no changes in the code base are necessary.

Unused languages

Define explicitly which languages should be supported so there are no unnecessary languages file bundled. Read here how remove unused alternative resources.

Unused resources

While applications are growing over time, it easily happens that there is a bunch of unused resources, such as images, layouts, assets, files and so on. Luckily, with Lint it is possible to find the forgotten resources from better times. 😉 To run the Linter, execute the following steps:

1. Select Analyze in the menu
2. Select Run Inspection by Name
3. Type unused resources

Unused libraries

Over the time libraries are added, replaced and removed. It easily happens that dependencies that are not used anymore are not removed and blowing up the app size. So a quick win can be to simply check what dependencies are currently added in the build.config. The get an overview about everything inside the apk Android Studio provides a nice tool which can help to identify large libraries, APK Analyzer.

APK Analyzer

There are three different approaches to access the Analyzer.

1. Drag an APK into an editor window of Android Studio
2. In Android Studio, switch to the Project perspective, and select in the build/output/apks the APK
3. Select Build in the menu bar and then Analyze APK and select the APK.

The APK Analyzer will show the sizes of all dependencies, recourses, code etc. So it will be possible to figure out where the oversize of the APK comes from.

Modularization

Modularization has the biggest impact on the binary size as well as the code structure of the project. Besides the binary size modularization has some other advantages as well:

• Scalability
• Maintainability
• Improve build times

Scalability

Let’s imagine the project started with a small scope and maybe in the beginning just a single developer is involved. It often happens that those projects are growing, more developers start working on it. This can cause a lot of troubles, conflicts etc. With modularization it is easily possible that more developers working on the same project but in different modules. Developers will have ownerships over “their” modules. This approach allows development to be done faster, less error prone and better maintainable. In comparison to a monolithic app where the amount of coordination work and conflicts will increase drastically when the project grows.

Maintainability

When the project is split up into modules, there will be a module for each feature in the app, and most likely some common modules, like base, shared resources or in some cases even a shared database. This decoupling will make the search where a problem is coming from much easier and most likely also faster. The decoupling of modules has also the nice effect that a development on feature/module will not effect anything else in the project.

Improve build times

With a growing project that contains more and more functionalities in a monolithic project the build time will also increase dramatically. The time invested in modularizing a project will pay off in the long run, because Gradle is optimized for projects that are organized in modules. Gradle is able to build decoupled modules in parallel and builds only those which got changed since the last build.

Modularize an existing app

Modularization means splitting the monolithic application into smaller parts. It’s perfectly described in the official Google documentation. To sum it up in simple words, the current exiting module has to become the base module. Then feature modules have to be added. When adding a new module it is necessary to decide what this module should do. If it should be a feature that is provided as an instant app, then a Instant Dynamic Feature has to be chosen because then the new added module is already correctly configured. Every feature that is provided as an instant app needs an activity. This activity needs intent filters to define the entry point.

viesure and Instant apps

After all this theory let’s move on to the possibilities for us at viesure. Recently we launched our first app which had the goal of a radically improved experience for all parties involved in the effectuation of health insurance policies using the means of digitalisation. To do so, we create an extensible app which serves as a fundament of a fully digitalised interaction with our customers. Using automation and artificial intelligence we aim at reducing the processing time of standard submissions to minutes until payment. Applying the possibilities of native apps and well-thought leading UX design we aim at improving the quality of input data and increasing customer satisfaction.

Let’s imagine that a customer doesn’t know that this app even exists but searches for a way to hand in a doctors invoice via the search on his/her smartphone. Then the user is shown a link which will trigger our instant app. Our user will have a native experience immediately without the cumbersome way through the PlayStore.

Drawbacks of using Instant apps

Last but not least let’s have look about some downsides of using instant apps.

Makes app less sticky

This will be an issue especially for the marketing department. Although the user has access to a native experience the app is gone from his device as soon as the app is closed. Therefore an important communication channel to the user is lost, it is necessary to evaluate which features are provided so that users are convinced to install the full app.

Limited file size

For some features it will be really difficult to provide a good experience to the user with such a limitation. There will be cases where users will experience less comfort in comparison to the full app. A simple example is a feature that would provide some kind of image analyzing. It is easily possible that such features need more space than 10MB. In this case that functionality has to be removed from the instant app apk. This can lead to dissatisfied users who are not convinced to install the full app.

Conclusion

The steps that have to be taken to provide instant apps are in any case useful. It will make the project more structured, maintainable and scalable which will make growing much easier. Whether or not an instant app will be provided depends on various things and has to be decided carefully.