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

Writing the app is most of the work, but shipping it is a separate project. Both stores have their own accounts, paperwork, testing rules and reviewers, and most first launches slip because of these steps, not the code. This guide walks through the process as it works in 2026, with notes on where founders usually get stuck.

Step 1: Set up your developer accounts

Do this first, before the app is finished. Account approval is the step you can't speed up, and it can take anywhere from a day to a few weeks.

Apple Developer Program

• Cost: $99 per year (Apple offers fee waivers to some nonprofits, schools and government entities).
• Individual vs. organization: an individual account shows your personal name as the seller. An organization account shows your company name, but you need a legal entity and a D-U-N-S number (free from Dun & Bradstreet, but it can take a week or more to issue).
• Who should own it: the business. If an agency builds your app, it should still be published under your account, with the agency added as a team member. Moving an app between accounts later is possible but tedious.
• EU distribution: Apple asks you to declare trader status under the EU Digital Services Act, and traders' contact details are shown publicly.

Google Play Console

• Cost: a $25 one-time registration fee.
• Identity verification: Google verifies your legal name and address, and organization accounts also need a D-U-N-S number. Expect a few days, sometimes longer.
• The closed-testing requirement: personal accounts created after November 2023 must run a closed test before they can publish to production. At the time of writing, that means at least 12 testers opted in for at least 14 consecutive days (Google has changed the exact number before). Organization accounts are not subject to this requirement.

Step 2: Prepare your store assets and disclosures

Both stores ask for roughly the same material. Gather it in one shared folder while development wraps up, because missing any of these blocks submission.

• App icon: 1024×1024 px for Apple (no transparency) and 512×512 px for Google Play, plus a 1024×500 feature graphic for Play.
• Screenshots: Apple wants a set for the largest iPhone display size (and iPad if you support it) and scales them down for smaller devices. Google needs at least two phone screenshots, plus tablet screenshots if you want to appear well on tablets.
• Name, subtitle and description: see the ASO section below for character limits.
• Privacy policy URL: required by both stores, for every app. It must be a live web page that matches what the app actually collects.
• Privacy disclosures: Apple's App Privacy section (the "nutrition label") and Google's Data safety form. Both ask what data you collect, why, and whether it's linked to the user or used for tracking. Your third-party SDKs (analytics, crash reporting, ads) count too.
• Account deletion: if users can create an account, both stores require a way to delete it, both inside the app and (for Google) through a web link.
• Age rating: Apple has its own questionnaire, and Google uses the IARC questionnaire. Answer honestly; mismatched ratings are a common reason for review problems.
• Support URL and contact email.

Write the privacy policy and fill in the disclosures from the same list of SDKs and data flows. If the policy says one thing and the form says another, reviewers can and do flag it.

Step 3: Build and sign your release

A store build is a signed, production-configured binary. You don't upload source code.

• iOS: archive the app in Xcode and upload it to App Store Connect, or let a cloud service do it for you. Apple handles distribution certificates and provisioning profiles, and Xcode's automatic signing covers most cases.
• Android: Google Play requires an Android App Bundle (AAB) for new apps, not an APK. You sign it with an upload key, and Play App Signing holds the actual app signing key. Back up your upload key and its password, because losing them means a support request to Google.
• React Native / Expo: we use EAS Build to produce both binaries in the cloud and EAS Submit to send them to App Store Connect and the Play Console. It removes most of the local signing headaches and makes releases repeatable.
• Version numbers: every upload needs a higher build number than the last one. Automate this early.
• Target API level: Google requires new apps and updates to target a recent Android API level, usually within about a year of the latest release. Check the current deadline before you submit.

If you're deciding how to build for both platforms in the first place, our iOS app development and Android app development pages explain how we ship one codebase to both stores.

Step 4: Test with TestFlight and Play testing tracks

Never let a store reviewer be the first person outside your team to install the release build. Both stores give you free beta distribution:

Test on real, older devices, on slow networks, and with a fresh install (no cached login). That last one catches a surprising number of crashes that reviewers would otherwise find for you.

Step 5: Submit for review

Apple reviews every build and every update, and most are reviewed within a day or two. Google's review is more automated, but first submissions from new accounts often take several days, and sometimes a week or more. Plan your launch date around the slower of the two.

The most common rejection reasons

1. Crashes and bugs (Apple guideline 2.1, App Completeness). Reviewers test on current devices and OS versions. If the app crashes on launch or a button does nothing, it's rejected.
2. No demo account. If your app requires login, give the reviewer working credentials in the review notes (Apple) or the App access section (Google). If login uses a one-time code or a special backend state, explain how to get past it.
3. Minimum functionality (Apple guideline 4.2). An app that is just a wrapped website, a single-screen utility, or a marketing brochure will likely be rejected. The app needs to do something useful that justifies being an app.
4. Spam and copycat apps (guideline 4.3). Near-duplicates of your own apps or common templates get flagged.
5. Payments outside in-app purchase (guideline 3.1.1). Digital goods and subscriptions unlocked inside the app generally must use Apple's In-App Purchase and Google Play Billing. Physical goods and real-world services (food delivery, rides, consulting) can use Stripe or similar. Recent court rulings and regulations have loosened this in the US and EU, but the details differ by country and keep changing.
6. Privacy mismatches. Requesting permissions without a clear purpose string, collecting data not declared in your privacy label, or having no account deletion option.
7. Placeholder content and broken links. Lorem ipsum, "coming soon" screens, and a dead support URL all count.

A rejection isn't a ban. You get a message citing the guideline, you can reply in App Store Connect's Resolution Center, and you can resubmit. Most rejections cost a few days, not weeks, if you respond quickly and specifically.

Step 6: Choose a release strategy

Approval doesn't have to mean instant release. Both stores let you control when and how widely the update goes out.

• Manual release: hold an approved build and press release when your marketing, backend and support are ready. Good for first launches.
• Apple phased release: automatic updates roll out to a growing share of users over seven days. You can pause it if crash reports spike. New users downloading from the store get the new version immediately either way.
• Google staged rollout: you choose the percentage (say 5%, then 20%, then 100%) and can halt the rollout if something breaks.
• Server-side feature flags: ship code dark and turn features on remotely, so a bad feature doesn't need a new store review to disable.

Remember that you can't roll back a store release. If version 1.3 is broken, the fix is version 1.3.1 and another review. Staged rollouts and feature flags are how you keep a bad release small.

Step 7: App Store Optimization (ASO) basics

ASO is SEO for app stores. You won't out-rank big brands on day one, but a few basics matter:

• Name: both stores allow 30 characters. Put your brand plus one key phrase if it reads naturally (for example "Acme: Shift Scheduling" rather than just "Acme").
• Apple subtitle (30 characters) and keyword field (100 characters, hidden): don't repeat words that are already in your name. Separate keywords with commas, no spaces.
• Google short description (80 characters) and full description (4,000 characters): Google indexes the description, so use your main terms naturally in it.
• Screenshots sell, not describe. The first two screenshots show in search results. Lead with the main benefit in a short caption, not a settings screen.
• Ratings: prompt for reviews after a success moment using the native review APIs, never right after install.
• Localize the listing for each major market, even if the app itself is English-only at first.

Apple vs. Google publishing checklist

The commission column is simplified: both stores have regional programs and exceptions. Read the current terms for the countries you plan to sell in.

How long publishing takes, realistically

In our experience, a first launch on both stores takes one to three weeks from "the app works" to "the app is live" when the accounts already exist. Add a week or more for D-U-N-S and account verification, and two weeks for Google's closed test on a new personal account. That's why we start the store setup in the first week of a project, not the last. For the full picture, see how long it takes to build an app and the app development process explained.

If you'd rather not spend those weeks learning store paperwork, our mobile app development work includes accounts, signing, beta testing, store listings and review responses. You can get a free app plan to see what your launch would involve.