Reducing Mobile App Bundle Size and Cold-Start Time

Every second between a tap and a usable first screen is friction for your field technicians and customers. Android's launch-time documentation defines cold start as the path from process creation to first frame, the window a bloated binary stretches.

Bundle size is the total code, assets, and libraries an app loads before it can run, and it is the lever you control most directly over cold-start time. Across 10 to 150 locations, that delay repeats on every device and every shift, so it becomes an operations cost. The sections below cover measurement, deferral, and regression control.

What You'll Learn

• The difference between bundle size, install size, and cold-start time, and which one each user actually feels
• How to set a launch baseline on iOS and Android before changing any code
• Which dependency, asset, and initialization habits add the most weight and delay
• How native and cross-platform stacks change the levers you can pull
• How to put bundle and launch budgets into your release process so regressions get caught early

What Bundle Size and Cold Start Time Actually Measure

Teams often use "app size" to mean three different things. Each one affects a different part of the user experience, so keep them separate.

• Download size: the compressed package a user pulls from the app store or network. Shoppers see this number before they install.
• Install size: the storage the app occupies on the device after unpacking. It includes code, images, fonts, and cached assets.
• Cold-start time: the time from tapping the icon to a usable first screen, when the app has no warm process in memory.

Bundle size is the code and assets packaged into the build. It feeds download size, and it is the number engineers usually cut first. Cutting it helps, but it does not control everything the user feels.

Which Metric Drives Abandonment

Download size shapes whether someone installs at all. A user on a slow cellular connection feels every extra megabyte before the first tap. Install size matters less to that decision, but a full phone can block the install outright.

Cold-start time shapes whether the user stays. It sets the wait between tapping the icon and seeing something useful. That wait happens on every session, not just once.

A simple way to frame this in a planning meeting:

1. Download size affects the install decision.
2. Install size affects whether the install completes on older or full devices.
3. Cold-start time affects whether the first session feels worth continuing.

Why a Small Download Can Still Launch Slowly

A small download does not guarantee a fast launch. The package is compressed, but the app must unpack, verify, and load code into memory before it runs. Work that happens at launch, not at download, sets the cold-start clock.

Common causes include:

• Many modules loaded before the first screen renders
• Network calls for config or feature flags that block startup
• Heavy initialization on the main thread
• Third-party SDKs that each start at launch, whether or not the user needs them
• Local databases that migrate or index on first open

Consider a hypothetical 40-location service business whose field app ships at 25 MB. If the app then fetches four config endpoints and starts six analytics SDKs before drawing the home screen, the user waits on network and setup work. The download looks small, but the launch still feels slow.

This gap matters for multi-location operators. A field technician may open the app many times per shift, so a few extra seconds per launch add up across every crew and every location. Measure cold start on mid-range devices, not only on the latest flagship phone your developers carry.

Key Insight: Download size decides whether a user installs, but cold-start time decides whether they come back. Measure both on real mid-range devices, because a small package can still hide a slow launch.

How to Measure Mobile App Launch Performance

Agree on definitions before you time anything. A cold start happens when the operating system builds the app process from nothing. A warm start happens when the process still sits in memory and the app only rebuilds its screen. A hot start happens when the app returns from the background with its state intact.

Track each type as a separate metric. Averaging them together hides the number that matters most, which is the cold start a new or returning user sees.

Set Fixed Start and End Timestamps

Pick one start point and one end point. Keep them the same for every test run, or your numbers will not compare over time.

On iOS:

1. Start at the process launch event, captured with Xcode's App Launch instrument or an XCTest launch measurement.
2. End at the first frame the user can actually tap, not the splash screen.

On Android:

1. Start at process creation, which the system records when the app launches.
2. End when the first activity reports it is fully drawn. Android's Macrobenchmark library reports both an initial display time and a full display time, and the full display time is the better baseline.

Time to first interactive screen is the point where the first useful control responds to a tap. Fire a custom signal from that control so your timer stops at the right moment.

Choose Device Tiers to Test

Test on at least three device tiers. Each tier answers a different business question.

• Low tier: an older phone with 3 GB of RAM or less. This shows the worst case.
• Mid tier: a phone two to three years old. This is the most useful tier for most fleets.
• High tier: the current flagship. This shows your best case.

For a multi-location business, the mid tier usually drives the decision. A hypothetical 60-location service company might issue the same mid-range Android phone to every technician. If the app is slow on that phone, the slowness hits every job.

Run the Baseline Correctly

1. Test release builds only. Debug builds run slower and will distort the baseline.
2. Force-quit the app before each cold start run, and discard the first run of each session.
3. Run at least 20 cold starts per device. Record the median and the 90th percentile, because the median alone hides slow outliers.
4. Measure warm and hot starts in separate runs.
5. Test once with a warm cache and once with a cold network connection.

Save each result with the build number, device model, OS version, and date. Without those fields, you cannot tell whether a change helped or whether the phone just changed.

Key Insight: A baseline is only useful if it is repeatable. Lock the start point, end point, device tiers, and build type before you measure, so every later change is compared against the same yardstick. If your fleet runs mid-range phones, your mobile app strategy should be judged on those devices first.

How to Reduce Mobile App Bundle Size

Start with what you ship. Most teams never measure their build contents, so they guess at what is heavy. Measure first, then fix the largest weights before the smaller ones.

Start with a dependency audit

A dependency audit lists every library in your build and the weight each one adds. Run your platform's bundle analyzer and sort the results by size. Look for three problems:

• Libraries that repeat a feature the platform already provides
• Two packages that do the same job, such as two date or networking libraries
• Packages imported once and never removed

Be strict here. One heavy charting or animation package can add more weight than a feature team's entire codebase. Remove it, or swap it for a smaller alternative.

Apply tree shaking

Tree shaking removes code your app never calls. It only works when libraries ship as modules and your build tool can see which exports you use. Import named functions, not whole namespaces. Wildcard imports keep everything in the bundle.

Confirm that production mode is on in your bundler. Teams sometimes ship debug-mode builds by mistake, and those skip most of this optimization.

Remove dead code

Dead code compiles but never runs. Retired screens, old feature flags, and abandoned experiments all count. Use a linter rule that flags unused exports, and pair it with a coverage report from your test suite.

Delete the code instead of commenting it out. Version control keeps the history if you ever need it back.

Compress images and convert formats

Images often make up the largest share of a mobile build. Use vector formats such as SVG for icons wherever the platform supports them. For photos, convert to modern formats such as WebP or HEIF, and resize each image to the largest size it actually displays at.

Consider a hypothetical 40-location service app that bundles 300 uncompressed PNG screens. Much of that weight never loads on first launch. Moving large images to on-demand download is often the fastest gain available.

Subset and compress fonts

Custom fonts add up quickly, especially when every weight and style ships as a separate file. Keep only the weights your screens use. Font subsetting trims each file to the character sets you need, such as Latin characters for a US-only app.

Strip unused localization and debug artifacts

Localization files grow with every language you add. Ship only the languages your markets use, or download language packs when a user needs them.

Debug symbols, test fixtures, sample data, and logging helpers belong outside release builds. Check your release configuration to confirm it strips them.

Priority order by typical weight savings

Work through these in order. Each step usually saves more than the one below it:

1. Images and media assets, typically the largest share of the build
2. Unused or duplicate third-party dependencies
3. Custom fonts and extra font weights
4. Dead code and unused exports
5. Unused localization files and debug artifacts

Multi-location businesses often run several app variants from one codebase. A single cleanup pass then carries across every location build. If you need help structuring that work, the right service covers native and cross-platform builds for multi-location operators.

Key Insight: Start with images and third-party dependencies, because they usually hold the most weight. Small code cleanups matter, but they rarely move the total as much as the first two steps.

Need help applying this to your business? Tell us about your project and we will scope it with you.

Native vs Cross-Platform: Bundle Size and Startup Tradeoffs

Your stack choice sets the floor for bundle size and cold-start time. Each option ships its own runtime, libraries, and startup path. Know what you start with before you tune anything.

What drives bundle size in each stack

Native apps use frameworks the operating system already provides. Most of their size comes from your own code, images, and asset catalogs. Swift and Kotlin also strip unused code at build time, which keeps the final package lean.

React Native ships a JavaScript engine and your app's JavaScript bundle. Hermes, the default engine in current releases, can compile that code to bytecode ahead of time. This cuts parse work at launch.

Flutter ships its own rendering engine inside every build. That engine adds a fixed block of code, even for a simple screen. In return, your screens look the same on iOS and Android.

Startup initialization cost

Cold start measures the time from tapping the icon to a usable first screen. Every SDK, analytics library, and feature flag runs work before that screen appears. The more you load at boot, the slower the launch.

• Native Swift and Kotlin: The OS loads compiled code directly. Startup is usually the fastest of the four options.
• React Native: The app starts the JavaScript engine, then loads and runs the bundle. Lazy loading helps.
• Flutter: The app starts the Dart runtime and rendering engine before drawing. Startup cost is fixed but predictable.

Consider a hypothetical 60-location field service brand with 300 technicians opening a dispatch app several times per shift. A two-second delay on each cold start adds up to hours of lost time across the workforce each month. That is why launch cost belongs in the buying decision, not only in the engineering backlog.

Comparison table

Optimization levers you control

Each stack gives you different controls. Pick the one your team can maintain.

1. Native: Use platform app thinning and modular delivery so each device downloads only what it needs.
2. React Native: Keep Hermes enabled, split rarely used screens into separate bundles, and remove unused packages.
3. Flutter: Defer large libraries until a user needs them, and audit each plugin for its size cost.

Cross-platform stacks trade some control for speed of delivery. Native stacks trade development speed for the leanest runtime. Teams that want a clear recommendation for their location count can get one through the right service for their app.

Key Insight: For most multi-location operators, the stack matters less than discipline about what loads at launch. Audit startup work every release, whatever stack you choose.

How to Improve App Cold Start Time on iOS and Android

Every SDK that starts at launch adds work before the first screen appears. Analytics, crash reporting, attribution, ad mediation, and feature flag tools often each run setup code on launch. Most of that work can wait.

Sort each SDK into one of three groups:

1. Needed before the first frame: crash reporting, so launch failures get caught.
2. Needed before the first network call: authentication and remote config, started just before that request.
3. Safe to defer: analytics batching, ad mediation, heatmaps, and secondary feature flags. Start these after the first screen is interactive.

Audit the list every release. SDKs tend to accumulate, and nobody removes them.

Move non-essential work off the main thread

The main thread draws the interface. Heavy work there blocks the first frame. Database migrations, image decoding, large JSON parsing, and cache warming all belong on background queues.

Profile before you change anything. Measure where launch time goes, then move the top three costs first. Guessing wastes engineering sprints.

Lazy load modules and screens

Load a screen only when a user navigates to it. Do not build the full view hierarchy, dependency graph, or router table at launch. An app with 40 screens should not instantiate all 40 when it opens.

Good candidates for lazy loading include:

• Onboarding flows, which users see once per install
• Settings and account screens
• Rarely used features such as reports or data exports
• Third-party SDK modules tied to a single feature

Render a lightweight first screen while data loads

Show a usable shell right away. Use a static layout with placeholders, cached content, or the last known state. Swap in live data when the network call returns.

For multi-location operators, cache the location list and each site's current hours or schedule on the device. A manager in a basement stockroom or a parking garage still sees a working screen. The user waits for fresh data, not for a blank page.

iOS launch sequence notes

On iOS, the system loads the app binary and its dynamic libraries before your code runs. Apple calls this the pre-main phase. Each dynamically linked framework adds load time, so remove unused libraries and merge where you can. Apple's guidance is in its documentation on reducing app launch time.

Keep the application launch callback thin. Defer setup until the scene becomes active. Use SwiftUI lazy containers or table and collection views that build rows on demand.

Android launch sequence notes

Android creates the Application class first, then the first Activity. Heavy work in Application.onCreate() delays everything that follows. Use the AndroidX App Startup library to initialize components in a defined order, and defer the rest.

Baseline profiles help too. They tell the runtime which startup code to compile ahead of time, which shortens cold starts on first install and after updates. A cold start, where the process is created from nothing, is the slowest launch type and the one users feel most.

If your internal team lacks time to profile both platforms, the right service can handle launch tuning end to end.

Key Insight: Cold start time is set by what runs before the first screen appears. Defer every SDK and task that the first screen does not need, then show a cached shell while live data loads.

Enterprise Mobile Apps: Faster Launches for Field and Internal Teams

Field technicians and store staff open the same app dozens of times a shift. A consumer might open a shopping app once a week. That difference changes what a slow launch costs.

Why Field and Store Teams Feel Launch Delays

Internal apps face pressure points that consumer apps rarely do:

• Shared or older devices that sit in vans, behind counters, or in storerooms, often with less memory.
• Weak connectivity in basements, rural job sites, and back rooms, where the app cannot fetch everything at startup.
• Frequent restarts after a scan, a photo, or a phone call, when the operating system closes the app.
• Queues of waiting customers or jobs that make every extra second visible to the worker.

Consider a hypothetical 40-location service group with 6 technicians per location. Each technician launches the app 25 times a day. That is 6,000 launches daily. If each launch wastes 4 extra seconds, the group loses about 6.7 hours of waiting every day.

Split the Bundle So the First Screen Loads First

Modular delivery means the app ships a small core and loads other features only when a user needs them. The goal is a fast path to the first useful screen.

1. Move rarely used screens such as reporting, settings, and admin tools into on-demand modules.
2. Lazy-load heavy libraries like camera processing, PDF generation, or maps until a user reaches those features.
3. Remove unused assets, including languages and image sizes that no location uses.
4. Defer non-critical SDKs, such as some analytics tools, until after the first screen renders.

Both major mobile platforms support this delivery. Android app bundles and iOS app thinning send each device only the code and resources it needs.

Use Over-the-Air Updates for the Non-Native Layer

Cross-platform apps built with React Native keep much of their logic in JavaScript. Teams can push fixes to that layer without a full store release. This only works when the native binary stays unchanged.

A practical setup includes these rules:

• Version native modules and keep their interfaces stable.
• Ship JavaScript and asset updates over the air when the native layer has not changed.
• Roll out by location or role, so one pilot group tests the update first.
• Keep a rollback path to the last known good bundle.

This matters most for field crews. A broken scheduling screen on a Monday morning cannot wait for a store review cycle.

What This Looks Like in Practice

We worked with Aedanrose on a multi-agent AI platform with 5 specialized agents built for restaurant operators. The engineering challenge was dividing one product into separate, well-defined parts that can each change without breaking the others. The same discipline applies to a field app. Separate the concerns, load what the user needs now, and update the parts that change most often. Teams that want this build can review the right service for their stack, or see the full Aedanrose results.

Key Insight: For multi-location field teams, every launch second repeats across hundreds of workers each day. Splitting the bundle and updating the JavaScript layer over the air shrinks both the install footprint and the time a technician spends waiting.

How to Set Bundle Size and Launch Time Budgets for Your App Team

Budgets turn "the app feels slow" into a number your team can test. Without a number, every release turns into a debate over opinions. With one, a build either passes or fails.

Set two numeric budgets

Start with two limits. Set them separately for iOS and Android, because each platform reports size and timing differently.

1. Install size budget: The download size shown in the app store. Many teams start near 50 MB for a mid-size app and tighten from there.
2. Time to first interactive screen (TTFI): The time from tap to a screen where the user can act. A common starting target is under 2 seconds on a mid-range device.

Record a baseline before you set anything. A budget set without a baseline is a guess. Measure on a device that is two or three years old, because many customers still carry one.

Enforce budgets in CI and release gates

A budget that lives in a slide deck gets ignored. Put it into the build pipeline.

• Fail the build if install size grows past a set amount, such as 2 MB, over the last release.
• Run a cold-launch test on a device farm and fail the build if TTFI exceeds the budget.
• Block the store submission, not just the code merge, until both checks pass.
• Log every exception with a reason and an expiry date.

Assign one named owner

Shared ownership means nobody owns the number. Name one person, usually a mobile lead or platform engineer, who answers for both budgets. That person reviews every exception and reports the trend to the COO or marketing lead each month.

If your team lacks the capacity to run this, dedicated mobile app engineering can own the pipeline for you.

Calculate the per-location cost of a slow launch

Convert launch delay into dollars so finance and operations can weigh it against other work. Use this formula:

Lost revenue per location per month = Daily app launches per location x 30 x Abandon rate due to delay x Average order value

Here is an illustrative example for a 40-location group:

• 150 daily launches per location
• 2% of launches abandoned because the app is slow (measure your own rate)
• $32 average order value

Per location: 150 x 30 x 0.02 x 32 = $2,880 per month.

Across 40 locations: 40 x $2,880 = $115,200 per month.

The abandon rate is the number to test. Pull it from session analytics or run a short test on launch speed. At this scale, a 0.5% change in abandon rate moves the total by $28,800 per month.

Key Insight: A launch budget is a business control, not an engineering preference. Give it a number, a gate, and one owner, then price the delay per location so leadership sees what a slow launch costs.

Related resources

Explore more from Gaazzeebo on this topic:

• Resource: the business automation playbook

Sources and References

Primary sources cited above:

• Android's launch-time documentation
• documentation on reducing app launch time