What happens when you publish an app to the app stores

The app store submission process has five parts: setting up the developer accounts, preparing the store listing and privacy details, passing each store's review, avoiding the common reasons apps are rejected, and releasing updates after launch. Knowing what each store expects before you start saves days of back-and-forth and makes launch dates more realistic.

Apple's App Store and Google Play are the two main stores for mobile apps. Each has its own accounts, tools and policies. This guide explains what to prepare, based on each store's official documentation. If you are planning an app, our mobile app service page explains how we work.

Developer accounts you need

You need an account with each store you plan to publish on.

A checklist before you register

• Register the accounts in your business's name, not a developer's.
• Decide who in your business will be the account holder.
• Prepare business details, such as registration documents, that each store may request during verification.
• Give your developer access to the accounts, rather than letting them publish from their own.

A common mistake and its fix

A common mistake is letting the developer publish the app under their own account "to save time". Moving an app to another account later can be slow and complicated. The fix is to create your own accounts first and add the developer as a user.

If store accounts and review are a barrier, our comparison of progressive web apps and native apps explains an option that skips the stores.

App store submission process: listings, screenshots and privacy details

Each store shows a listing page for your app, and each asks for details about how the app handles data.

What to prepare

1. App name, short description and full description, written for your customers.
2. Screenshots for the device sizes each store requires, showing the app's real screens.
3. An app icon in the required formats.
4. A privacy policy available at a public web address.
5. Support contact details, such as a website and email address.
6. Privacy disclosures. Apple requires App Privacy Details in App Store Connect, including the data practices of third-party code integrated into the app. Google Play requires every published app to complete the Data safety form, even apps that do not collect user data.

A worked example

A booking app uses an analytics tool and a crash reporting tool. When completing the privacy disclosures, the business must include what those tools collect, not only the data its own code collects. Listing only the booking details would leave the disclosure incomplete.

The review process

Both stores review apps before they appear to the public. Apple's App Review Guidelines are grouped into sections covering safety, performance, business, design and legal requirements.

Apple's guidelines list steps to take before submitting, including:

1. Test your app for crashes and bugs.
2. Make sure all app information and metadata is complete and accurate.
3. Give the reviewer full access, such as an active demo account or a fully featured demo mode if the app requires login.
4. Make sure backend services are live and accessible during review.

Google Play also reviews apps and updates against its policies. Its testing tracks let you release to internal, closed or open groups of testers before full publication, which helps you find problems before review and launch.

Questions to answer before submitting

1. Can a reviewer who has never seen the app complete its main tasks?
2. Does every link, including privacy and support pages, work?
3. Do the screenshots and description match what the app actually does?
4. Is the backend live, with test data a reviewer can use?

Common reasons apps are rejected

Many rejections are avoidable. These problems come up often:

If an app is rejected, read the reviewer's message carefully, fix the specific issue and reply or resubmit with a clear explanation of what changed.

Releasing updates after launch

Launch is the start of the app's life in the stores.

1. Plan regular updates for bug fixes, new operating system versions and store policy changes.
2. Test each update with a small group first, using the stores' testing tools.
3. Update privacy disclosures whenever data practices change, such as adding a new analytics tool.
4. Write clear release notes so users know what changed.
5. Watch crash reports and reviews after each release, and be ready to fix problems quickly.
6. Keep backend changes compatible with older app versions that some users will still have installed.

A common mistake and its fix

A common mistake is changing the backend and the app together, assuming everyone updates at once. Users who have not updated suddenly see errors, because their older app sends requests the new backend no longer accepts. The fix is to keep the backend working with older app versions for a period, and to prompt users to update only when the old version truly cannot be supported.

Our guides on how to plan the first version of a mobile app, what it costs to build a mobile app and what to prepare before hiring a mobile app developer cover the stages before submission.

Whether you maintain one codebase or two affects how updates are released, as our comparison of native and cross-platform apps explains.

Summary

• Register Apple and Google developer accounts in your business's name and add your developer as a user.
• Prepare listings, screenshots, a privacy policy and each store's privacy disclosures, including third-party tools.
• Follow Apple's pre-submission steps: test thoroughly, complete metadata, give reviewers access and keep the backend live.
• Avoid common rejections such as crashes, login problems, inaccurate metadata and missing privacy details.
• Plan updates, keep disclosures current and keep the backend compatible with older app versions.

Preparing properly turns app store submission into a predictable step rather than a delay. If you're preparing to publish an app, you can tell us about it here.