DEV Community: HanoStudio

What I Learned Reading Unity's BuildReport After Building 16 APKs

HanoStudio — Thu, 02 Jul 2026 05:13:51 +0000

Build Analyzer series, article 2.

In the previous article, I built 16 Android APKs while changing one variable at a time. After that, I had the APK numbers. What I did not have yet was a good explanation for where those bytes came from.

When I finished the build-size experiment, I almost published the wrong number.

Unity handed me three different "build sizes," and for a moment I was not sure which one represented the file users actually download.

That confusion is why I wrote a small BuildReport parser. I already had the final APK deltas, but I wanted evidence from inside Unity's build output too.

It helped, but not in the clean way I expected.

The first surprise: there was no single build size

My first instinct was to look for "the build size" in Unity's BuildReport.

That turned out to be the wrong mental model.

In the final measured Android build, I had three different size numbers:

Metric	Value
Final APK file size	17.10 MiB
`BuildReport.summary.totalSize`	143.54 MiB
Sum of `BuildReport.packedAssets` entries	5.60 MiB

At first glance that looks suspicious. How can the same build be 17 MiB, 143 MiB, and 5.6 MiB?

The answer is that they are not measuring the same thing.

APK bytes: the compressed artifact users download
BuildReport.summary.totalSize: Unity's reported build output size
Packed asset sum: serialized asset data inside packed build files

Once I separated those three, the rest of the experiment became much easier to reason about.

The smallest parser I needed

I did not start by building a polished UI. I only wanted a repeatable text report after every build.

Unity's IPostprocessBuildWithReport was enough for that.

using UnityEditor.Build;
using UnityEditor.Build.Reporting;

internal sealed class BuildAssetSizeReporter : IPostprocessBuildWithReport
{
    public int callbackOrder => 1000;

    public void OnPostprocessBuild(BuildReport report)
    {
        var rankedAssets = CollectAssetSizes(report);
        var packedAssetBytes = rankedAssets.Aggregate(
            0UL,
            (total, asset) => total + asset.Value);
        var artifactBytes = GetArtifactBytes(report.summary.outputPath);

        LogSummary(report, rankedAssets, packedAssetBytes, artifactBytes);
        WriteReports(report, rankedAssets, packedAssetBytes, artifactBytes);
    }
}

The full source is here:

https://github.com/hellohanostudio/BuildAnalyzer/blob/main/Assets/BuildAnalyzer/Editor/BuildAssetSizeReporter.cs

The important part is not the hook itself. It is what I decided to record:

The final APK file size from disk
BuildReport.summary.totalSize
A ranked list of packed asset entries

I wanted the report to make it hard for me to mix those up later.

Aggregating packed assets

BuildReport.packedAssets contains the packed files generated during the build. Each packed file contains PackedAssetInfo entries.

The fields I used were:

sourceAssetPath
sourceAssetGUID
packedSize

One thing I had to handle: the same source asset can show up more than once. Unity is reporting packed entries, not a neat "one source file, one row" table.

So I grouped by source path before sorting.

private static KeyValuePair<string, ulong>[] CollectAssetSizes(BuildReport report)
{
    var sizesByPath = new Dictionary<string, ulong>(StringComparer.Ordinal);

    foreach (var packedFile in report.packedAssets)
    {
        foreach (var asset in packedFile.contents)
        {
            var path = string.IsNullOrEmpty(asset.sourceAssetPath)
                ? $"<generated:{asset.sourceAssetGUID}>"
                : asset.sourceAssetPath;

            sizesByPath.TryGetValue(path, out var currentSize);
            sizesByPath[path] = currentSize + asset.packedSize;
        }
    }

    return sizesByPath
        .OrderByDescending(pair => pair.Value)
        .ThenBy(pair => pair.Key, StringComparer.Ordinal)
        .ToArray();
}

This was enough to check the asset-shaped parts of the experiment:

Did the texture really shrink after ASTC?
Did the audio data shrink after Vorbis?
Did the Korean font subset remove real packed bytes?

For those questions, the parser was useful right away.

I still measured the APK directly

I did not use BuildReport.summary.totalSize as the APK size.

For the artifact number, I read the file on disk:

private static ulong? GetArtifactBytes(string outputPath)
{
    return File.Exists(outputPath)
        ? (ulong)new FileInfo(outputPath).Length
        : null;
}

That produced a plain summary like this:

artifact_bytes=17928357
artifact_mib=17.0978
build_report_total_bytes=150514033
build_report_total_mib=143.5414
packed_asset_bytes=5873204
packed_asset_mib=5.6011

This is not fancy, but that is the point. I wanted boring measurement code because boring code is harder to argue with.

The CSV had a small surprise

The parser also writes a ranked CSV. This is the top of Results/raw/step-07-dotween-runtime-assets.csv from the final experiment step:

rank,packed_bytes,packed_mib,source_asset_path
1,2796376,2.666832,"Built-in Texture2D: Splash Screen Unity Logo"
2,1871556,1.784855,"Assets/Experiment/Generated/ExperimentTexture.png"
3,656420,0.626011,"Resources/unity_builtin_extra"
4,477252,0.455143,"Assets/Experiment/Generated/ExperimentAudio.wav"
5,69510,0.066290,"Assets/Experiment/Generated/NotoSansKR-Regular.ttf"

The biggest packed texture was not even my generated test texture. It was Unity's splash-screen logo.

That was a useful reminder. A ranked build report is not a list of "my files only". It includes built-in assets Unity packs into the player too.

The raw reports are here:

https://github.com/hellohanostudio/BuildAnalyzer/tree/main/Results/raw

The place where the parser failed

The parser explained textures, audio, and fonts pretty well.

Then I added DOTween.

DOTween Free increased the APK by 0.46 MiB. But the packed-asset CSV attributed only 192 bytes to the DOTween DLL path.

That was the moment the shape of the problem changed for me.

The parser was not "wrong". It was just looking through one narrow window. DOTween affected generated code and metadata, so most of the growth appeared in files such as libil2cpp.so and global-metadata.dat, not in BuildReport.packedAssets.

That was probably the most useful result of the whole parser exercise: it showed me exactly where the parser stopped being enough.

What I would use this for

After this experiment, I would use this kind of parser for asset questions:

Which texture is taking packed space?
Did an importer setting change actually reduce build data?
How much did a font contribute?
Did one source asset appear through multiple packed entries?

I would not use it alone for code-size questions:

How much did a plugin increase IL2CPP output?
Which assemblies affected native binary size?
Did managed stripping change generated code size?
Which files inside the APK changed?

For that, I need to inspect the final artifact too.

The rule I kept

The main thing I kept from this week is simple:

Do not say "build size" as if it is one number.

For every build, I now want these three values side by side:

Final artifact bytes from the file on disk
BuildReport.summary.totalSize
Sum of BuildReport.packedAssets[].contents[].packedSize

Then I use the packed-asset ranking as evidence, not as the final truth.

That small separation prevented the biggest mistake I could have made in the experiment: confusing what Unity packed as assets with what users actually download.

Sources

Unity API: BuildReport.packedAssets
Unity API: PackedAssetInfo
Unity API: BuildSummary.totalSize
Reproducible project: https://github.com/hellohanostudio/BuildAnalyzer
Previous article: https://dev.to/hanostudio/what-actually-makes-a-unity-build-so-large-3jh4

The app that concludes nothing until 14 days add up

HanoStudio — Fri, 26 Jun 2026 15:50:02 +0000

I built a mood tracker. But what I actually want to write about isn't "I shipped an app" — it's how carefully a product should speak when it barely has any data. That's the question I sat with the longest.

Why Mood Weather

Most mood apps score your feelings. They turn a mood into a 1–10, draw a graph, and sometimes say things like "you're showing a tendency toward depression." I didn't want that. A day's mood feels less like a verdict and more like a passing state.

So I made the metaphor weather. Today is clear, yesterday was fog. Instead of "I'm a wreck," I wanted you to be able to say "today's weather is stormy." This isn't a logging app — it's an app for observing, carefully.

The hardest decision: the voice

What I deliberated on longest wasn't a feature. It was a single sentence. Do I say "you are like this," or "here's a signal I'm seeing"?

The less data you have, the more a conclusion becomes a lie. Telling someone "you're sensitive to caffeine" off three days of logs is just false. So I pinned the app's identity to one line — signal, not diagnosis. The copy, the screens, the stat cards all follow it. Even when it surfaces a connection, it shows the sample size as a plain number, like "3 of 4 days." It doesn't hide how small that is.

The 10-second check-in problem

My first input form was heavy: several sliders, number fields, a note. But in an app you use every day, friction is death. Users don't open it again on day two.

So I made the default path "save just the weather." Context (sleep, movement, and so on) is added only when you want to. On mobile, all six weathers fit at a glance and the save button is pinned to the bottom. And one line for the days you skip — a missed day isn't a failure, it's a blank.

The first 14-day wall

Patterns only show up once data accumulates. An "insight" before 14 days is just noise dressed up as truth.

So I locked the report until day 14. Instead of leaving that gap empty, I turned it into a sense of progress — 1/14, 2/14 — and from day three, a light preview. Give a small reward, but defer the conclusions. I chose saying less over building hooks to keep people around.

Local storage and backup

No login. Open the app and you're in; records stay on this device only. For an emotional journal, privacy is trust.

Local-only has a weakness, though — data can vanish. So I added JSON export/import as a safety net. I also added optional outside-weather capture: the location is used once to fetch the weather, and the coordinates aren't stored. Trust is the whole point of this app, so I was especially careful with that one line.

Going public

It's on Vercel. Still an experiment.

This app won't tell you who you are. It just shows you what your mind's weather has been like lately.

Link: https://mode-weather.vercel.app

That's the concept and the first deploy. I'm not trying to claim "this is the right answer." I made these decisions, and the real test starts when actual 14-day histories begin to accumulate. That result is for #2.

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 a small BuildReport parser, which I break down in the follow-up article: What I Learned Reading Unity's BuildReport After Building 16 APKs.

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