Test a named release candidate on actual devices, reconcile store information and declarations, and retain submission and post-release evidence.
Name the build revision, intended stores and territories, supported OS/device configurations and accountable release owner. Separate a prototype test from a production release. Create a live requirements list from the relevant store dashboards and policies, including dependencies such as account setup, signing, privacy declarations and review access.
Generate a matrix with exact build labels and representative devices, input modes and language/accessibility settings. Test first launch, a full round, save/resume, interruptions, offline behavior and any login or purchase path. Record expected behavior, actual result and reproducible evidence; use a new target label after fixing the build.
Run the same representative sequence under stated device, thermal and power conditions. Record frame-time behavior, memory, startup and battery/thermal observations. Convert the chosen FPS target to a comparison interval, and calculate texture data only when investigating a specific imported resource. Measure compressed download and installed size separately; a component estimate is useful only with an explicit observed packaging factor.
Prepare accurate screenshots, descriptions, content-rating answers, support contacts and review instructions for the release candidate. Review data collection by your code and integrated SDKs, then complete the applicable platform declarations using the current definitions. Exercise review access and purchase behavior in the platform’s supported test environment.
Resolve release-blocking defects against written acceptance conditions. Record any accepted limitation, owner and user-facing workaround. Complete the store’s current submission checklist, retain the uploaded build identity and record review feedback. Schedule the rollout through the actual account controls only after the responsible owner approves the candidate.
Observe crashes, failed sessions, support reports and the measurements you intentionally configured. For a return-rate question, choose one original cohort, one exact follow-up day and a consistent activity definition; compare only eligible members observed on that day. Assign follow-up fixes based on severity and evidence, retest them and preserve the release history.
Draft and download the release checklist, review notes and follow-up record.
Record lifecycle, device and purchase test results against exact build labels.
Calculate exact ratios for the device/display configuration list.
Convert a chosen FPS target for comparison with measured frame times.
Count a specific imported texture’s data and mip levels.
Compare measured component packaging assumptions with the real delivered size.
Calculate an exact-day return percentage for an observed original cohort.
Loading your checklist…
Use Apple’s current guidelines for completeness, accurate metadata, access for review and the behavior of the submitted app. Match the evidence to the actual release candidate.
Play reports can highlight stability, performance and accessibility problems on the tested configurations. Review their coverage and reproduce relevant findings in your own device matrix.
Review the current Data safety definitions and scope for your distribution track, including integrated SDK behavior. Keep the declaration consistent with what the app actually collects and shares.
Keep one accountable decision record.
| Record | Evidence |
|---|---|
| Candidate | Version, revision, upload identity and supported configurations |
| Readiness | Tests, resolved blockers and explicitly accepted limitations |
| Store review | Submission checklist, declarations, access and feedback |
| Follow-up | Crash/support observations, next actions and owner |
A test result is useful only when it points to the build that will actually be released.
Define cohort dates and activity consistently before comparing return rates.