Custom app package is over 100 MB and users say downloads are slow—will optimizing images first be a waste of time?

Bottom line first: For a custom app whose installer is over 100 MB and users say downloads are slow, optimizing images first is not necessarily a waste of time, but in most projects images are not the only major contributor. Based on 2026 delivery experience, for an 80–150 MB package, size commonly concentrates in native libraries and third-party SDKs (often 30–50%) and images, audio, and video assets (often 30–40%). To decide which part to tackle first, measure the package composition first, then rank by payoff and regression cost—do not delete assets based on gut feeling.

When an installer is oversized, what do users really care about?

Package size itself is not an experience metric; what users perceive is how long the download takes and how much space it takes after installation. Under average network conditions, the difference between 100 MB and 50 MB shows up in first-download wait time and data usage; in weak-network environments or during app store promotions, that difference can be magnified into concrete churn.

Based on common 2026 delivery practices, an Android first-release package around 60 MB is relatively comfortable; above 150 MB, it is worth checking whether video or untrimmed native libraries have been packed in. Because of different packaging mechanisms, iOS with the same features is usually smaller than Android, but it should not grow without limit either. A smaller package does not equal faster startup; these two things should be evaluated separately, not merged into one goal.

• Affects download conversion: Store detail pages show package size, and some users decide whether to install based on it.
• Affects update experience: If an incremental update fails, users have to fall back to a full download; the larger the package, the worse it feels.
• Affects installation success rate: On low-end devices with tight storage, large packages are more likely to fail installation or be cleaned up by the system after installation.
• Does not affect performance itself: Startup speed and lag mainly depend on code and network; package size is correlational, not causal.

Measure first, then reduce: a four-layer breakdown method

The package size is not one solid block; different layers have very different reduction methods and costs, and cutting them together can easily cut into functionality. So first break it into four layers and measure their proportions, then decide which layer to touch. This step does not take much time, but it avoids repeated rework later.

1. Code layer: business code, build artifacts, obfuscation and compression configuration.
2. Native library and SDK layer: .so libraries, third-party map, push, live streaming, analytics, and other SDKs.
3. Asset layer: images, fonts, audio/video, multilingual copy.
4. Channel and configuration layer: multi-channel packages, debug symbol files, backup and configuration files.

Each layer has different concerns: the asset layer is low-risk to change but its payoff depends on asset volume; the native library layer has a large payoff but requires retesting functionality; the code layer usually accounts for only a few percentage points and has limited payoff; the channel layer is where invisible size such as debug symbols is easiest to miss. For measurement, check against official documentation or build artifact analysis tools; do not rely on rough estimates.

Which layers can be reduced a lot, and which are risky to touch?

After breaking down the four layers, you can rank them by input and output. In experience, the asset layer and native library layer are the main sources of weight reduction, while the code layer is more about cleaning up along the way. Here is a set of typical ranges; how much can actually be reduced depends on the project's original compression habits, so do not treat the ranges as promises.

• Asset layer: Convert images to WebP/AVIF, output multiple image sets by screen density, remove duplicate assets. Typical range is often 10–30 MB, with lower risk, but confirm support for image formats on older system versions.
• Native library and SDK layer: Keep only the arm64 architecture, remove unused .so files, replace SDKs that are clearly oversized. Typical range is often 10–25 MB; relevant functionality must be retested after changes.
• Code layer: Enable obfuscation and unused code stripping; often reduces only a few MB, with small changes and small payoff.
• Channel and configuration layer: Split multi-channel packages, remove debug symbols and redundant configuration; often reduces a few MB to over ten MB, and is easy to overlook.

If you can only choose one layer to start with, the asset layer is suitable for packages with “many assets and a tight schedule,” while the native library layer is suitable for packages with “many stacked SDKs and heavy functionality.” The difference is not only the reduction amount but also regression cost: the asset layer mainly involves visual checks and older-version compatibility, while the native library layer requires retesting capabilities such as maps, push, and live streaming, which usually takes more testing time. A checkable order is: first look at composition proportions, then rank reduction amounts, and finally calculate regression cost.

Should all assets be bundled into the package, or downloaded on demand?

This is an unavoidable choice during weight reduction, and the two paths have different cost structures. The judgment criterion is: are these assets needed on every launch, and can users accept waiting a bit?

• Fully bundled in the package: available offline, no extra waiting on the first screen; drawbacks are a large package and a full re-download with every update.
• On-demand download: small package, lighter updates; drawbacks are a slower first screen on weak networks and extra handling of download failures and resumable downloads.

A relatively reliable approach is layered handling: put icons and fonts required by the startup first screen into the package, and load activity images, tutorial videos, and assets for secondary pages remotely. For C-end products that are sensitive to download conversion and have a broad user distribution, on-demand download is preferred; for tool apps that are mainly used offline or have very few users, full bundling may be less trouble.

Delivery scene: tight schedule plus a requirement to reduce package size to under 50 MB

There was a custom project where the client gave about two months of development time and also required the Android package to be compressed to under 50 MB without making the first screen noticeably slower. The team first audited package composition and found that short videos and large activity images accounted for the largest share, while native libraries also had room for trimming. The approach was to move videos and large images on secondary pages to CDN on-demand loading, then keep only the arm64 architecture and remove unused .so files. As a result, the package size dropped close to the target, but the first screen on weak networks took one or two seconds longer; placeholder images, preloading, and failure retries were later added to bring the experience back. The cost was about one to two extra weeks for download and caching logic. This kind of trade-off needs to be clarified during the requirements phase, rather than waiting for user feedback after launch to force rework.

Common pitfalls during slimming down

Reducing size itself is not hard; what is hard is making sure functionality still works after reduction. The following are recurring rework points in delivery; think through the consequences before making changes.

• Images are compressed too aggressively, list pages become visibly blurry, and after user complaints the only option is to roll back and re-export images.
• After trimming native libraries, some older devices or specific chips crash directly; such issues may not reproduce on test devices.
• Images are switched to a new format without a fallback, so older system versions show blank spaces.
• When deleting multilingual copy, the default language is deleted, and the interface falls back to English.
• Only configuration is changed without rebuilding and verifying the package; after signing and packaging, the size has not changed, and the effort was wasted.

To judge whether slimming work is acceptable, check two things: whether the target package size is met, and whether all core paths work on mainstream devices. In experience, cover at least a dozen common device models and major system versions before deciding to release.

Applicable scenarios and boundaries

Package size optimization is suitable for C-end products that are sensitive to download conversion, have a non-trivial share of weak-network users, or are subject to soft app store prompts about package size. At that point, reducing the package delivers visible payoff.

Conversely, for internal enterprise tools, apps used only in Wi-Fi environments, projects with only a few hundred installations, or packages already under 30 MB, there is no need to invest a dedicated development round just for size. Putting that time into startup speed and stability usually gives more direct returns.

There are also two boundaries to explain in advance: if core functionality depends on large amounts of offline assets—such as offline maps, offline courses, or on-site inspection materials—the room for package reduction will be clearly limited; if compliance or audit requirements call for retaining original assets and complete log symbols, it is also not suitable to forcibly cut them for size. Confirm these constraints first, then set the reduction goal.

FAQ

What package size is considered appropriate?

There is no unified standard. In experience, an Android first-release package in the 50–80 MB range is relatively comfortable; above 150 MB, it is advisable to first audit composition, then decide whether weight reduction is worth the investment.

Can you slim down by deleting images only?

For most projects, optimizing images alone can reduce 10–30 MB, but if the largest contributors are native libraries and SDKs, image deletion has limited effect. Look at proportions before acting, so you do not have to add assets back later.

Is optimizing images first a waste of time?

Not necessarily. The image layer is low-risk and quick to act on, but if its proportion is not high, reduction is limited; a more stable order is to measure composition first, then decide whether images or native libraries should be tackled first.

Will switching to on-demand download affect app store review?

Usually not, but the core offline-available path must be complete, permission and privacy statements must be consistent, and remote asset domains must be stable; do not put first-screen critical content on links that may be inaccessible.

Should full regression be done after slimming down?

Yes. Trimming native libraries, changing image formats, and deleting multilingual copy can all affect specific device models or languages. In experience, cover at least a dozen mainstream device models and major system versions before release.

If package size is already affecting download conversion, it is advisable to first audit package composition, then cut in the order of asset layer and native library layer, doing a real-device regression after each layer is reduced; Xiyue Company follows the same order in mobile delivery. Conversely, if the app is used only by a few dozen internal people in a Wi-Fi environment, or the package is already under 30 MB, putting effort into startup speed and stability is more worthwhile.