Publishing an app on the App Store and Google Play: steps and review times

Publishing an app on the App Store and Google Play requires, before any submission, a developer account with each of the two platforms, a store listing, privacy declarations and a build that meets their technical requirements for the year. Apple then reviews each version, most of them in under 48 hours; Google may take up to seven days, longer in some cases. This guide explains in whose name to open the accounts, what to prepare, the 2026 requirements and the most common rejection reasons.

It is written for managing directors and CIOs who are having a mobile app developed and want to know what happens between the end of development and going live. The technical submission is the development team’s job; the decisions described here belong to the company.

What are the steps to publish an app?

Publishing a mobile app takes six steps, the same at Apple and Google: open the account, register the app, fill in its listing and declarations, upload a build, test it, then submit it for review.

• Open the developer account. The Apple Developer Program for the App Store, the Google Play Console for Android. Allow for identity or company verification in the schedule.
• Register the app. Its name and its technical identifier (the Bundle ID at Apple, the package name at Google), which can no longer change once a build has been uploaded.
• Fill in the listing and declarations. Description, screenshots, category, age rating, privacy policy, data collected.
• Upload a build. The compiled and signed app, compliant with the technical requirements in force.
• Test. TestFlight at Apple; internal, closed and open testing at Google, with closed testing mandatory for some accounts.
• Submit for review, then publish. Once the version is approved, it can be released immediately or at a chosen time.

Which developer account should you open, and in whose name?

The developer account for a company app is opened in the company’s name, as an organisation account, not in the name of the provider or an employee. At Apple, the organisation’s name is shown as the seller on the App Store, whereas an individual account shows the person’s name.

An app published from a provider’s account can be transferred, but it is a heavy operation. At Apple, the Account Holder of the transferring account initiates the transfer and the receiving Account Holder accepts it; the app keeps its reviews, ratings and Bundle ID. At Google, the transfer is requested from the original account, approved by the target account and reviewed by support; some reports do not follow the app, and linked services such as Firebase must be reconfigured.

What do you need to prepare before submitting an app?

Before submitting an app, you need to prepare its listing, its privacy declarations and what the reviewer needs to test it: most rejections come from a missing item, not from the code.

• A privacy policy. A public URL, required by both platforms, including at Google for an app that collects nothing.
• The declaration of data collected. The App Privacy details at Apple, the Data safety section at Google. They also cover embedded third-party SDKs (analytics, advertising, payment): ask your development team for the list.
• Account deletion. If the app lets users create an account, it must let them delete it from within the app (Apple guideline 5.1.1(v)); Google also requires a web link, declared in the Data safety section.
• A demo account. If the app requires a login, the reviewer must receive a working account, and the back end must stay live during review (Apple guideline 2.1).
• An accurate listing. Screenshots that show the app as it is (Apple guideline 2.3), a description, a category and the age rating questionnaire.
• Closed testing at Google, for the personal accounts concerned: twelve testers opted in continuously for fourteen days, to be recruited before the target launch date.

Which technical requirements apply in 2026?

In 2026, Apple requires apps to be built with Xcode 26 and Google requires every new app or update to target Android 16. These thresholds rise every year: an app that does not keep up can no longer be updated, and at Google it is no longer offered to some new users.

These mandatory updates belong in the app’s budget, just like bug fixes. Our guide to the application maintenance contract explains how to include them.

How long do Apple and Google reviews take?

Apple states that it reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours. Google warns that review can take up to seven days, or longer in exceptional cases, for some developer accounts and apps subject to extended review.

These are the times announced by the platforms, with no commitment: a rejection starts a full cycle again. Apple accepts requests for an expedited review to fix a critical bug or for an app tied to a dated event. At Google, the fourteen-day closed test, when it applies, comes before the very first production submission.

Why are apps rejected?

An app is most often rejected because it is incomplete or poorly described, more rarely because of its code. Apple’s public review guidelines describe the following cases.

• An incomplete app (2.1). Crashes, broken links, placeholder content, a missing demo account or a back end offline during review.
• Misleading metadata (2.3). Screenshots or a description that do not match the app.
• A repackaged website (4.2). An app must offer more than a website wrapped in a mobile shell.
• Duplicate apps (4.3). Several near-identical variants of the same app.
• Privacy (5.1.1). A missing policy, permission request texts (location, camera, contacts) that do not say what access is for, missing account deletion.
• A regulated service submitted by the wrong account. A banking or health app must be published by the entity providing the service, not by its provider.

Frequently asked questions

What happens after publication?

After publication, every update goes through review again, and both platforms raise their requirements every year: a mobile app is maintained, like a service. The choice of technology matters too: our comparison of Flutter, .NET MAUI and React Native helps make it, and the specification remains the starting point.

The iones team develops iOS and Android apps nearshore from Tunisia, for French and European companies, publishes them on its clients’ accounts and maintains them over time. You can write to us for an initial discussion.