Mobile apps

How to publish an app on the App Store and Google Play: steps, timing and rejections

How to publish an app on the App Store and Google Play: accounts, materials to prepare, testing, review, reasons for rejection and what to do after launch.

Fabio Folgori6 min read

Table covered with many vintage postage stamps
Photo by Ilnur on Unsplash

When the app works on the developer's phone, it feels like you are almost at the end. In reality a step is missing that is often underestimated: publication. The App Store (Apple) and Google Play have their own rules, checks and timing, and arriving unprepared means losing weeks.

In this guide I explain how the path works, what to prepare in advance and the most common reasons for rejection.

First of all: developer accounts

To publish you need an account for each store.

  • Apple: you join the Apple developer programme, which has an annual fee. If you publish on behalf of a company you need verifiable company details.
  • Google Play: you open a developer account on Google Play Console, with a registration fee. Here too there are checks for organisations; for some accounts Google requires a testing period before publication.

In whose name? It is the most important decision, and it is best taken right away. The account should be in the name of the app's owner, that is the client or the company, not the developer. If the app is on the account of whoever wrote it, moving it later is complicated.

What to prepare before publication

Besides the app, the stores ask for many materials. Preparing them in time avoids delays.

  • Name and description, short and long, clear and without exaggerated promises.
  • Icon in the required sizes.
  • Screenshots of the app, for the different phone formats.
  • Category and keywords.
  • Web address for the privacy policy, mandatory.
  • Statements about the data collected: each store asks you to say which data the app handles and how it uses it.
  • Content rating (age bracket).
  • Support contact and, if needed, an app website.
  • A test account, if the app has restricted access, so the reviewer can get in.

The technical steps

The path differs a little between iOS and Android, but in general it is this.

  1. Preparing the build: the production version of the app is created, with the digital signatures the store requires.
  2. Internal testing: the version is tried on real devices. Apple offers a testing service for collaborators; Google Play allows internal and closed testing tracks.
  3. Testing with a small group: a few outside people try the app before publication.
  4. Submission for review: the build is uploaded and the store listings are filled in.
  5. Review: the store checks the app and the listing.
  6. Publication: if everything is in order, the app goes live at once or on a chosen date.

The review: what the stores check

Each store verifies that the app respects its guidelines. Among the main points:

  • functioning: the app must not crash or have broken links or screens;
  • content: no deceptive or offensive material, nothing that violates others' rights;
  • privacy: statements consistent with what the app really does;
  • payments: precise rules on how to sell digital content and services inside the app;
  • minimum quality: an app that is just a framed website, with no added value, risks being turned down.

The most common reasons for rejection

No need to be frightened: rejections happen, especially at first publication.

  • Crashes or errors during review.
  • No test account for restricted areas.
  • Missing or incomplete privacy policy, or inconsistent data statements.
  • Features described but not present in the listing.
  • Use of payment systems not allowed for digital goods.
  • Permissions requested without a clear explanation (location, camera, notifications).
  • Confusing metadata: name, description or screenshots that do not match the app.

When it happens, the store states the reason: usually you fix the point flagged and submit again.

How long it takes

There is no guaranteed time. Review can last from a few hours to several days, and a rejection adds another round. So it is worth:

  • not setting rigid launch dates without a margin;
  • submitting in time, especially if there is a campaign or event attached;
  • keeping materials ready to fix things quickly.

After publication

Publication is the start of the work, not the end.

  • Mandatory updates: Apple and Google periodically ask for the app to be adapted to recent versions of their systems and rules, on pain of losing visibility or removal.
  • Reviews and ratings: they need to be read and, when appropriate, answered.
  • Monitoring of errors and crashes, to step in early.
  • New versions with fixes and features, following real use.

If you are not yet sure you need an app present in the stores, first read Native app, web app or PWA: which to choose.

The mistakes that waste time

  • Opening the account in the developer's name instead of the owner's.
  • Leaving publication for last, without planning the materials and tests.
  • Forgetting the privacy policy or writing it generically.
  • Not trying the app on different real devices.
  • Not planning for future updates and their cost.

A checklist before submitting

Before pressing the button, answer these questions.

  • Is the account in the name of the app's owner?
  • Are name, description, icon and screenshots ready and do they match the app?
  • Is the privacy policy online and are the data statements consistent?
  • Do I have a test account for the reviewer, if the app has restricted access?
  • Have I tried the app on real devices, with different system versions?
  • Does every permission requested have a clear explanation for the user?
  • Are the features described in the listing really there?
  • Have I planned what to do in case of rejection, and how many days of margin do I have?

Why entrust it to me

I have been programming since 1999, with more than 300 projects delivered and about 30 agencies as an external developer. I build apps for iOS and Android and also handle publication and updates over time: Apple and Google change rules and systems every year, and I keep the app compatible, secure and published, so you do not have to worry about it. I work from Rome and remotely.

If you have an app in the works or an idea to take to the stores, write to me: a chat of about 20 minutes, no strings attached, then a written, free proposal. The service is in iOS and Android app development.

Frequently asked questions

It depends on the store, the app and the period: review can take from a few hours to several days. It is best not to set rigid launch dates and to leave a margin, also for a possible rejection to fix.

Yes: a developer account for each store, with its own rules and costs (an annual fee for Apple, a registration fee for Google). To publish as a company you need verifiable company details.

Better under the client's or the owning company's name, with an account in their name: that way the app stays theirs even if the developer changes. It is a choice to make before starting.

The store explains the reason. Usually you fix the point indicated and submit again. Rejections are common, especially at first publication, and almost always solvable.

  • #publish app
  • #app store
  • #google play
  • #app review
  • #mobile app

More articles

Shall we talk about your project?

A 20-minute chat, no strings attached: we'll figure out together where to start.