Analysing and Optimising TWA APK and AAB File Sizes

When publishing an Android application to the Google Play Store, download size is a critical factor influencing user acquisition and conversion rates. Large applications require more time to download, consume data caps, and are more likely to be uninstalled when storage runs low on budget devices. Developers moving from native frameworks or heavy hybrids to Trusted Web Activities often notice a massive difference: TWA packages are incredibly small, frequently weighing under 3 megabytes.

This guide explains the architectural reasons behind the minimal footprint of TWA-based Android apps, breaks down what inside a TWA bundle actually consumes space, and provides clear steps to keep your APK and AAB files as slim as possible.

Why TWA Apps Are Extremely Lightweight

To understand why a Trusted Web Activity app is so small, it is helpful to contrast its architecture with alternative mobile application frameworks. Cross-platform environments like React Native or Flutter, and standard hybrid wrappers such as Apache Cordova or Capacitor, must bundle significant dependencies directly inside the final APK or AAB file.

React Native packages must include the Hermes or V8 JavaScript execution engine, along with native bridge libraries. Flutter applications compile down to native binary code and bundle their own rendering engine (Skia or Impeller). Even traditional WebView wrappers often compile additional custom native bridging layers to manage operations.

In contrast, a Trusted Web Activity acts as an architectural thin client. Instead of bundling a browser rendering engine, it leverages the pre-installed system browser (typically Google Chrome) already present on the Android device. The TWA wrapper is simply a set of native instructions and configurations that tells Android to launch the browser in a standalone, chromeless window, securely bound to your domain name via Digital Asset Links.

The Anatomy of a TWA Android App Bundle

Because the web application itself is hosted on your web server and updated on the fly, the compiled Android App Bundle (AAB) or Android Package (APK) contains only the scaffolding required by the Android operating system. A typical TWA package contains the following primary elements:

• Android Manifest (AndroidManifest.xml): The configuration file defining the package name, app permissions, supported features, intent filters, and references to the digital asset links association.
• Java/Kotlin Classes: A minimal set of native instructions provided by the Android browser-helper library. This code initialises the custom tab and manages system integration features like splash screens or push notification setups.
• Res folders (Android Resources): Storage for static app assets required during initial boot, such as the application launcher icons, XML configurations, and the splash screen drawables.
• Asset Links Config: A metadata entry pointing to your assetlinks.json file on your secure web domain.

Because no HTML, CSS, JavaScript, or media files from your actual web application are packed inside the binary, the starting footprint is exceptionally small. Any web assets are retrieved dynamically and cached by the web browser or your PWA service worker after the initial launch.

Comparing Mobile Architecture Footprints

The table below provides a typical comparison of application sizes for a basic application across different development frameworks:

As illustrated, choosing a TWA provides a distinct advantage, especially in emerging markets where network speeds are variable and devices have limited storage capacities.

How to Optimise Your TWA Assets

While a default TWA generated using tools like PWAtoApp is already highly optimised, certain developer-added assets can inadvertently bloat the package. To maintain the absolute minimum file size, pay close attention to the local resources bundled within your native wrapper:

1. Optimise Launcher and System Icons

Your application requires launcher icons for various screen densities (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi). Developers often export uncompressed PNGs for these assets. Ensure all generated PNG icons are passed through an image optimiser. Better yet, where supported by your build pipeline, use Android Vector Drawables (XML) for system-level icons, which scale infinitely at a fraction of the file size of raster graphics.

2. Compress the Splash Screen Image

The splash screen is displayed briefly while the system browser loads your web application's initial viewport. Since this graphic must look crisp across large high-density screens, developers often use high-resolution images that can easily add several megabytes to the final build. Keep your splash screen design simple, preferably with a solid background color and a centered vector logo. If you must use a raster image, compress it thoroughly or export it as a WebP file within your native resource structure.

3. Avoid Embedding Local Web Files

Some hybrid approaches allow developers to bundle HTML, CSS, and JS files directly inside the Android assets folder for offline fallback. In a pure TWA implementation, this is generally unnecessary and discouraged. Instead, rely on a robust Service Worker setup. Your service worker can cache your entire web application shell locally upon the user’s first open. This keeps your Google Play download size minimal while still providing full offline functionality and fast subsequent load speeds.

By ensuring your local graphics are highly compressed and leaving the bulk of your application delivery to your web server, you can publish a fast, modern Android application that occupies minimal space on your users' devices.