Prove the two builds belong in the same comparison.
A precise delta between unlike builds is still misleading. Record the variables that can move output independently of the code change.
Pin the build contract
Record Unity version, platform and target, scripting backend, development/release state, architecture, stripping level, compression, and the build entry point.
Name the baseline
Use an accepted commit and artifact, not whichever prior file is easiest to find. Preserve the baseline identifier beside every result.
Stop on material mismatch
If the contract differs, label the comparison non-comparable or separate environment movement from the candidate change before applying budgets.
Persist the evidence Unity already produces.
The first useful layer is structured build output. Keep it with the artifact so a later reviewer can reproduce the numbers.
Capture BuildSummary
Persist total size, total duration, result, warnings, errors, platform, and timestamps from the Unity BuildReport.
Keep packed-asset attribution
Where supported, retain PackedAssets and PackedAssetInfo so size contribution can be traced to source asset GUIDs, paths, types, and packed size.
Enable Addressables layout reports
For Addressables builds, retain the build layout report and inspect bundle size, explicit and implicit assets, bundle dependencies, and duplication clues.
Rank changes by materiality, then attribution confidence.
Start with facts that survive build-to-build comparison. Attribution should become less confident—not more dramatic—as evidence gets weaker.
Report absolute and relative movement
Show bytes and percentage for the complete artifact and agreed sections. A small percentage on a large build can still cross a delivery constraint.
Separate payload classes
Break out player/native code, managed code, scenes, resources, bundles, textures, audio, and symbols only where the artifact or report exposes a defensible boundary.
Attach the evidence path
Every attributed change should point back to the BuildReport, layout report, bundle, package entry, or other inspectable record that supports it.
Make the budget reviewable instead of magical.
A budget is a team decision encoded as policy. Keep it versioned, scoped, and explainable.
Use platform-specific thresholds
Define absolute and relative thresholds per build target and metric; avoid a single percentage across Android, iOS, desktop, and content delivery.
Distinguish fail, review, and observe
Reserve blocking status for trusted measurements and agreed limits. New or heuristic checks should begin as informational.
Keep an explicit unknown
If the reports cannot attribute a material delta, say so and name the next artifact needed. Do not convert proximity in the source diff into certainty.
Inspect the underlying documentation.
This guide is XeSoft's evaluation framework, not a substitute for the source documentation. Links below go to the primary publisher.
Structured totals, duration, warnings, errors, platform, result, and timestamps.
UnityPackedAssets scripting API ↗Asset contribution records attached to a BuildReport.
UnityAddressables build layout report ↗Bundle, asset, dependency, and duplication evidence for Addressables output.
UnityAddressables Analyze tool ↗Unity's existing Addressables inspection surface and analysis rules.