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

To publish an app to the App Store and Google Play you don’t press one “upload” button. You go through a chain: developer accounts, signed builds, a store listing, data disclosure forms, review, and then a steady stream of updates. No single link is hard, but a missing one costs days of waiting.

Here is the order it happens in, and where people usually trip.

Developer accounts

You need two: the Apple Developer Program and the Google Play Console. The first decision is who owns them — a person or a company. That decides whose name appears under your app, and transferring ownership later is more work than it sounds.

For a company, Apple asks for an organisation identifier and proof that you can act on its behalf. Google verifies identity and, for new personal accounts, requires a closed test with a group of real testers before it opens production. Plan for weeks, not days.

One more rule: register the accounts on a company email, not a contractor’s personal inbox. Whoever controls the account effectively owns the app.

Signing and builds

Stores only accept signed builds. The signature proves that an update came from the same author as the first version.

• iOS. A developer certificate, an app identifier (bundle ID) and a provisioning profile tying them together. Xcode can manage this automatically, and that’s fine to start with.
• Android. An upload key you sign the .aab file with, and an app signing key that Google keeps (Play App Signing). A lost upload key can be reset through support, but you’d rather not find out how long that takes.

Keep keys and their passwords in the team’s secret manager, not in the repo and not on one person’s laptop. Choose the app identifier (com.company.app) once: it cannot change after release.

Test builds before you submit

Before sending anything to review, put the build in front of real people: TestFlight on iOS, internal or closed testing in the Play Console on Android. These are the same pipes that will later deliver your updates, so you test the process as well as the app.

Use real devices, including an old, cheap Android phone. An emulator won’t show you how the app behaves offline, with large system fonts, or when it comes back from the background.

The store listing

This is a landing page you get one shot at. You’ll need:

• a name and short description that don’t promise things the app doesn’t do;
• screenshots in the required sizes for phones (and tablets, if you support them);
• an icon, a privacy policy URL and a support contact;
• an age rating, which comes from a questionnaire — answer it honestly.

Then the data forms: “App Privacy” on Apple and “Data safety” on Google. You list what data the app and every SDK inside it collects. Analytics and ad SDKs count. A mismatch between the form and the app’s real behaviour is a common reason for rejection.

Review and common rejection reasons

Apple reviews every build by hand. Google relies mostly on automated checks with some manual review. Rejections tend to repeat:

• the app crashes or hangs on the first screen;
• the reviewer can’t log in — put a test account in the review notes;
• placeholders, lorem ipsum, buttons that do nothing;
• the app is just a website in a wrapper with no value of its own;
• digital goods are sold outside the in-app purchase system;
• users can sign up but can’t delete their account from inside the app.

A rejection isn’t a ban. You get a reason, you fix it and resubmit, or you reply in the same thread if you think the reviewer got it wrong.

Updating after you publish to the App Store and Google Play

The first release is the start, not the finish. The version and build number must go up with every upload — the store won’t accept a build number it has already seen.

Roll out gradually: both stores can ship an update to a percentage of users first. If crashes go up, you pause the rollout. You can’t roll back an app on a phone that already updated, so your backend has to keep serving older app versions for a while. It also helps to build an “update required” screen early, for versions you can no longer support.

In short

• Register developer accounts to the company and its email; verification takes time.
• Signing keys and the app identifier are forever — treat them as secrets.
• Test through TestFlight and closed testing on real devices.
• Data disclosure forms must match what the app and its SDKs actually do.
• Roll out updates gradually: you can’t roll back a version on a user’s phone.

If you’d rather not learn this path on your own product, SUBXCAT can walk through the release with you.