How to Publish a Mobile App: Pre-Review Checklist for App Store and Google Play

To publish a mobile app with fewer avoidable delays, treat store submission as a product-readiness review, not an administrative task at the end of development. Apple and Google assess the submitted build, but they also rely on the listing, privacy disclosures, review access, payment flow, and support details to understand what customers will receive. A polished interface cannot compensate for a broken sign-in path, misleading screenshots, missing reviewer credentials, or declarations that do not match the app’s real behaviour.

For a business owner, this is an important control point when reviewing a development partner’s work. You do not need to inspect source code to ask useful questions: Who owns the store accounts? Which devices and customer journeys were tested? What happens if a payment fails? Which third parties receive user data? Who can submit an urgent update after launch?

Before you publish a mobile app: define the review scope

Submission and release are separate decisions. A build may be ready for store review while marketing assets, customer support, pricing, or launch timing still need approval. Agree on the release plan early: target countries or regions, supported languages, free or paid model, availability date, and the person authorised to make the final release decision.

Start with the journeys that a reviewer and a first-time customer must be able to complete. These commonly include opening the app, onboarding, registration or sign-in, password recovery, the core value-producing action, a purchase or subscription where relevant, account settings, and help or contact options. If a journey is intentionally unavailable for a specific market or user role, explain that clearly in the review notes and store configuration.

A practical acceptance criterion is simple: a person who has never seen the project can install the public build, understand its purpose, and complete its central task without private knowledge from the team. If that is not possible, the release package needs clearer instructions or more product work.

Keep store ownership with the business

The legal business entity should normally own its Apple developer and Google Play Console accounts, payment profiles, domains, analytics properties, and production signing arrangements. A contractor can receive the access needed to build and submit, but relying on a vendor’s personal or shared account can complicate updates, revenue reporting, account recovery, security, and a future change of supplier.

Ask for a written handover inventory covering the account owner, administrator roles, recovery email, two-factor authentication owner, signing-key responsibility, source repository access, backend hosting, domain DNS, crash reporting, analytics, push-notification configuration, and external-service credentials. Sensitive credentials should be transferred through an appropriate password-management process, not stored in an unprotected spreadsheet or chat thread.

Make the app reviewable without guesswork

Reviewers may not be able to create an account, receive a one-time code, join a private workspace, or access your office network. If the app requires authentication, provide working review credentials and explain any role-specific setup. If content is behind a paywall, membership, location restriction, hardware connection, or approval workflow, include precise steps and keep the necessary environment available during review.

Do not provide a demonstration account with different functionality from the submitted build. The account, permissions, and content should let the reviewer inspect the features described in the listing and privacy disclosures.

App Store review checklist and Google Play inputs

The two store consoles use different labels and workflows, and their requirements change over time. Your team should confirm the current prompts in each console before submission, particularly for target operating-system versions, content ratings, encryption questions, permissions, monetisation, and data declarations. The comparison below is a management tool, not a replacement for checking the live platform requirements.

For both stores, keep a dated copy of the information submitted through the console. This reduces risk when a new feature, SDK, market, or business model changes data handling or product positioning later.

Test the release build, not just a developer environment

A common launch problem is assuming that a feature which works on a developer’s device will work after installation from the store. The release build may use different signing, environment variables, API keys, entitlement settings, deep-link configuration, push certificates, or purchase products. Test the exact candidate intended for submission through the platform’s appropriate pre-release distribution route.

Cover representative physical devices, current and older supported operating-system versions, small and large screens where applicable, and both strong and weak network conditions. Check what happens when the app is interrupted by a call, sent to the background, restarted, denied a permission, or opened from a notification or deep link.

• Install the app as a new user and test update behaviour from an earlier version if customers will be upgrading.
• Verify registration, sign-in, logout, password reset, email or SMS verification, and each social sign-in path.
• Test the primary user task from start to finish, including empty states, errors, cancellation, and recovery.
• Check push notifications, app links, file uploads, camera or location features, and offline or slow-network behaviour where relevant.
• Confirm text, prices, dates, currencies, and layouts work in every supported language and region.
• Review crash reports and non-fatal errors from test distribution before submitting.

Do not hide a known defect merely because it is uncommon. Decide whether it affects a core journey, data integrity, security, or the reviewer’s ability to use the app. If it does, fix it before submission. A documented limitation may be manageable only when it is genuinely peripheral, clearly communicated, and does not contradict store claims.

Validate the services behind the interface

Also test every dependency that makes the app useful: CRM synchronisation, inventory, booking engines, maps, notifications, identity providers, email or SMS services, and internal APIs. Confirm rate limits, error messages, fallback behaviour, and monitoring ownership. An app can pass a visual quality check yet fail customers because an integration is using staging credentials or a production firewall blocks mobile traffic.

Ask the delivery team to identify which systems are essential to the main customer journey, who owns each one, and how the business will learn about an outage. That turns “the app is live” into an operationally meaningful state rather than a store status.

Align privacy, permissions, and third-party services

Privacy work is a product exercise, not a last-minute form. Make a data map that lists what the app collects, why it is collected, where it is sent, how long it is retained, and which supplier processes it. Include analytics, advertising, crash reporting, maps, chat, authentication, payment, customer-support, and attribution SDKs. A library can collect identifiers or diagnostic information even when the screen design does not make that obvious.

Published apps on the App Store and Google Play generally need a publicly accessible privacy-policy URL, including apps that do not sell goods. The policy content and the disclosures required in each store must still reflect the app’s actual data practices, features, and integrations. An app that collects no relevant user data should say so accurately rather than reuse a generic policy written for a different product.

Your privacy policy, in-app explanations, and store disclosures should tell the same story. If the app requests access to the camera, photos, location, contacts, microphone, calendar, or notifications, make the request at the point where the user chooses a feature that needs it. Explain the benefit in plain language. Requesting several sensitive permissions on first launch without clear context is difficult to justify and can harm completion rates.

Review data flows again after enabling a new marketing tool or software development kit. The publisher remains responsible for understanding what integrated services do; “the vendor added it” does not resolve an inaccurate disclosure. Avoid embedding private API secrets in the app package, and ensure that test accounts, test data, and internal endpoints are not exposed in the production release.

Consistency matters more than elaborate wording: the app’s real behaviour, store declarations, privacy policy, and user-facing permission messages must describe the same product.

Check payments, subscriptions, and operational integrations

Monetisation requires end-to-end testing. For digital goods, features, content, or subscriptions sold inside an app, confirm the appropriate platform billing approach for your distribution model and the current store rules. For physical goods, appointments, or external services, the relevant flow may differ. Validate the current policy for your exact use case rather than copying a payment pattern from another app.

Test successful purchase, cancellation, pending or failed payment, restore or recovery options where applicable, renewal messaging, entitlement changes, and customer-support escalation. The product should not grant paid access indefinitely because a server callback failed, nor remove legitimate access after a user reinstalls the app. Finance, support, and engineering should agree on who investigates disputed access and how the decision is recorded.

Where the product does not take payment, apply the same discipline to its central transaction or conversion: submitting a booking, requesting a quote, sending an order, reserving stock, or sharing information with a sales team. Confirm that the customer receives a meaningful result and that staff can see, act on, and trace the request.

Make the listing accurate and the handover usable

Your listing sets expectations that the product must meet. Describe the core customer benefit, not an ambition on a roadmap. Screenshots and preview media should show genuine app experiences, accurately represent the supported platform, and avoid claims that cannot be verified. If a feature depends on a paid plan, a specific location, a partner account, or compatible hardware, say so where customers can make an informed decision.

Prepare working support and privacy-policy URLs on domains the business controls. Give support staff a short operational brief covering the current version, known issues, ways to reproduce common problems, the payment escalation path, and how to report a suspected privacy or security issue. If users can create accounts, define the account-management and deletion process appropriate to the product, applicable requirements, and the places where it is offered.

For businesses choosing a supplier, this is where deliverables should be explicit. If you plan to order a custom mobile app, ask whether the scope includes store listing assets, a privacy-data inventory, review notes, test distribution, submission assistance, release monitoring, and a post-launch handover. “Publishing included” can mean anything from handing over a build file to managing the complete release package.

Run a final submission gate and prepare for release

Use this mobile app launch checklist as the final gate before the release owner submits the build. Assign one accountable person to collect approval from product, engineering, marketing, support, and the business owner. A lightweight release record prevents avoidable confusion: submitted build number, source commit or release tag, test evidence, devices tested, open issues and decision owner, listing copy version, disclosure review date, reviewer credentials, and rollback or hotfix contact.

1. Confirm that the submitted build is the approved release candidate and is connected to production-safe services.
2. Repeat the highest-value customer journeys using the actual review account and real store configuration.
3. Check that names, icons, screenshots, descriptions, URLs, contact details, prices, territories, ratings, and availability settings are complete and consistent.
4. Verify privacy declarations against the current build and its third-party services.
5. Provide concise reviewer notes for any non-obvious access, hardware, location, or account requirement.
6. Decide whether release is manual, scheduled, or phased where that option fits your risk tolerance, and name the release owner.
7. Set monitoring for crashes, backend errors, payments, sign-in, support requests, and store feedback from the first day.

After approval, monitor rather than declare the project finished. Store processing, regional availability, customer adoption, and backend demand can reveal issues not seen in testing. Keep the release team reachable, preserve the ability to stop a problematic rollout where platform controls allow it, and prioritise clear customer communication if a material issue appears.

A disciplined pre-review process does not guarantee approval; platform decisions depend on the submitted product and the rules in force at that time. It does, however, give your business a stronger basis for challenging vague contractor assurances, reducing preventable rework, and launching with ownership of the assets and decisions that matter.