DEV Community: HanoStudio

What Actually Makes a Unity Build So Large?

HanoStudio — Sun, 21 Jun 2026 14:59:18 +0000

Eight controlled Unity Android builds show how texture, audio, Korean font, and DOTween choices change APK size, with reproducible data and source code.

Most developers know that textures are heavy and uncompressed audio is bad. But ask which setting added how many megabytes to a real APK, and the answer often gets vague.

After 14 years of building and shipping Unity mobile games, I wanted measurements rather than folklore. I started with a minimal project, changed one variable at a time, built eight Android APKs, and then repeated the entire run.

The largest difference between the two runs was 8 bytes.

For per-asset measurements, I used the BuildReport parser included in the public experiment repository.

Run it yourself: The complete Unity project, build automation, both repeat-run CSVs, and every per-step raw report are public in the BuildAnalyzer GitHub repository.

The setup

Unity 6000.3.7f1
Android APK, not AAB
IL2CPP, ARM64 only
Built-in Render Pipeline
Development Build off
Managed Stripping Level: Medium
Engine code stripping enabled
One scene with one camera, one directional light, and one cube

The scene included a small reference harness so every test asset was genuinely referenced. That makes the 14.32 MiB baseline specific to this experiment, not a universal Unity minimum.

I measured the APK itself with FileInfo.Length:

var artifactBytes = new FileInfo(report.summary.outputPath).Length;

This matters because BuildReport.summary.totalSize, the sum of packed assets, and the final compressed APK size are three different metrics.

The results

Each row changes one condition from the row immediately before it.

Step	Controlled change	APK size	Delta
0	Minimal experiment project	14.32 MiB	-
1	Referenced 2048x2048 texture, Android RGBA32	28.12 MiB	+13.80 MiB
2	Same texture, Android ASTC 6x6	16.14 MiB	-11.98 MiB
3	Add referenced 30-second stereo audio, PCM	21.19 MiB	+5.05 MiB
4	Same audio, Vorbis quality 0.5	16.60 MiB	-4.59 MiB
5	Add full Noto Sans KR dynamic font	19.49 MiB	+2.89 MiB
6	Same font, app-specific subset	16.63 MiB	-2.86 MiB
7	Add DOTween, preserved and referenced at runtime	17.10 MiB	+0.46 MiB

Texture: RGBA32 vs ASTC

The test texture was an opaque, deterministic 2048x2048 noise image with mipmaps disabled. Using high-entropy pixels prevented APK ZIP compression from making an uncompressed texture look artificially cheap.

Android format	Packed texture	APK
RGBA32	16.00 MiB	28.12 MiB
ASTC 6x6	1.78 MiB	16.14 MiB

ASTC reduced the texture's packed contribution by 88.84% and removed 11.98 MiB from the APK. The ASTC build was still 1.82 MiB above baseline; compression did not make the texture free.

The practical lesson is not simply "use ASTC." Pick a format and block size that your target devices support, then inspect the visual cost on real hardware. But leaving a large mobile texture as RGBA32 is an expensive default.

Audio: PCM vs Vorbis

The audio input was deterministic 30-second stereo PCM at 44.1 kHz. It contained several tones plus noise so it behaved more like real content than a silent WAV.

Android format	Packed audio	APK
PCM	5.05 MiB	21.19 MiB
Vorbis, quality 0.5	0.46 MiB	16.60 MiB

Vorbis reduced the packed audio by 90.98% and removed 4.59 MiB from the APK.

That does not make Vorbis correct for every clip. Short, latency-sensitive effects and long music tracks have different runtime requirements. The important part is that import format is a measurable build-size decision, not a housekeeping detail.

Korean font: full source vs app subset

For the font test I used the same Noto Sans KR Regular dynamic font in both builds. The first build embedded the full source font. The second used a subset containing the characters required by a small example UI plus ASCII letters, digits, and punctuation.

Font condition	Packed font	APK
Full Noto Sans KR	5.94 MiB	19.49 MiB
App-specific subset	0.07 MiB	16.63 MiB

Subsetting reduced the packed font data by 98.88% and removed 2.86 MiB from the APK.

This is specifically a dynamic source-font comparison. A TextMeshPro static atlas has different tradeoffs, and a dynamic font may need fallback glyphs or downloadable language packs. Do not quote this percentage for every font pipeline. Do measure the character coverage your product actually ships.

DOTween: the part PackedAssets did not explain

For the final step I enabled the DOTween Free DLL for Android, preserved it through linking, and referenced it at runtime through the experiment harness.

The APK grew by 0.46 MiB. But PackedAssetInfo attributed only 192 bytes to the DLL path.

Most of the increase appeared elsewhere:

libil2cpp.so compressed size grew by about 0.36 MiB.
global-metadata.dat compressed size grew by about 0.06 MiB.

This is the result that changed how I think about the analyzer. A per-asset report is necessary, but it cannot explain all code growth. A useful build analyzer needs to show at least three layers separately:

Final artifact bytes
Packed asset contributions
Native and managed code or metadata changes

What surprised me

The texture was the largest single increase, but the font result was more useful. A full Korean dynamic font added 2.89 MiB to this APK; an app-specific subset recovered almost all of it.

The second surprise was the metric mismatch. In the final build:

APK artifact: 17.10 MiB
BuildReport.summary.totalSize: 143.54 MiB
Packed asset sum: 5.60 MiB

None of these values is wrong. They answer different questions. Reporting one as if it were another creates a very convincing but incorrect chart.

Finally, the two full experiment runs were remarkably stable. Across 16 APK builds, each matching step differed by at most 8 bytes. That made the large deltas easy to trust.

The takeaway

Build size is not one big mistake. It is an accumulation of import formats, referenced content, font coverage, enabled code, engine modules, and packaging.

The controlled experiment produced three high-value changes:

ASTC 6x6: -11.98 MiB versus RGBA32
Vorbis quality 0.5: -4.59 MiB versus PCM
App-specific Korean font subset: -2.86 MiB versus the full font

The exact numbers belong to this project and configuration. The method is the reusable part: fix the build settings, change one variable, measure the final artifact, and use BuildReport to explain what changed without mistaking it for the artifact itself.

You can clone the public experiment repository and run all eight builds from the Unity menu or command line.

Next, I will apply the same measurement loop to a real mobile project and track which changes survive contact with production assets.

I'm a Unity client developer with 14 years of experience in mobile and live-service games. I write about optimization problems I keep encountering in production.

Experiment files

Repository: hellohanostudio/BuildAnalyzer
Automation: ExperimentBuildRunner.cs
Raw results: experiment-results-run1.csv and experiment-results-run2.csv
Per-step BuildReport exports: Results/raw
Unity API: BuildReport.packedAssets and PackedAssetInfo
Font: Noto Sans KR from Google Fonts, SIL Open Font License 1.1

5 Reasons Your Unity Mobile UI Breaks Across Devices

HanoStudio — Fri, 12 Jun 2026 15:14:26 +0000

And a Practical Pre-Release Checklist for Safe Areas, Aspect Ratios, and Localization

Mobile UI often looks fine in the Unity Editor.

Then you test it on a real device.

The top currency bar is too close to the notch. The bottom button overlaps with the home indicator. A popup looks fine on 16:9, but gets cut off on a smaller phone. German or French text overflows outside the button. The tablet layout feels stretched and empty.

After 14 years of shipping Unity mobile games, these are the five UI issues I keep seeing across real projects.

They are not always caused by bad UI design. Most of the time, they come from small assumptions that only break when the game is tested across different devices, safe areas, and languages.

In this post, I want to share 5 common reasons Unity mobile UI breaks across devices, and a simple checklist you can use before release.

The same Unity mobile menu before and after a UI QA scan

The same menu before and after a UI QA scan.

1. Applying Safe Area to Everything

One of the most common mistakes is applying Safe Area to the entire Canvas.

At first, this feels safe. If everything is inside the Safe Area, nothing should overlap with the notch or home indicator, right?

But in practice, this often creates another problem.

Backgrounds, dim overlays, screen effects, and full-screen visuals should usually fill the entire screen. If you place them inside the Safe Area, the screen can look visually cropped or incomplete.

A better structure is to separate full-screen visuals from important interactive UI.

Example structure:

Canvas
├── FullScreenLayer
│   ├── Background
│   ├── Dim
│   └── ScreenEffect
│
├── SafeAreaLayer
│   ├── TopHUD
│   ├── CurrencyArea
│   ├── NavigationButtons
│   └── BottomMenu
│
└── PopupLayer
    ├── DimBackground
    └── PopupRoot

A simple rule:

Backgrounds and full-screen effects can extend to the full screen.
Buttons, HUD, currency, navigation, and readable UI should stay inside the Safe Area.

Safe Area is not for everything. It is mainly for important UI that the player needs to read or tap.

2. Testing Only One Aspect Ratio

Many UI bugs are not visible when testing only 16:9.

Mobile devices have many different screen shapes:

 16:9
 18:9
 19.5:9
 20:9
 4:3
 Tablet ratios
 Foldable or unusual ratios

A layout that looks good on one phone can easily break on another.

Common problems include:

Bottom buttons moving too close to the edge
Top HUD stretching too much
Popups becoming too tall
Side margins looking too wide on tablets
Important UI elements being pushed outside the screen

When testing Unity mobile UI, it is better to check layout behavior across multiple aspect ratios before release.

At minimum, I like to test:

 Small phone
 Tall phone
 iPhone-style notch device
 Android device with navigation bar
 Tablet

Even if you do not have all physical devices, using Unity Device Simulator or custom Game View resolutions can help catch many layout problems early.

3. Ignoring Localization Text Overflow

Localization can break a layout that looked perfectly fine in English.

A short English button label can become much longer in other languages.

Example:

 Start
 Start Game
 Spiel starten
 Commencer le jeu
 게임 시작하기

If your UI was only tested with English text, you may miss issues like:

Button text overflowing
Popup titles becoming two lines
Labels overlapping icons
Text being clipped inside fixed-size containers
Smaller devices not having enough horizontal space

This is especially important for mobile UI because the available space is already limited.

When testing localized UI, check:

 [  ] Long button labels
 [  ] Popup titles
 [  ] Shop item names
 [  ] Mission descriptions
 [  ] Error messages
 [  ] Settings menu labels
 [  ] Small screen layouts

Localization QA should not happen only at the end. It should be part of layout testing.

4. Making Popups Too Rigid

Popups are another common source of mobile UI bugs.

A popup may look fine on a large phone, but on a smaller device:

The title gets too close to the top
The content area becomes too tall
The confirm button is pushed near the home indicator
The popup is clipped vertically
Text cannot fit inside the panel

A safer popup structure is:

 PopupRoot
 ├── Title
 ├── ScrollContent
 └── ButtonArea

The key idea is:

Keep the title visible.
Keep the main buttons visible.
Let the content area scroll if the screen is too small.

Instead of making the entire popup fixed-height, consider giving it a maximum height and allowing the content area to shrink or scroll.

This is especially useful for:

Terms popups
Mission descriptions
Shop item details
Event notices
Settings panels
Localization-heavy UI

5. Trusting the Editor Too Much

The Unity Editor is useful, but it does not always represent the real device experience.

A UI can look fine in the Editor and still fail on device because of:

Safe Area differences
Device-specific navigation bars
Notches and rounded corners
DPI and scaling differences
Touch comfort issues
Real font rendering
Platform-specific behavior

Before release, it is important to test on actual devices when possible.

But even before device testing, you can catch many problems with a structured checklist.

A Simple Unity Mobile UI Pre-Release Checklist

Here is a practical checklist I use when reviewing mobile UI before release.

Safe Area

 [  ] Top HUD does not overlap with the notch
 [  ] Bottom buttons do not overlap with the home indicator
 [  ] Important buttons are inside the Safe Area
 [  ] Backgrounds still fill the entire screen
 [  ] Full-screen effects are not accidentally constrained by Safe Area

Aspect Ratio

 [  ] UI works on 16:9
 [  ] UI works on tall phones
 [  ] UI works on small phones
 [  ] UI works on tablets
 [  ] UI does not stretch too much on wide layouts

Popup

 [  ] Popup fits on small screens
 [  ] Main action buttons are always visible
 [  ] Long content can scroll
 [  ] Close button is easy to tap
 [  ] Popup title does not overlap with other elements

Localization

 [  ] Long translated button text fits
 [  ] Popup titles support longer text
 [  ] Text does not overlap with icons
 [  ] Important labels are not clipped
 [  ] Small screens are tested with long strings

Touch Comfort

 [  ] Buttons are not too close to screen edges
 [  ] Important buttons have enough padding
 [  ] Bottom UI is not too close to the home indicator
 [  ] Close buttons are easy to tap

Final Thoughts

Unity mobile UI does not usually break because of one big mistake.

It breaks because of many small assumptions:

assuming one aspect ratio is enough
assuming English text is representative
assuming Safe Area should apply to everything
assuming popups will always fit
assuming the Editor view is close enough to real devices

The best way to reduce these issues is to test UI with a clear checklist before release.

Safe Area, aspect ratios, localization, popups, and touch comfort should be reviewed together.

That is what helps catch layout problems before players do.

Resource

Going through this checklist manually across every device ratio and language takes a long time — I know because I did it for years.

So I built ScreenFit QA, a Unity editor tool that runs these checks automatically.

It scans your UI across multiple device resolutions, safe areas, and long localized strings, then reports broken layouts before release.

ScreenFit QA finding safe-area, touch-target, text-overflow, and localization issues

If this article's checklist felt useful, ScreenFit is that checklist, automated:

See ScreenFit QA on Gumroad