Reduce Indie Game Install Size Before Store Review - A 90-Minute Team Pass for Unity and Godot (2026)

Install size is a product problem disguised as an engineering chore. Players abandon slow downloads. Store surfaces penalize huge installs on cellular. Reviewers file pre-launch report warnings that read like vague homework unless you attach before and after numbers and one owner for each fix.

This guide is a ninety-minute team pass you can run the week before you hand a build to QA for store submission. It is not a deep engine course. It is a repeatable ritual that turns “we should optimize someday” into measured deltas your producer can paste into a release note.

If you want a longer case-study narrative with Addressables math, pair this pass with our cut build size with texture compression and Addressables case study. If you are still choosing engines for mobile, read Godot vs Unity mobile in 2026 for honest tradeoffs before you lock pipelines.

Who this is for and what you will ship in ninety minutes

Audience: Solo developers and small teams shipping Unity or Godot 4 to Google Play or PC storefronts where download size affects conversion.

Outcome: A size table (before and after), a three-line executive summary for your producer, and one prioritized follow-up task that is not “optimize everything.”

Prerequisites: A release or release-like build profile, not the editor. Someone who can run Android Studio APK Analyzer or an equivalent size diff for your Godot export.

Time budget: Ninety minutes wall clock with two people. One person drives the editor export settings. The other drives measurement tools and the spreadsheet.

Beginner Quick Start - The five numbers you must write down first

1. Install size the store or device reports for your candidate build (not editor play mode).
2. Download size if the store shows a separate compressed transfer size.
3. CPU architecture split if you ship fat binaries (armeabi-v7a, arm64-v8a, x86_64).
4. Largest content bucket from your analyzer (often lib/ for native code, assets/ for packaged content).
5. One risky assumption you are making (for example, “we never strip unused engine modules”).

Success check: You can answer “what is the biggest slice of the pie” without opening ten different tools.

Why ninety minutes beats a two-day optimization spike

Long spikes feel heroic. They also merge late, break cinematics, and stall certification. A ninety-minute pass forces scope control:

• You measure first.
• You pick one primary lever (textures, audio, duplicate locales, or native libs).
• You schedule everything else as ticketed work with owners.

This rhythm keeps store review focused on stability and policy, not on debating whether someone “already tried cranking compression once.”

Unity teams - the pass in three timed blocks

Block A (0 to 25 minutes) - Reproduce the store binary

1. Build with the same profile you intend to submit.
2. Produce an AAB for Play when Play is the target (AAB is standard for new apps).
3. Note scripting backend (IL2CPP vs Mono) because IL2CPP changes stripping and stack traces.
4. Capture Managed Stripping Level and link.xml presence if you rely on reflection-heavy plugins.

Pro tip: If your QA build differs from your submission build, your size table is fiction.

Block B (25 to 55 minutes) - Find the top three megabyte offenders

Use Android Studio APK Analyzer on the output you will ship (AAB contents are still analyzable in modern Studio flows). Sort by download size contribution and raw file size. Write the top three paths or categories.

Typical winners:

• Textures that are still max resolution for UI sprites.
• Audio left as large WAV inside streaming assets.
• Duplicate copies of the same font or localization table.
• Plugins you stopped calling three milestones ago but never removed.

Block C (55 to 90 minutes) - Apply one safe change and re-measure

Pick one change that is unlikely to need art reapproval:

• Raise texture compression for a clearly labeled batch (UI atlas, not hero character, unless you verify).
• Switch a non-looping SFX bank to a sensible Vorbis or Opus bitrate budget.
• Remove a language you are not launching with yet (ship en-only first, add locales in a patch with a tracked ticket).

Re-run the analyzer. Record delta MB and percent change.

Godot teams - the pass in three timed blocks

Block A (0 to 25 minutes) - Export with shipping honesty

1. Use your release export preset, not a debug convenience preset.
2. Confirm export filters exclude prototype scenes and sample assets.
3. If you use GDExtension, treat native libs as first-class size citizens the same way Unity treats lib/.

Block B (25 to 55 minutes) - Classify Godot’s usual suspects

Godot projects often balloon from:

• Uncompressed or oversized textures in imported textures.
• WAV left in place when Ogg or MP3 would suffice for short SFX.
• 3D meshes with duplicate materials and hidden high-poly duplicates in res:// folders you forgot to exclude.

Use your analyzer of choice on the produced APK or AAB, then map paths back to resource folders your team actually owns.

Block C (55 to 90 minutes) - One surgical change

Examples that usually survive review quickly:

• Reimport a batch of UI textures with a smaller max size and verify in-device readability.
• Move a music stem to streaming load if your game already streams levels.
• Delete duplicate audio assets after a filename search, not after guesswork.

Re-measure and log the delta the same way as Unity.

Play Console and the pre-launch report - speak the reviewer’s language

Google Play’s pre-launch report surfaces warnings that teams dismiss as “noise” until they stack. Size-related issues often overlap with memory and startup stability. Treat your size pass as evidence that you are not shipping a debug kitchen sink.

When you respond to warnings, include:

• Build id or version code the warning referenced.
• Device profile if the warning is device-specific.
• What you changed in one sentence and what you measured after.

If you need a broader Play checklist for first-time publishers, use how to publish an AI game on Google Play in 2026 as the companion doc for policy steps, then return here for size discipline.

PC storefronts - size still matters

Steam and other PC clients care about disk footprint and patch deltas. A ninety-minute pass still works if you replace APK Analyzer with:

• Folder diff between two build outputs.
• Unpacked streaming asset comparisons.
• Symbol and debug bundle separation so you do not ship PDB mountains by accident.

Unity Player Settings - the knobs people argue about for an hour

You do not need to master every Android checkbox in ninety minutes. You do need to know which toggles require a full regression versus a quick smoke test.

IL2CPP usually increases build time but enables better stripping paths than Mono for shipping games. If you are already on IL2CPP, your pass should confirm Managed Stripping Level matches what your plugins tolerate. If a plugin relies on reflection, you may need a link.xml file—treat that file as version-controlled product code, not a personal side quest.

Split Application Binary (Play feature delivery style packaging) can move large content into delivery-time slices. It is powerful and easy to misconfigure. In a ninety-minute pass, only touch this if your analyzer shows assets/ or obb-like dominance and you already have a delivery plan QA agrees with.

Target Architectures deserve a deliberate choice. Shipping fat APKs with every ABI “just in case” is a classic silent size tax. If your analytics show no 32-bit device requirement, discuss dropping x86 or legacy ABIs with your producer before you promise a number.

Script Compilation and Burst or Entities packages are out of scope here, but if lib/ dominates your analyzer output, your next ticket probably belongs to native code owners, not to the artist who offered to “compress PNGs.”

Godot import defaults - stop re-solving the same texture twice

Godot’s import dock is fast until it becomes thirty different one-off fixes. For a disciplined pass:

• Decide one default max size for UI versus world textures and document it in a one-page art standard.
• Use VRAM compression choices that match your target GPUs, not your laptop’s comfort.
• Batch-reimport after changes, then spot-check two worst-case screens (HUD text and a distant prop).

If you maintain multiple resolutions of the same asset in res://, you are paying human attention and bytes. Prefer one source texture and sane scaling rules unless a platform genuinely requires bespoke atlases.

Size lever versus risk - pick from this table before you edit art

Your ninety-minute pass should touch at most one row that sits in the high risk half unless you already have a green QA lane for it.

A one-week calendar around submission - where this pass sits

T minus 14 days - Lock feature scope. No new content packs without a size budget line item.
T minus 7 days - Run this ninety-minute pass on a release candidate build.
T minus 3 days - Freeze anything that changes native code or plugin versions unless you reset the clock.
T minus 1 day - Re-run only measurement on the final candidate; compare hashes to the T-7 table.

If your producer wants “just one more trailer-quality cinematic” at T-2, negotiate which size row pays for it.

Common mistakes that waste the ninety minutes

Myth one - “We will fix size after we fix gameplay.”
Gameplay fixes ship every week. Size fixes get deferred until submission week, when you cannot afford risky reimports.

Myth two - “Compression fixes are always safe.”
Aggressive texture compression on fine text or thin UI lines creates unreadable HUDs. Scope changes to asset classes you can visually verify in one session.

Myth three - “Stripping will break everything.”
Stripping breaks reflection and serialization edge cases. That is why you budget time for a test build, not why you skip stripping forever.

Myth four - “We deleted scenes, so assets are gone.”
Engines and exporters still pack reachable assets. Run a unused asset pass appropriate to your pipeline, then verify with a second analyzer snapshot.

Evidence naming - make the spreadsheet boring

Create a three-column table:

Add a notes column only when needed. Reviewers and future you care about repeatability, not storytelling.

Store the spreadsheet next to your build log folder with a filename that includes version code and git hash. When someone asks why April’s build was smaller than May’s, you answer from rows, not memory. If you use continuous integration, attach the same table as a build artifact so support cannot confuse a local experimental export with the signed upload candidate.

When to escalate beyond ninety minutes

Escalate to a longer optimization task when:

• The top offender is native code you do not control without a vendor update.
• You need mesh or animation rework, not a parameter tweak.
• Addressables or remote catalogs need architecture changes (see the Addressables case study for that class of work).

If the analyzer shows duplicate copies of the same audio or texture under two different paths, resist the urge to delete one copy during this pass unless you can prove which path the engine references at runtime. Mis-deleting the referenced asset is how ninety-minute rituals turn into all-night hotfixes. Log the duplicate as a follow-up with a repro scene and a single owner.

Key takeaways

• Measure release binaries, not editor comfort builds.
• Use one analyzer pass to name the top three contributors before touching art.
• Apply one safe change per ninety-minute session and re-measure immediately.
• Treat AAB and architecture splits as first-class size levers on Play.
• For Godot, export filters and import defaults beat frantic scene deletes.
• Pair size work with Play pre-launch evidence habits, not vibes.
• Document before and after numbers for producers and reviewers.
• Schedule deep refactors separately from this ritual so you keep shipping.
• Watch UI texture compression especially—early wins, easy regressions.
• Keep audio bitrate decisions explicit and tied to content type.

FAQ

Does this replace profiling GPU and CPU work?
No. This pass targets packaged bytes. Performance is adjacent but different work.

Should we prioritize size over crash fixes?
Crash fixes win. Size work runs parallel when possible, or immediately after stability gates go green.

Is Mono ever the right call for smaller size?
Sometimes, but IL2CPP is common for shipping Android. Deciding Mono versus IL2CPP is a platform and toolchain choice, not something you flip in ninety minutes without testing.

What if our biggest slice is a third-party SDK?
Document the vendor version, ask for lite modules if available, and schedule a vendor upgrade task rather than inventing home-grown hacks.

Do we need a dedicated build machine?
No, but you need consistent export settings. If laptops differ, you will chase ghosts.

How often should we run this pass?
At minimum before each store submission candidate and after any milestone that adds large content packs.

What if Gradle dependencies dominate the diff?
Treat that as a supply-chain task. Upgrade or replace the library, enable ABI splits if your pipeline supports them safely, and never “fix” native size by deleting lib/ entries you do not understand.

Can we win size by lowering target API level?
Usually a policy mistake, not a size strategy. Play’s target API requirements move forward; chasing size by lagging API levels trades a small byte win for a rejection risk.

Should we compress video trailers inside the game package?
Often they should stream from your site or CDN, not ship inside the first download. If marketing insists on offline trailers, budget them like content packs with explicit MB ownership.

Conclusion

Install size work pays off when it is boring: same ritual, same spreadsheet, same willingness to stop at one lever when the clock runs out. Run this ninety-minute pass, attach numbers to your release note, and let your next milestone focus on the game players actually feel. If leadership wants a headline metric, give them percent reduction on the download path players actually hit, not vanity totals from an old sideload APK.