Android build size stuck at ~129 MB due to Sprite Atlas (95% textures) – looking for advanced optimization tips

Unity Engine
, , , , , , ,
1

Hi everyone,

I’m trying to reduce my Android build size below 100 MB, but I’m currently stuck at ~129 MB, with textures taking ~95% of the build according to the Build Report.

Project Setup

  • Unity version: 6000.3.5f1
  • Platform: Android
  • Build type: Release (Development Build OFF)
  • Scripting backend: IL2CPP
  • Target architecture: ARMv7 only
  • Output: APK

Current Build Size

  • Total build size: 129.38 MB
  • Textures: ~95.45% of the build

Assets

  • ~300 sprites (2D mobile game)
  • Sprite Atlas: Enabled
  • Largest contributor:
    • Card Sprite Atlas.spriteatlasv2 → ~105 MB
  • Audio:
    • Only 5 audio files, already optimized
    • Audio is not a significant factor

Texture Import Settings

  • Override for Android: Enabled
  • Max Size: 2048
  • Format: RGB(A) Compressed ASTC 12x12
  • Resize Algorithm: Mitchell
  • ETC2 fallback: Use build settings

:warning: I cannot lower Max Texture Size further (1024 / 512) without noticeable quality loss, so I’m specifically looking for non-destructive optimizations.

What I’ve already verified

  • Development Build disabled
  • Audio is optimized and minimal
  • No large unused assets
  • Build Report confirms Sprite Atlas textures as the bottleneck

What I’m looking for

  • Advanced Sprite Atlas optimization techniques (packing, padding, tight packing, atlas splitting, variants, etc.)
  • Common mistakes or pitfalls that cause atlases to become unexpectedly large
  • Any Unity 6–specific texture or build size optimizations that are easy to miss

At this point, I’m confident the issue is not basic import settings, so I’d really appreciate insights from people who’ve dealt with large Sprite Atlases on Android.

Thanks in advance!

2

As long as you hang onto this limitation it will be difficult to make meaningful progress.

I suggest you study your largest sprites for ones that have less information and try them at lower resolutions. Remember: the larger the sprite, the larger the reduction in build size if you are able to halve its dimensions.

Alternately you could move to something like Addressables to deliver your content post app install, perhaps even through the Unity content delivery stuff, although I haven’t used that system myself.

All of this stuff is bog-standard boring “reduce APK size” type stuff that the mobile app people have been doing for 20 years, so there is plenty of resources to consider online, no need to reinvent the wheel. It’s just data and we know how data compresses. :slight_smile: