Publishing an app is a sequence of checks, not a single upload. A build can be accepted for processing while the app still needs privacy declarations, reviewer access, production-track approval or a release decision. Plan App Store submission and Google Play publishing alongside development rather than treating them as a final administrative task.
This checklist was checked against official documentation on November 10, 2026. Platform requirements change. Verify the linked rules and your account’s console notices before submission; your app category, account type and distribution region can change what applies.
1. Establish account ownership and responsibilities
The business should know who owns the developer accounts, who can publish, and who provides legal and store-listing information. Invite developers through appropriate roles rather than sharing passwords or recovery codes. Complete required identity or business verification early.
Make a responsibility list for the app name, support contact, privacy policy, screenshots, age/content rating, data declarations and review notes. Developers can explain technical behavior, but the owner must confirm business facts and data practices. Allocate time for missing materials before announcing a fixed public launch date.
App submission readiness worksheet
Google Play submission and Apple App Store submission use separate developer accounts, declarations and review workflows. Use this worksheet for an iOS and Android app launch, assigning a named person to each responsibility. Record each item as ready, missing or not applicable, with a link to the evidence in your private project workspace.
| Check | Prepared by | Evidence to review | Submission blocker |
|---|---|---|---|
| Developer account and app identity | Account owner | Correct organization, app identifier and publisher access | Verification or required permissions incomplete |
| Signed release build | Developer | Tested build, version and build number | Upload validation or release testing fails |
| Store listing | Owner and designer | Accurate description, support URL, screenshots and rating responses | Required fields or assets missing |
| Privacy and data declarations | Owner with developer input | Released SDK inventory, privacy policy and completed platform declarations | Statements do not match the released app |
| Account deletion, when required | Developer and owner | Tested in-app path and Google Play web resource | Applicable deletion journey incomplete |
| Reviewer access | Developer and owner | Working review account or review mode, instructions and reachable backend | Reviewer cannot complete the main workflow |
| Testing and production access | Release owner | Applicable test evidence and console access status | Required testing or access application incomplete |
The owner confirms business information, while the developer verifies the app’s behavior. Keep passwords, review credentials and API keys out of public checklists. A ready worksheet means the team has checked its materials; track platform review and the eventual release as separate statuses.
2. Check current build requirements, not an old tutorial
As of this review, Apple requires uploads to use Xcode 26 or later with the applicable version-26 SDK. Apple also lists a separate iOS/iPadOS deployment-target minimum of iOS 13. These are different concepts: the SDK used to build an app is not the minimum operating system your app or chosen framework supports. See Apple’s current requirements.
For standard Android phone and tablet apps, Google’s published requirement since August 31, 2026 is Android 16, API level 36, for new apps and updates. Other device categories have different thresholds. An existing app’s discoverability requirement is also distinct from submitting an update. Check the Google Play target API policy and the actual Play Console notice.
Do not stop at changing a version number. Test your release build and its dependencies against the required platform behavior. A build configuration that passes upload validation is not proof that the app works correctly on real devices.
3. Allow for Google Play closed testing where applicable
For personal developer accounts created after November 13, 2023, Google requires a closed test with at least 12 testers continuously opted in for at least 14 days before applying for production access. Meeting that threshold enables the application for access; it is not automatic publication. This is not a universal rule for every organization account. Follow the official account-specific testing requirements.
Recruit people who can use the actual workflow and report problems. Keep a simple record of feedback, fixes and what was tested. A last-minute tester count is not a substitute for a useful test, and internal distribution should not be confused with public production availability.
4. Make privacy declarations match the released app
Inventory authentication, analytics, crash reporting, payments and every SDK that may handle data. Google requires Data safety disclosures to account for third-party libraries as well as your own code. Compare declarations with the release configuration, not only an early prototype. Google’s Data safety guidance explains the required disclosures.
Apple has privacy-manifest requirements for listed SDKs, with signature conditions for relevant binary dependencies. Flutter and common plugins can be part of that dependency review. Check Apple’s SDK requirements rather than assuming a framework handles every declaration automatically.
5. Test deletion, login and reviewer access
Where account creation is supported, Apple requires an in-app account-deletion route. Google’s applicable policy requires an in-app deletion path and an external web resource for requesting deletion. Test the complete path, including how the backend handles associated data and any disclosed retention exceptions. See Apple’s privacy rules and Google’s deletion requirements.
Provide working review credentials or the appropriate review mode, clear instructions and a reachable backend. Explain hardware or location dependencies. Reviewers should not meet an empty account, an expired login or a feature that only works on the developer’s network.
6. Respond to rejection with evidence
Read the cited issue, reproduce it on the submitted version and distinguish a code problem from missing information. Fix the relevant cause, update inaccurate metadata and explain the change plainly. Do not resubmit an identical build repeatedly without addressing the issue. Payments, subscriptions and regional distribution require their own policy check; there is no universal payment shortcut.
7. Automating App Store Connect and Play Console submissions
Automating App Store Connect and Play Console submissions is useful when the same team repeatedly prepares releases. Start with a tested manual release process, then automate the repeatable steps: building, checking the artifact, uploading approved materials and recording the result. Keep the decision to submit for review or release to users explicit.
Apple documents build uploads through Xcode and Transporter, including command-line upload options. The Google Play Developer Publishing API supports build uploads, store-listing changes and distribution-track operations. Tools such as fastlane provide App Store upload and Google Play upload workflows. Check the current tool options and account permissions before enabling any submission or production-release action.
A practical release pipeline separates five checkpoints:
- Build and test the intended version, including its production configuration and signing setup.
- Validate the app identifier, version, screenshots and release notes against the approved release.
- Upload to the intended platform and testing destination, retaining the build identifier and processing result.
- Ask the release owner to confirm declarations, reviewer access and the next submission or rollout action.
- Record review and publication status separately, and verify the actual store listing after release.
Automation does not replace required account verification, account-specific testing, accurate privacy answers or platform review. An upload-success message only confirms that step; a rejected build, processing failure or review issue needs investigation before another attempt. Store automation credentials in the team’s approved secret manager or CI secret store, grant only the access needed and keep secrets out of repository files and logs.
For a Flutter iOS and Android MVP, agree whether the scope includes a single submission-support cycle, repeatable release automation or both. These are different deliverables. Document who maintains signing, updates dependencies and operates subsequent releases after handover.
AIUNSEEN Studio’s mobile MVP service can include an agreed submission-support cycle. Apple and Google retain approval authority. Include account status, target platforms and known review constraints in the project brief so development and launch responsibilities are scoped together.