What should you check before accepting a mobile app release?
Direct answer. Accept an app release against six evidence groups: the exact build, working journeys, upgrade behaviour, declarations, reviewer access and release status. A submitted build and an app available to customers are two different milestones; record which one the supplier is delivering.
Commissioning work now? Compare the Google Play submission scope, or send the project details for a scope check.
Name the release milestone before testing the app
A founder may hear “the app is done” when the developer means that a file has been built. The business may mean that customers can install it from a store. Between those points are test distribution, account readiness, declarations, review and release controls. Write those milestones separately in the quote and decide what evidence closes each one.
For an existing Android app, record the package name, current live version and candidate version. For iOS, record the bundle identifier, version and selected build. Ask for a short change list in ordinary language: which customer problem changed, which areas should remain unchanged and which backend deployment the app depends on. Avoid an acceptance conversation based on an unnamed file sent through chat.
Build a small acceptance matrix around business journeys
Use the original six-row worksheet below to brief the supplier and collect evidence. A row is complete when the agreed result is demonstrated on the candidate build, with the device and test conditions recorded. These are commissioning suggestions, not a claim that either store mandates this exact worksheet.
Choose journeys by consequence. If the app creates bookings, follow one booking into the staff system. If it collects enquiries, inspect the matching record. If there are accounts, test sign-in, sign-out and the intended recovery path. A screen recording that stops at a success banner leaves the business outcome untested.
| Check | Write before work | Collect before acceptance |
|---|---|---|
| Build identity | Package/bundle ID, candidate version and changes | The exact test build and matching console selection |
| Core journey | A realistic customer action and staff result | Test result on named devices, plus destination record |
| Install and upgrade | Fresh install and state that should persist | Both paths checked, with defects listed |
| Declarations | Business-approved data, SDK and permission information | Declaration review tied to the candidate build |
| Reviewer access | Demo account or mode and access instructions | Access works without a founder-only step |
| Release status | Track, submission owner and release decision owner | Dated console status and next action |
Check a fresh installation and an upgrade separately
A clean installation can work while an upgrade loses a preference or leaves an old session in an unexpected state. Ask for both paths where the release updates an existing app: install the current production version, create labelled test state, then update through the agreed test channel. Note what should persist and what should require sign-in again. Use test accounts and remove test records according to the agreed cleanup plan.
Android distinguishes the internal versionCode from the versionName people see. Its documentation calls for successive releases to use a greater versionCode. Ask the supplier to record the actual candidate values rather than treating a renamed download file as version evidence. Signing and account access should be handled through an agreed secure route; a public enquiry form is not a place to upload a keystore or password.
Make review access and declarations match the tested build
Apple’s review guidance asks for complete metadata, working access to account-based features and reachable backend services. Give the reviewer a permitted demo account or suitable demo mode, with concise notes for a non-obvious journey. Do not make the reviewer depend on an OTP that only the founder can receive, or a test account that was disabled after the developer’s demonstration.
Have the app owner approve the description of data collection, permissions and connected SDKs. The supplier needs information from the people who understand the product; guessing from screenshots is a weak basis for declarations. Keep the privacy policy address and support route working. If behaviour changes after the declaration review, make reassessment part of the release decision.
Separate business readiness from the store clock
For personal Google Play developer accounts created after 13 November 2023, Google currently requires a closed test with at least 12 testers continuously opted in for 14 days before an application for production access. Meeting the test threshold starts that application step; it does not guarantee production access. Confirm the actual account’s dashboard requirements before announcing a launch date.
Ask for the current console status and the next responsible person: waiting for business information, ready for submission, submitted for review, changes requested, approved awaiting release or available. Capture the status at handover with its date. A supplier can report what was submitted and respond within its scope, while the store retains its own decision and timing.
Use a release note that someone else can act on
Example acceptance brief: “For our existing booking app, identify the candidate build and test a fresh installation, upgrade from the current store version, login recovery and one booking reaching our staff dashboard. Document the review login, declarations approved by us, selected track and present console status. We will approve submission after the six-row evidence sheet is complete.” This is an illustrative brief; additional testing or code changes require an agreed scope.
Put unresolved issues in a decision list with severity, workaround, owner and the business person accepting the risk. Decide who watches support requests after release and who can pause distribution or prepare a corrected version if a significant problem appears. Do not describe an older build as a universal rollback: customer data and backend changes may require a separate recovery plan.
Match publishing help to the work still required
ZoopCoder’s Play Store publishing service covers listing and declaration preparation, the release submission and the first round of Google feedback. The client provides the signed AAB, console access and listed assets. Store fees, recruiting testers, Google’s review time and its final decision are excluded. Buy submission assistance after the app itself is ready for that scope.
For an existing Android version, the app update release scope prepares and submits the release; writing new features or fixes is excluded. The separate iOS publishing scope handles App Store Connect submission and listing-level feedback, with required code changes quoted separately. We sell these services, so use this guide to compare our boundaries and evidence with any supplier you are considering.
Questions before you commission the work
Does a publishing service include fixing the app?
Only if the quote says so. Submission preparation, listing feedback, code changes and feature development are different scopes. Check the service exclusions before paying.
Is a submitted app already available to customers?
No. Submission, review, approval and availability are distinct states. Ask for the current console status and the next action rather than an undated upload screenshot.
Should I accept only a screen recording?
A recording can support acceptance, but it should identify the candidate build and show the agreed result. Test access, destination records, declarations and console status need their own evidence.
Sources and scope
Primary documents checked 4 November 2026. The commissioning tables and sample briefs are editorial suggestions, not platform requirements or measured client outcomes. Live service pages govern the current price and included work.