How to publish an app on the App Store and Google Play

Accounts: what to set up, and in whose name

The App Store requires the Apple Developer Program: $99 a year, renewed annually. Miss the renewal and the app disappears from the store. Google Play requires a Play Console account with a one-time $25 fee.

Register the accounts under your company or the product owner, never the contractor. It sounds obvious, but losing access to a developer account when the team changes is one of the most common and most painful stories — reviews, installs and the ability to ship updates all go with it.

For a company account Apple will ask for a D-U-N-S number. Getting one is free but takes time, so start there rather than a week before launch.

Give contractors access by inviting them to the team, not by sharing the owner's login. That way access can be revoked without changing anything else.

Checklist before your first submission

Collect all of this in advance, or submission turns into several attempts:

• A signed production build and a unique app identifier.
• An icon and screenshots in the required sizes, plus preview video if you want one.
• Name, short and full description, keywords.
• A publicly reachable privacy policy link and a working support contact.
• Completed data forms: App Privacy for the App Store, Data safety for Google Play.
• Age rating and the content questionnaire.
• A test account for the reviewer if the app has a login.

The data forms must match what the app actually does. A mismatch between declared and real data collection is a rejection reason in itself, and an easy one to spot.

How review works

Apple reviews apps by hand. In practice that usually means a few hours to a couple of days, with no guarantee, and queues grow before holidays. A reviewer opens the app on a device and walks the main flows, so a test account and clear notes in the submission speed things up noticeably.

Google uses a mix of automated and manual checks. Note the extra requirement for new personal developer accounts: before a public release you must run closed testing with a group of testers for a set period. The requirements change periodically, so check current Play Console documentation.

The most common reasons for rejection

Most rejections fall under a handful of App Store Review Guidelines:

• 2.1 The app crashes, contains placeholders or unfinished screens. The most common reason, and the most avoidable.
• 4.2 Minimum functionality: the app looks like a wrapper around a website and offers nothing a browser does not. The main risk for WebView apps.
• 3.1.1 Selling digital content outside in-app purchase. A link to your own checkout inside the app is the classic mistake.
• 5.1.1 Collecting data without need or explanation, and missing account deletion in apps that support sign-up.
• 2.3 Description and screenshots that do not match what the app actually does.
• 1.x User-generated content with no moderation or reporting mechanism.

What to do when you are rejected

A rejection is a conversation, not a verdict. The Resolution Center gives you a specific guideline number and usually a screenshot. Read the wording literally — more often than not the reviewer means exactly what they wrote.

If you disagree, reply with an explanation instead of just rebuilding and resubmitting. Apple also has an appeals process if you believe the decision is wrong. Arguing aggressively gets nowhere, but a reasoned explanation often works.

Plan for one or two rounds of fixes. Scheduling a launch for the day you submit is a reliable way to miss your marketing dates.

After release

Publishing is not the finish line. The app has to be updated for new iOS and Android versions or it starts breaking on recent devices. Apple and Google periodically raise the minimum SDK version, and builds that fall behind stop being accepted.

Set up crash reporting before release, not after the first complaints. And watch store reviews: it is the one channel where a user reports a problem publicly and affects your installs at the same time.