Store-Ready Mobile Build Checklist: Packaging, QA, and Release Readiness

What “Store-Ready” Means in Practice

A store-ready build is not just “it runs on my phone.” It is a reproducible, signed, versioned release candidate that passes a defined QA matrix, meets performance targets under realistic conditions, and is compliant with platform policies (privacy, permissions, disclosures). The goal of this checklist is to move from an internal build to a release candidate (RC) with minimal last-minute surprises.

Suggested Pipeline Stages (Engine-Agnostic)

• Internal Build: frequent, may include debug tooling; used by the team.
• QA Build: close to release settings; stable enough for systematic testing.
• Release Candidate (RC): identical to what will ship unless a blocker is found; changes are tightly controlled.

1) Build Configuration Checklist (Debug vs Release, Symbols, Versioning, Signing)

1.1 Define Build Types and Their Rules

Create explicit build “flavors” so everyone knows what is being tested. Avoid ad-hoc toggles that differ per developer machine.

• Debug: assertions on, verbose logging, dev menus enabled, profiling hooks allowed, test servers allowed.
• QA/Release: optimizations on, assertions off (or limited), logging minimized, dev menus disabled, production endpoints (or a controlled staging environment), analytics enabled as intended.

1.2 Versioning: Make It Deterministic and Trackable

Stores typically require a monotonically increasing build number and a user-facing version string. Decide your scheme early and automate it.

• User-facing version (e.g., 1.4.0): shown in store and settings.
• Build number (e.g., 10423): increments every upload; used to identify exact binaries.
• Source revision tag: embed commit hash/build timestamp for internal diagnostics.

Step-by-step:

• Pick a version format and document it (e.g., MAJOR.MINOR.PATCH).
• Automate build number increments in CI (or a shared script).
• Embed a “Build Info” screen (hidden behind a gesture or menu) showing version, build number, environment, and content catalog version.
• Ensure crash reports and analytics include the same identifiers.

1.3 Symbols and Crash Diagnostics (Without Shipping Debuggability)

Release builds should be optimized, but you still need actionable crash stacks. This requires generating and archiving symbol files and mapping artifacts.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

• Generate symbols for each build (platform-specific symbol formats).
• Upload symbols to your crash reporting service (or store them securely for later symbolication).
• Archive mapping files if code is obfuscated/minified.
• Verify symbolication by forcing a test crash in a QA build and confirming the stack trace is readable.

Operational rule: no build is “shippable” unless its symbols are stored and retrievable.

1.4 Signing Concepts and Key Management

Stores require signed binaries. Treat signing keys as production secrets; losing them can block updates.

• Use separate signing identities for internal/testing vs production when possible.
• Centralize signing in CI or a controlled machine; avoid distributing keys to every developer laptop.
• Back up keys securely with access control and recovery procedures.
• Document certificate/keystore expiration and renewal steps.

Step-by-step:

• Create a signing inventory: which key signs which app ID/package ID.
• Restrict access to production signing credentials.
• Perform a “clean machine” signing test (new environment) to ensure the process is reproducible.
• Verify the signed build installs and updates over the previous store build (upgrade path test).

1.5 Packaging Sanity Checks

• Confirm package identifier/app ID matches the store listing.
• Confirm build outputs match store requirements (e.g., supported CPU architectures as applicable).
• Verify install size and on-device footprint against your targets.
• Verify first-launch experience: no dev popups, no placeholder content, no test endpoints.
• Confirm error handling for missing connectivity (if applicable) uses user-friendly messaging.

2) QA Matrix Checklist (Devices, OS, Aspect Ratios, Input Edge Cases, Suspend/Resume, Low Battery/Storage)

2.1 Build a QA Matrix That Matches Your Audience

A QA matrix is a deliberate selection of devices and OS versions that represent your expected players. Keep it small enough to execute, but broad enough to catch real-world issues.

Step-by-step:

• List your minimum supported OS and the top 2–3 OS versions in your target markets.
• Pick at least one device per tier (low/mid/high) for each platform you ship on.
• Add at least one tablet (if supported) and one unusual aspect ratio device.
• Document the matrix in a shared sheet with tester assignment and pass/fail columns per build.

2.2 Input and Interaction Edge Cases

Even if your core controls are solid, store readiness requires resilience to interruptions and unusual touch sequences.

• Multi-touch conflicts: two-finger touches during drag, pinch, or UI interactions.
• Touch cancel: incoming call/notification interrupts a gesture; ensure no “stuck pressed” state.
• Rapid context switching: opening system UI (notification shade), then returning.
• External input (if supported): controller connect/disconnect mid-session.

Step-by-step test script (repeat on multiple devices):

• Start a gameplay session; perform rapid taps and swipes for 30 seconds.
• Trigger a system interruption (notification, quick settings) and return; confirm controls still respond.
• Perform a multi-touch sequence that your game doesn’t explicitly use; confirm it fails safely.
• Open/close overlays (pause, settings) repeatedly; confirm no input leaks through.

2.3 Suspend/Resume and App Lifecycle

Mobile OSes frequently suspend apps. Store-ready builds must preserve state correctly and avoid crashes on resume.

• Backgrounding: home button/gesture while in gameplay, menus, loading screens.
• Resume: return after 5 seconds, 1 minute, 10 minutes.
• Termination: OS kills the app in background; app should restore gracefully on next launch.
• Audio focus: audio pauses/ducks appropriately when interrupted; resumes correctly.

Step-by-step:

• Enter gameplay; background the app; wait 60 seconds; resume; verify state and audio.
• Background during a load; resume; verify no deadlock or corrupted UI.
• Background and force memory pressure (open heavy apps); return; verify stability.
• Relaunch after termination; verify last known safe state (or a consistent restart policy).

2.4 Low Battery / Low Storage / Low Connectivity Conditions

Players run games under constrained conditions. Your build should fail gracefully and avoid data corruption.

• Low battery mode: verify gameplay remains functional; check for extreme frame pacing issues.
• Low storage: test install/update with limited free space; verify save operations handle failures.
• Connectivity changes: airplane mode toggles; Wi‑Fi to cellular; captive portal; intermittent drops.

Step-by-step:

• With near-full storage, attempt install/update; confirm user-facing errors are clear if it fails.
• Simulate low storage during runtime; attempt to save; verify you handle write failures safely.
• Toggle airplane mode mid-session; verify the game doesn’t hang and recovers when online returns.

3) Performance Verification Checklist (FPS, Memory, Load Times, Thermal)

3.1 Define “Pass” Criteria Before Testing

Performance verification is only meaningful with thresholds. Define targets per device tier (e.g., stable frame rate, maximum memory usage, maximum load time) and treat them as acceptance criteria for RC.

• Frame pacing: stable delivery matters more than peak FPS.
• Memory ceiling: set a maximum working set per tier to avoid OS kills.
• Load time budgets: cold start and scene transitions.
• Thermal behavior: sustained play without severe throttling.

3.2 FPS Stability and Frame Pacing Checks

Measure in representative gameplay, not just a quiet menu. Use consistent test routes so results are comparable between builds.

Step-by-step:

• Create a 3–5 minute “benchmark route” (same level, same actions, same camera path).
• Run it on each device tier with release settings.
• Record: average FPS, 1% low (or worst spikes), and visible hitch counts.
• Repeat after 15 minutes of play to capture thermal throttling effects.

3.3 Memory Ceilings and Leak Detection

Store readiness requires confidence that long sessions won’t crash. Focus on peak memory and trends over time.

• Long session test: 30–60 minutes with repeated level loads and UI navigation.
• Peak memory: note the maximum; compare to your ceiling for low-tier devices.
• Trend: memory should stabilize; steady growth suggests leaks or caching issues.

Step-by-step:

• Start from a cold launch; record baseline memory.
• Perform a loop: play → menu → play → restart level (repeat 10–20 times).
• Record memory after each loop; confirm it plateaus.
• If memory grows, capture a reproduction path and mark it as RC-blocking if it risks OS termination.

3.4 Load Time Verification (Cold Start and Transitions)

Players judge quality quickly. Validate load times on low-tier devices and under realistic storage conditions.

• Cold start: from app tap to interactive state.
• Warm start: resume from background to interactive state.
• Scene/level transitions: measure worst-case transitions.

Step-by-step:

• Reboot device (or force-stop app) to simulate cold start; time to first interaction.
• Background for 60 seconds; resume; time to interaction.
• Run your heaviest transition 5 times; record min/median/max.

3.5 Thermal and Battery Reality Checks

Thermal throttling can turn a smooth game into a stuttery one after 10–20 minutes. Validate sustained play.

Step-by-step:

• On a mid-tier device, play continuously for 20–30 minutes at typical brightness and volume.
• Observe: device heat, FPS degradation, input latency changes, audio glitches.
• Repeat while charging (some devices heat more) and confirm behavior remains acceptable.

4) Compliance Readiness Checklist (Permissions, Privacy Policy, Ad/IAP Disclosures)

4.1 Permissions Minimization and Justification

Request only what you truly need, and request it at the moment it becomes relevant. Unnecessary permissions increase review risk and reduce user trust.

• Audit all requested permissions and map each to a feature.
• Remove unused SDKs or features that pull in extra permissions.
• Ensure permission prompts have clear in-app context (why it’s needed, what happens if denied).

Step-by-step:

• List every permission in your build output.
• For each permission, document: feature dependency, user-facing explanation, and fallback behavior if denied.
• Test denial paths: deny once, deny permanently, revoke in system settings, then relaunch.

4.2 Privacy Policy Presence and Data Handling Transparency

If you collect any data (analytics, ads identifiers, crash logs, account data), you typically need a privacy policy accessible to users and referenced in the store listing.

• Ensure a privacy policy URL exists and is reachable.
• Include an in-app link (settings/about) to the privacy policy.
• Confirm disclosures match actual SDK behavior (analytics/ads/crash reporting).

4.3 Ads and IAP Disclosures (Store Metadata + In-App UX)

Stores often require clear disclosure of monetization and data usage. Ensure your store listing and in-app flows are consistent.

• IAP: product names, pricing tiers, restore purchases behavior (where applicable), error handling for failed transactions.
• Ads: disclose ad presence; ensure ad frequency matches what you claim; confirm ad consent flows where required.
• Age/content ratings: ensure your content and ad categories align with your rating selections.

Step-by-step:

• Review store listing fields: “Contains ads,” “In-app purchases,” data safety/privacy sections.
• Run a purchase test: success, cancel, failure, offline attempt; verify user messaging and state consistency.
• Verify “restore purchases” (if applicable) works on a fresh install.

4.4 Third-Party SDK Inventory

Every SDK can affect permissions, data collection, and stability. Maintain an inventory to avoid surprises during review.

• List SDK name, version, purpose, data collected, and configuration flags.
• Confirm you are using production keys and correct environments.
• Remove unused SDKs before RC.

5) Launch Assets and Rollout Basics (Screenshots/Video Concepts, Localization, Soft Launch vs Full Release)

5.1 Store Listing Asset Requirements (Conceptual Checklist)

Each store has specific requirements for screenshots, preview videos, icons, and feature graphics. Even without memorizing exact numbers, you can prepare a robust asset set and validate it against the store portal.

• Icons: correct sizes, no transparency issues where disallowed, consistent branding.
• Screenshots: represent real gameplay and UI; avoid misleading mockups.
• Preview video (if used): shows actual gameplay capture; avoids prohibited claims.
• Description text: accurate feature list, supported languages, support contact.

Step-by-step:

• Create a capture plan: which scenes best communicate the core loop and key features.
• Capture on-device (or high-fidelity capture) to match real UI and aspect ratios.
• Prepare assets for multiple aspect ratios if required by the store.
• Run a “truth check”: every claim in text and visuals must be present in the build.

5.2 Localization and Regional Readiness Checks

Localization is not only translation; it includes layout fit, formatting, and store metadata consistency.

• Verify supported languages in-app match store listing languages.
• Check text overflow/truncation in key screens (tutorial prompts, buttons, dialogs).
• Validate number/date formatting where applicable.
• Confirm customer support email/URL works in all regions you target.

Step-by-step:

• Switch device language for each supported locale; smoke test first-time user flow and store-related screens.
• Check purchase/ads consent dialogs in each language (if present).
• Review store descriptions per locale for accuracy and policy compliance.

5.3 Release Channels and Rollout Decision Points

Plan how you will expose the build to players: staged rollout reduces risk, while full release maximizes reach immediately.

Step-by-step rollout basics:

• Define “go/no-go” metrics for launch (e.g., crash-free sessions %, support ticket volume, critical bug count).
• Prepare monitoring: crash reporting, analytics events sanity, server health (if applicable).
• Prepare a hotfix plan: who is on call, how quickly you can rebuild/sign/upload, what triggers a rollback.
• Do a final RC checklist run: install, first launch, core loop, purchase/ad flows, suspend/resume, and a 15-minute thermal/perf spot check on low-tier and mid-tier devices.