Android Instant Apps: where the first launch breaks
The drop-off happens not inside the app, but before it. The user clicks a link, lands in the store and sees a loading screen — and leaves without waiting for the first screen.
The greater the size of the downloaded package and the more steps between the link and a working interface, the higher this loss, and it is measured in multiples, not single-digit percentages.
Instant launch is not about speeding up loading, but about eliminating it. The app is assembled from modules: the entry point and shared resources remain in the base one, while the rest is pulled in as the scenario progresses.
The user gets the first screen immediately after the transition, and installation of the full version happens in the background — and is often no longer needed if the task is solved in a single section.
Modular assembly rebuilds the architecture entirely, and this is where its own bottlenecks appear. Module boundaries have to be drawn along user scenarios, not layers, and shared dependencies must be moved into a separate layer, otherwise their size is duplicated in every module.
Each new section is a rule for appearing in a specific route, an entry in the build configuration, and a check that the transition does not pull half the app along with it.
An error in these boundaries manifests quietly: the app works, but first launch degrades again, and drop-off at the installation stage returns.
This can only be caught on real devices and in real networks — synthetic runs on a fast connection give a smooth picture where real users leave.
That is why below we break down how to mark up modules and which checks keep the size of the downloaded package under control after every release.
Measurable effect: launch speed, size, drop-offs
Moving to modular delivery changes not architecture for architecture's sake, but three numbers that show the result: time to first screen, share of the downloaded package, and conversion from the link.
While the app is monolithic, following an external link costs the user a full installation — on a weak connection that means 10-15 seconds of waiting and a noticeable share of drop-offs that happen before the first screen.
After splitting into a base module and feature modules, the client receives only what is needed for the current scenario.
The share of the downloaded package falls to 15-25% of the full volume, time to first screen to 2-4 seconds, and conversion from the link grows: the user sees the needed screen before deciding whether they need the whole app.
Google Play serves modules on demand, so the depth of the scenario is limited only by what you have moved into a separate module.
A separate effect is a class of drop-offs that disappears entirely: interrupted installation, lack of space, incompatible version, rejected update.
Updating without full installation works at the module level: a fix in one scenario is pulled in separately and does not force reinstallation of the entire app.
We take metrics before and after: median and 90th percentile of time to first screen, share of the downloaded package, share of sessions without installation, and conversion from the link to the target action.
Launch options: Instant Apps, installation, link
The delivery mode determines what the user gets in the first seconds: use without installation, a link transition in the browser, or a full installation from the store.
The choice comes down to one thing — which part of the scenario must work immediately, and which can wait until the next visit.
Platform limitations set boundaries more rigidly than interface wishes: instant launch is limited by module size and the set of available system capabilities. Below are four schemes among which a choice is actually made at the start.
| Option | When it fits | Limitations |
|---|---|---|
| Instant launch (Instant Apps) | Scenario with 1–2 screens: payment, order, promo | Limit on module size, reduced set of permissions |
| Link transition in the browser | Reach from search and messengers, content without complex logic | No access to some device capabilities, weaker retention |
| Full installation | Long cycle, offline mode, background work | Barrier at entry: some users leave during download and permission prompts |
| Hybrid scenario | First contact instantly, then a full app | Requires modular architecture and state transfer between modules |
In practice, the hybrid scheme more often wins: we serve the first screen with an instant module, and offer installation at the moment when the user has already gotten the result.
Then the link transition does not lose state — the cart, authorization, and progress are transferred to the installed app instead of starting over.
Work sequence: audit, module splitting, verification
Implementing instant launch is not 'making another build', but rebuilding the project for a modular architecture.
We start with an audit: without a map of screens, entry points, and external dependencies, it is impossible to understand what even makes sense to move into launch without installation.
Then we follow a fixed sequence — from code slicing to testing on real devices and handover to the team.
- App audit. We assemble a map of screens and user paths, a list of external dependencies, build size, and cold start time. The output is a list of scenarios that genuinely benefit from instant launch.
- Defining scenario boundaries. We decide which paths become separate modules and what remains in the shared core. We keep the core minimal: everything that goes into instant launch directly affects time to first screen.
- Splitting into modules. We move code into scenario modules, and shared resources and network work into the core. After each step, we verify that the startup part has not bloated and the module does not pull extra dependencies.
- Dependency scheme and build rules. We fix the direction of links: scenarios depend on the core, but not vice versa. We move versions into a single catalog, and automatically check the ban on reverse dependencies at build time — otherwise the architecture drifts apart within a couple of releases.
- Testing on devices. We run scenarios on real devices from different manufacturers, including weak network and cold start. Separately, updating an already installed app and rolling back to a previous version.
- Handover to the team. We hand over module documentation, build rules, the procedure for adding a new scenario and release. After that, the client's team manages the modules independently.
What remains with you: schemes, modules, regulations
We hand over the project not 'as is', but in a state in which your team releases updates without us.
The package describes the modular architecture of Android Instant Apps: which part of the code goes into instant launch, which remains in the installed app, and where the boundaries between modules lie.
- Module map — dependency graph, entry points, owner, and boundaries of each module; separately marked is what goes into the instant variant and what is available only after installation.
- Configured builds — profiles for the instant and full variant with shared resources and interaction contracts; a check on the build pipeline does not allow the downloaded package size to grow above a set threshold.
- Release regulations — the order of steps from merging changes to publication, mandatory automated tests, who confirms the release, and at what moment rollback to a previous version is enabled.
- Update policy — frequency, channels (closed testing, staged rollout, full release), and criteria by which the rollout stops automatically.
- Team instructions — how to deploy the environment, build and test the instant variant on a device, add a new module, and where to view crash logs.
- Transition scheme — which links open the instant experience, at what moment the user moves to the installed app, and what data is transferred.
- Metric set and monitoring dashboard — events that show the share of installations after instant launch and the places where users leave.
Case study: build size three times smaller, launch failures gone
The project is an app for a retail chain: catalog, loyalty card, order checkout. A monolith of three dozen modules meant that a fix in the catalog pulled a full rebuild and re-download of the entire package.
We split the product into independently buildable modules and raised a lightweight entry point on Android Instant Apps. The implementation case took seven weeks from task analysis to a working release.
What it was like
The user downloaded 28 MB and waited about four seconds for the first catalog screen on an average device. On cold start, 9% of launches were lost: the app did not manage to render the list or crashed during dependency initialization. Each such failure meant a lost order, and the person did not come back again.
The entry point was assembled from a single catalog module: via the link, a person gets the product list without installation, and order checkout is loaded by a separate module.
Shared libraries were moved to the base layer, links between modules were described explicitly, and the build was made incremental — only the changed part is rebuilt.
Result
The size of the build that the user downloads fell from 28 to 9 MB, the first screen opens in about one and a half seconds, and the share of failed launches is below 3%. Total build time dropped from 14 to 5 minutes, and rollback to the previous release takes one step. The next stage is the loyalty card on the same modular circuit.
What to do if the app is already built as a monolith?
A monolith is not rewritten entirely — during rewriting, releases stop, and regressions accumulate in one shared package.
The working path is different: the entry point is made a separate module within the same codebase, assembled into Android App Bundle, and released independently, while the main package continues to be released on its own schedule.
The first parts to be moved out are stateless ones: catalog, search, product card, order status view. The selection criterion is a minimum of links to internal services and no dependency on local storage: a lightweight module has no right to hold persistent data.
Such code moves almost without edits, because it is no longer tied to global state and works from a network response.
Version compatibility rests on three things: the package name and signature remain the same, so the update arrives on already installed devices without reinstallation; links between modules are described by contracts, not direct calls; the core and the extracted module are versioned separately, so rollback affects only one part.
The main migration risks are hidden links through shared state, resource duplication, and increased build time.
They are removed before the first edits: a dependency graph is built, modules are forbidden from accessing each other directly, and each module's build is checked separately on the build pipeline. Then moving out the next piece becomes a planned task, not a product halt.
Technical doubts and platform limitations
Platform limitations show up not in a demo, but in live traffic: some devices do not support instant launch, and some limit background installation.
Before starting, we fix a compatibility matrix — which OS versions and manufacturer shells we cover, and what we show to the rest: the same screen, but via a regular installation from the store.
The second layer is access to features, analytics, and updates. The instant module gets a reduced set of permissions, so we test the camera, payment, and geolocation separately on each scenario.
We mark the transition to the installed app with a single event: without this, the funnel breaks in the middle and the share of those who reach installation is calculated incorrectly.
Which devices do not support instant launch?
Coverage depends on the OS version and the set of manufacturer services.
We calculate the exact share from logs before release, and for the remaining users we leave the same functional path — an installation link with context preservation, so the person does not start the scenario over.
How is analytics for transitions between the module and the app calculated?
Events from the instant module and the installed app go in different streams, so without a single session identifier they do not match up.
We mark the entry, key steps, and installation with a common attribute — then it is visible on which screen the user is lost and what exactly should be simplified.
What about data security during instant launch?
The module runs in an isolated environment and does not store access keys between launches. We do not cache critical data, we verify authorization on every entry, and exchange happens only over a secure channel — storage requirements here are stricter than in a regular app.
How often can updates be released?
The instant module updates together with the store release and is picked up on the next launch, without any action from the user.
The only limitation is module size: the heavier it is, the higher the share of drop-offs during loading, so we move large sections into the installed part.
If you already have an app and are thinking about instant launch as an additional entry point, describe the current scenario — we will come back with an estimate and a plan by stages.Let's discuss your task: what is needed to start work
For us to come back with a timeline estimate rather than general words, we need a minimum of input data about the current state of the project and the boundaries of the task. Describe it in free form: the purpose of the app, what already works, and what is getting in the way.
We will ask clarifying questions ourselves — at this stage, context is more important than a formal requirements description.
- A link to the repository or project archive: the code shows the state of modules, dependencies, and accumulated debt.
- A scheme of modules and their boundaries — what has already been separated, what is connected directly, and where logic is duplicated between the main app and the Android Instant Apps scenario.
- A description of the scenario that must launch without installation: what the user does in the first seconds and what result is considered success.
- Data about the release cycle: how often versions are released, how long the build takes, and who checks changes before release.
- Constraints: minimum OS version, list of target devices, requirements for access and storage of personal data.
- A person responsible on your side — someone who confirms priorities and accepts intermediate results.
- Expectations for timelines and points where intermediate acceptance is needed.
After the review, we will come back with a timeline estimate, a scheme of work by modules, an implementation plan, and team composition — with roles and workload by stages.
If some data is missing, it does not block the start: we will record assumptions and refine them along the way.