Prepare compatible releases and debug failures

Before publishing

1. Save a named checkpoint.
2. Review Code editor diagnostics and run the Studio test matrix.
3. Recheck manifest audience, descriptors, entry and controls.
4. Review save-format changes and test migration from the live release’s data.
5. Confirm the rating in Publish and write useful release notes.
6. Submit and inspect the resulting checks.

A successful preview does not bypass rating confirmation, account eligibility or review.

Diagnose a failed release

Distinguish build findings from runtime-check failures and reviewer notes. Reproduce the issue in the same host context where possible. In Studio use Problems, Build output and Console. On a live game’s Overview, inspect grouped crash reports and the affected release before changing code.

Record safe reproduction steps. Do not put player names or private data in logs to make debugging easier.

Roll back carefully

Switching a release changes what players get on their next load. It does not restore the project editor. Restoring History changes the working project but does not switch the live game.

A previous release may not understand saves written by the newer one. Read the save-format confirmation and assess data compatibility before switching. Keep migrations backward-aware where practical.

Store listing

Later releases do not overwrite the approved store page seeded by the first release. Update store copy and covers through the separate review flow when controls or presentation change.