App Store and Google Play Submission Checklist for New Releases and Updates

Overview

Publishing an app is more than uploading a binary. Apple and Google each require a combination of account access, signed builds, store metadata, privacy disclosures, age or content ratings, screenshots, and release settings. The exact fields and technical requirements can change, so treat this guide as a working release checklist rather than a substitute for the current instructions in App Store Connect and Google Play Console.

Start preparation before the build is ready. Store copy, screenshots, privacy answers, subscription configuration, and reviewer notes often require input from product, legal, design, engineering, and support teams. Keeping these items in one release worksheet reduces last-minute changes and makes rejected submissions easier to diagnose.

For teams using cross-platform app development tools, low-code platforms, or a backend for app development, confirm who owns the signing credentials, build configuration, privacy documentation, and production environment. The platform may generate much of the app, but the publisher remains responsible for the submitted product and its disclosures.

Checklist by scenario

For a first release

• Confirm ownership: Verify the correct Apple and Google developer accounts, organization details, tax or payment information where applicable, and the people authorized to submit releases.
• Create the app records: Use the final app name, package or bundle identifier, primary category, support contact, marketing contact, and privacy policy URL. Keep identifiers consistent between your app development software, build pipeline, and store records.
• Prepare a signed production build: Check the application identifier, version and build numbers, release configuration, signing certificates or keys, entitlements, permissions, and production endpoints. Confirm that debug menus, test accounts, mock data, and development URLs are removed.
• Complete store metadata: Write a clear title, short description or subtitle, full description, keywords where supported, promotional text where applicable, support URL, and marketing URL. Describe what the app actually does rather than promising features that are not available in the submitted build.
• Supply visual assets: Capture screenshots for the required device families and orientations. Make sure the images show the current interface, readable text, and real functionality. Add preview video only when it improves understanding of the product.
• Finish ratings and privacy disclosures: Answer the platform’s age, content, data collection, tracking, and privacy questionnaires accurately. Review the answers against the SDKs, analytics services, advertising tools, authentication providers, and backend services used by the app.
• Test the complete journey: Test installation, account creation, sign-in, password recovery, purchases, notifications, deep links, offline behavior, permissions, account deletion, and support contact flows on real devices where practical.

For an app update

• Record the new version and build number, then confirm the uploaded artifact matches the release notes and intended branch.
• Review every changed permission, data flow, SDK, API, subscription, login method, and external link. A small code change can affect privacy answers or review behavior.
• Write release notes that explain user-visible changes in plain language. Do not use the notes to hide known defects or describe work that is not included.
• Run regression tests for existing features, especially sign-in, purchases, saved data, migrations, push notifications, and deep links.
• Check that the listing screenshots and description still represent the current interface. Update them when the product’s primary screens or value proposition have changed.
• Review crash reports, performance data, and support tickets from the previous version before submission. Application monitoring tools that combine logs, metrics, traces, and alerts can help identify release risks before users encounter them.

For a regional launch or subscription change

• Confirm the countries or regions, languages, currencies, tax handling, and availability settings for the release.
• Localize store metadata and screenshots only when the translation has been reviewed in the actual product context. Avoid machine-translated claims that change the meaning of pricing, eligibility, or features.
• Verify subscription products, offers, introductory terms, entitlement mapping, restore-purchase behavior, and cancellation or account-management links.
• Test the purchase flow using the platform’s appropriate testing environment and accounts. Confirm that the app handles declined payments, interrupted transactions, restored purchases, and expired access.
• Document the launch sequence for the app binary, backend configuration, feature flags, and marketing activity so the app and its services change in a controlled order.

For a rejected submission

• Read the complete review message and identify whether the issue concerns functionality, metadata, privacy, payments, account access, content, or technical configuration.
• Reproduce the reported path using the same account type, region, device conditions, and steps where possible.
• Fix the underlying issue rather than changing only the wording. If the behavior is intentional, provide concise reviewer notes, test credentials, navigation steps, and an explanation of the relevant product decision.
• Recheck the entire submission after making changes. A new build, privacy answer, screenshot, or entitlement configuration can introduce a separate inconsistency.

What to double-check

Signing and identity: Store records, package identifiers, certificates, provisioning settings, and uploaded artifacts must refer to the same app. Store signing keys and recovery information in an access-controlled system, and document who can rotate them.

Privacy consistency: Compare the store questionnaire with your privacy policy, consent screens, permission prompts, SDK inventory, and server-side data flows. Include data collected by embedded services, not only data handled by your own code.

Build and backend compatibility: Check API versions, database migrations, authentication settings, feature flags, push certificates, universal or app links, and minimum supported app versions. If you deploy the backend separately, establish whether the old app version will continue to work during rollout.

Access for review: If the app requires an account, paid access, location, hardware, or a special setup, provide a reliable review path and clear instructions. Use test credentials that will remain active during the expected review window, while avoiding sensitive personal data.

Current platform requirements: Before uploading, consult the latest official submission screens and technical guidance for both platforms. Check required target SDK or API settings, supported device declarations, screenshot dimensions, content-rating questions, privacy fields, payment rules, and any warnings shown by the consoles.

Common mistakes

• Uploading a development build with test endpoints, placeholder content, verbose logging, or incomplete permissions.
• Using screenshots from an older interface or showing features unavailable in the submitted version.
• Answering privacy questions from memory instead of checking the app’s SDKs and data flows.
• Forgetting that a new login provider, analytics package, advertising SDK, or payment feature may change disclosure requirements.
• Submitting without testing a clean install and an update from the previous production version.
• Leaving reviewer notes vague, incomplete, or dependent on an employee’s personal account.
• Changing the app, backend, store listing, and subscription configuration simultaneously without a rollback plan.
• Assuming a no-code app builder or managed deployment platform handles store compliance automatically. These tools can simplify build and deployment work, but they do not replace product-level testing and accurate declarations.

When to revisit

Use this checklist before every first release, major update, seasonal launch, regional expansion, monetization change, or resubmission after rejection. Revisit it whenever the app adds a permission, login method, SDK, tracking behavior, subscription, external service, or backend migration.

Review the official Apple and Google requirements on a regular schedule, especially before a planned release cycle. Platform forms, target API expectations, screenshot specifications, payment workflows, review rules, and account settings can change independently of your code. Assign one person to verify these inputs and record the date of the check in the release worksheet.

For a practical final pass, copy the following into your issue tracker or release document:

1. Release version, build number, commit, and release owner.
2. Signed artifact location and rollback build.
3. Test devices, operating system versions, and clean-install results.
4. Store metadata, screenshots, privacy policy, ratings, and disclosure review status.
5. Test account credentials and reviewer instructions.
6. Backend, feature-flag, notification, link, and subscription changes.
7. Known issues, monitoring dashboard, support contact, and post-release checks.
8. Links to the current platform guidance reviewed before submission.

Completing this worksheet does not guarantee approval, but it makes the release auditable and reduces avoidable surprises. After launch, monitor the app, backend, and support channels, then feed the findings into the next app update checklist.