After 16 APKs and 4 Articles, I Built the Tool I Kept Describing

Build Analyzer series, article 5 — the last one.

Full disclosure up front: this post announces a paid tool I made. The four
articles before it are measurement write-ups and stay exactly as they are,
and the measurement engine stays open source. This post is about what I
packaged on top, and why.

Five weeks ago I started measuring what actually makes a Unity Android build
large: 16 APKs, one variable at a time.

I did not plan to build a product. I planned to write articles.

But every article left behind code, because I refused to publish a number I
could not reproduce:

• Article 1 needed a repeatable experiment, so a build runner accreted.
• Article 2 needed honest numbers, so a BuildReport parser accreted.
• Article 3 needed to explain 0.46 MiB that packed assets could not, so an APK entry diff accreted.
• Article 4 needed the numbers to do something, so a CI gate accreted.

By the end I had a working pipeline that I was driving with text files, JSON
edited by hand, and a long -executeMethod command I kept in a notes file.

That gap — everything works, nothing is convenient — is what I built this
month.

Build Size Gate

Build Size Gate is an Editor window (Tools ▸ Build Size
Gate ▸ Open Window) wrapped around the series' measurement engine:

• Gate — run the baseline check in the Editor: a PASS/WARN/FAIL banner, per-metric deltas with reasons, and an Approve Current Build button for when growth is intentional.
• Baselines — capture a baseline from any build summary and edit thresholds in normal fields. The output is still the same boring, reviewable JSON from article 4 — it just no longer requires hand-editing.
• Layers — the article 3 technique as a tab: compare two APK/AAB files entry by entry and see that the growth went to libil2cpp.so and global-metadata.dat, not to your textures. Export the diff as CSV.
• CI Setup — generates the shell command and a GitHub Actions workflow with your actual paths, so the article 4 setup takes minutes instead of an evening.

It checks the three numbers this series kept coming back to — artifact bytes,
BuildReport.summary.totalSize, packed asset bytes — because a build can
regress in one while the others stay flat.

What stays free

I want to be precise about this, because the series' whole value is that you
can verify it.

Free, unchanged, forever:

• All four articles.
• The public experiment repository — reproducible project, raw CSVs, every measurement.
• The measurement engine under MIT: the post-build reporter, the gate logic, and the batchmode CLI. If you are comfortable assembling it yourself from the articles, you need nothing else. That was true last week and it is true now.

Paid (see the Asset Store listing for current pricing):

• The Editor window (all four tabs), baseline management without JSON editing, the Layers diff UI, the CI generators, bundled samples, and support with a human on the other end.

You are not paying for secrets. You are paying for the assembled, maintained,
convenient version of something you could build from the articles — and for
my time answering your questions when a build number looks wrong.

Honest scope, v1

• Built and validated on Android APK with Unity 6000.3 (IL2CPP/ARM64) — the exact setup the whole series used.
• The gate reads a plain-text summary and is platform-agnostic by design, but I have not validated iOS or AAB end-to-end yet. That is the roadmap, and I would rather ship a narrow tool that is honest than a wide one that is not.
• Editor-only. Nothing ships in your player build.

Who should not buy it: if you have no CI, no recurring size pressure, or you
enjoyed the articles and want to wire the free engine yourself — don't. The
free path is complete on purpose.

What five weeks of measuring taught me

The series changed how I think about build size, and the tool is just that
change made executable:

1. "Build size" is three numbers, not one.
2. Asset reports answer asset questions; code growth hides in the artifact.
3. An explanation after the fact is worth less than a gate before the merge.

The most useful sentence a build pipeline can say is still the one from
article 4:

This build grew by more than the team agreed to allow.

Build Size Gate exists so that sentence takes ten minutes to set up.

Links

• Build Size Gate on the Unity Asset Store: https://assetstore.unity.com/packages/tools/utilities/build-size-gate-ci-check-for-build-size-regressions-393158
• Free engine + experiment data: https://github.com/hellohanostudio/BuildAnalyzer
• The series: 1 — the experiment · 2 — three numbers · 3 — inside the APK · 4 — the CI gate

Thanks for reading along for five weeks. If the gate catches a 12 MB surprise
in your pipeline someday, I'd genuinely love to hear about it:
[e-mail]