# A Unity Release Candidate Checklist Built Around Change Risk Review a Unity release candidate using an identified artifact, change-based test coverage, upgrade checks, and an explicit decision about unresolved risks. Canonical URL: https://gameskit.ai/blog/unity-release-candidate-checklist Last updated: 2026-10-29 [Unity](https://gameskit.ai/blog#unity) Review a Unity release candidate using an identified artifact, change-based test coverage, upgrade checks, and an explicit decision about unresolved risks. [AI Games Kit Editorial](https://gameskit.ai/blog#editorial) Published October 8, 2026 · Updated October 29, 2026 4 min read [← All guides](https://gameskit.ai/blog) A release candidate is a specific artifact with a specific configuration. Testing a nearby development build does not establish that the candidate has the same scenes, content, or behavior. Start by making the object of the release decision unambiguous. Imagine a puzzle-game update that adds a new level pack and changes the save format. Its highest risks include discovering the new content, preserving old progress, and returning safely after an interrupted session. A useful checklist gives those changes more attention than an unchanged decorative menu animation. /01 ## Identify the artifact and its configuration Record the source revision, Editor version, package lock state, target platform, build profile, and artifact hash. Preserve the exported output that testers receive. Unity’s Build Profiles organize configuration for a target, so verify the selected profile and resulting settings rather than relying on the name of a build folder. Confirm the intended entry scene, included content, service environment, and development instrumentation state. Keep secrets out of distributable configuration and review evidence. If a setting changes after the candidate was tested, identify the replacement as a new candidate and determine which checks need to run again. /02 ## Map each change to a player-facing risk Review the actual diff and content changes, then list the player journeys they can affect. Include indirect dependencies: a shared UI prefab may affect old levels, and a changed save schema may affect startup before the new pack is even opened. Give each risk a test route and an owner. For the fictional update, prioritize an existing player reaching the new pack with previous progress intact. Also test a new player who has no save. Keep a short smoke route for unchanged essentials such as launching, making a move, finishing, failing, and restarting. The change map determines the deeper checks beyond that common route. /03 ## Exercise upgrade and interruption paths Use disposable historical fixtures to test the upgrade path from each supported save version. Verify that completed levels remain completed and that the new content appears under the intended rules. Reopen the migrated save after exiting the candidate. A successful first session alone cannot show that the new state was persisted correctly. Exercise interruption at meaningful boundaries: leaving during a level transition, canceling an optional download, or returning after pause. Pick scenarios relevant to the actual platform and architecture. Record the expected recovery before running the test, and distinguish a safe, explained failure from a silent reset of player progress. /04 ## Check the target experience and evidence Run the candidate on representative supported devices and input methods. Inspect readability, controls, audio settings, loading, and the performance scenarios most affected by the update. Use the project’s agreed budgets and preserve capture conditions. Do not convert an unavailable device into a passing result because a similar machine worked. Collect relevant player logs when a failure occurs; Unity documents where those logs are available on each target. Tie every report to the artifact, device, steps, and expected outcome. Remove unrelated personal information from shared evidence. A short reproducible report is more useful than an unexplained collection of screenshots from several different builds. /05 ## Make the decision and recovery plan explicit Summarize passed, failed, and unverified checks separately. For each remaining issue, state the player consequence, affected scope, owner, and reason for accepting or blocking it. A large number of successful minor checks should not dilute a known progress-loss failure. Keep the release decision attached to evidence from the actual candidate. Retain the prior artifact and consider whether it can read saves written by the new version. If rollback has a data-compatibility limit, document the forward-repair option before release. After the candidate is distributed, verify the delivered version through the real installation or hosting path. The release record should remain useful when someone needs to diagnose or recover from a later problem. Keep this in mind ## Key takeaways - Identify one immutable candidate and tie every test result to its actual build configuration. - Use the change set to prioritize upgrade, interruption, and target-device coverage. - Keep failed and unverified checks visible and plan recovery around save compatibility as well as code. ## Sources & further reading Consult the source documentation for the version and platform you are working with. - [Unity 6 manual: build profiles](https://docs.unity3d.com/6000.0/Documentation/Manual/build-profiles.html) - [Unity 6 manual: log files](https://docs.unity3d.com/6000.0/Documentation/Manual/log-files.html) Inside the AI Games Kit ## Workflows for your next step - [Game Release Regression Check](https://gameskit.ai/#roster) - [Unity Project Audit](https://gameskit.ai/#roster) - [Unity Performance Profiling](https://gameskit.ai/#roster) Explore these agents and skills in the [Games Kit roster](https://gameskit.ai/#roster). Keep building ## More from the field notes [All guides](https://gameskit.ai/blog) [Unity](https://gameskit.ai/blog/unity-game-settings-persistence) ### Make Unity Game Settings Persist and Apply Consistently Trace Unity settings from stored values to runtime behavior, define defaults and apply rules, and test persistence without erasing unrelated player progress. October 7, 2026 4 min read Read guide [Unity](https://gameskit.ai/blog/unity-play-mode-vs-build-bugs) ### Debug a Unity Game That Works in Play Mode but Fails in a Build Compare Unity Editor and player behavior using matching routes, real player logs, build configuration, and one controlled hypothesis at a time. October 6, 2026 4 min read Read guide [Unity](https://gameskit.ai/blog/unity-performance-regression-budget) ### Set a Unity Performance Regression Budget You Can Enforce Define Unity performance budgets around player scenarios, comparable captures, and explicit release decisions instead of a single unexplained average frame rate. October 5, 2026 4 min read Read guide Put the workflow to work ## Give your next game a focused team. Explore the AI Games Kit’s agents and skills for Unity and browser-game development, from debugging and playtesting to release preparation. [Explore the AI Games Kit](https://gameskit.ai/#pricing) [See how to use it](https://gameskit.ai/start) --- Markdown version of https://gameskit.ai/blog/unity-release-candidate-checklist, from AI Games Kit (https://gameskit.ai). Site index: https://gameskit.ai/llms.txt · Full text: https://gameskit.ai/llms-full.txt · AI usage policy: https://gameskit.ai/ai.txt