How to Publish an App to the App Store (and Google Play) in 2026

Finishing the code is not the same as shipping. Between a working build and a live listing sits a chain of accounts, certificates, questionnaires, and a human reviewer who can send you back to the start.

None of it is hard. All of it is fiddly, and the order matters, because a few steps have waiting periods you cannot compress. This is the full path for both stores, written from the perspective of someone doing it for the first time.

Step 1: Enroll in the developer programs

You need an account with each store before anything else. Start here, because Apple’s enrollment can take days.

Apple Developer Program: $99 per year. Renewable, and if it lapses your apps come off the store. Enroll at developer.apple.com. As an individual you can sign up with your Apple ID and a photo ID. As a company you need a D-U-N-S number, which is free from Dun & Bradstreet but can take one to two weeks to issue if you do not already have one. Apple then verifies your legal entity and your authority to bind it, sometimes with a phone call.

Enroll as the entity that should own the app. Migrating an app from a personal account to a company account later is possible but tedious, and if a contractor enrolled on your behalf you may find you do not control it at all.

Google Play Console: $25, one time. Faster to set up, but Google now requires identity verification with a government ID and, for personal accounts created after 2023, verified contact details that appear publicly on your listing. Individual accounts also face a testing requirement, covered below.

Step 2: Create app IDs and set up signing

Both platforms cryptographically sign your app so the store and the device can verify it came from you.

On the Apple side you register a bundle identifier (reverse domain style, like com.yourcompany.yourapp) in the developer portal. Pick carefully. The bundle ID is permanent once an app is published under it, and it is how push notifications, in-app purchases, and iCloud containers are wired up. Then you generate a distribution certificate and a provisioning profile. Xcode’s automatic signing handles most of this if you let it, and modern CI setups use App Store Connect API keys instead of certificates on a laptop.

On the Android side you have an application ID in the same format, plus an upload key. Google Play App Signing is now the default: you sign with an upload key, Google re-signs with the app signing key it holds. This is a good thing, because losing your upload key is recoverable while losing a legacy app signing key is not.

Two rules worth writing down. Back up your keystore and its password somewhere you will still have access to in three years. And make sure the developer accounts are in your name, not your agency’s.

Step 3: Write and host a privacy policy

Both stores require a publicly reachable privacy policy URL before you can submit. Not a PDF, not a page behind a login. A live URL.

It has to actually describe what your app collects, why, who you share it with, and how a user requests deletion. If your app has any account system, Apple also requires an in-app path for users to delete their account, and the reviewer will look for it.

You can draft this yourself with a free app privacy policy generator, which asks what your app collects and produces a policy you can host immediately. Read the output before you publish it. If it says you do not collect analytics and you ship Firebase Analytics, that is a mismatch waiting to be flagged.

Step 4: Fill out the privacy questionnaires

This is separate from the policy and it trips people up.

Apple’s App Privacy section in App Store Connect asks you to declare every data type you collect, whether it is linked to the user’s identity, and whether it is used for tracking. Your answers become the “privacy nutrition label” on your listing. If you use any third-party SDK, you inherit its collection behavior and must declare it. Apple also now requires a privacy manifest file from apps and from many common SDKs, plus a stated reason for using certain APIs like file timestamps or user defaults.

Google’s equivalent is the Data safety form in Play Console, with similar questions and its own definitions. The two forms do not map cleanly onto each other, so fill each one against the store’s own definitions rather than copying answers across.

Under-declaring is a rejection. Over-declaring hurts your conversion rate. Take the time to get it accurate.

Step 5: Build your store listing

The listing is your entire sales page, and it is worth more effort than most first-time publishers give it.

You will need:

• App name, 30 characters on iOS. Short, spellable, searchable. A name generator helps if you are still deciding.
• Subtitle (iOS, 30 chars) and short description (Android, 80 chars). These are indexed for search.
• Full description, up to 4000 characters on both.
• Keywords field, iOS only, 100 characters, comma separated, no spaces. Do not repeat words already in your title.
• App icon, 1024x1024 PNG with no transparency and no rounded corners baked in.
• Screenshots for the required device sizes. Apple currently requires at least one 6.9-inch iPhone set; iPad screenshots are required only if you support iPad. Android needs a phone set plus a 1024x500 feature graphic.

Screenshots drive conversion more than anything else on the page. The first two are what people see without scrolling, so lead with your strongest benefit rather than a login screen. A screenshot generator will frame your raw captures in device mockups at the exact required dimensions. If you need a scannable link to your listing for print or in-store signage, generate one with the QR code generator once the app is live.

Step 6: Test before you submit

Upload your build to TestFlight on iOS. Internal testers (up to 100 people on your team) get builds immediately with no review. External testers (up to 10,000) require a light review pass, usually under a day. Use TestFlight even if your only tester is you, because it surfaces packaging problems that never appear when running from Xcode.

On Android, use internal testing in Play Console for instant distribution to up to 100 testers, then closed and open testing tracks as you widen. Important: personal Google Play developer accounts created after November 2023 must run a closed test with at least 12 testers who stay opted in for 14 continuous days before they can apply for production access. Organization accounts are exempt. Plan around this, because it is a hard two-week gate that people discover at the worst moment.

Step 7: Submit and wait

Apple’s review is typically 24 to 48 hours, and the great majority of submissions are reviewed within a day. It can stretch during December and around major OS launches. Google Play review used to be near-instant; expect a few hours to a few days now, with new accounts and first submissions on the longer end.

Both stores let you set a release to go live automatically on approval, or hold it for manual release. Manual is usually better for a first launch so you control the date.

The rejections you are most likely to hit

Most first-time rejections come from the same short list.

• Guideline 2.1, incomplete information. Reviewers could not get in. If your app requires login, provide a working demo account in App Store Connect’s review notes, and make sure it stays working. Include steps for anything non-obvious.
• Broken links or a dead privacy policy URL. Check every URL in your listing right before submitting.
• Crashes on the reviewer’s device. They test on current hardware and often on beta OS versions. Test on a real device, not only the simulator.
• Payments outside in-app purchase. If you sell digital content or features, Apple requires IAP. Linking out to your own web checkout for digital goods is a rejection.
• Sign in with Apple missing. If you offer Google, Facebook, or other third-party login, you must offer Sign in with Apple too.
• No account deletion path. Required in-app if you allow account creation.
• Placeholder content. Lorem ipsum, test data, or “coming soon” screens.
• Data safety mismatch on Android. Your declared collection does not match what Google’s scanners observe from your SDKs.

A rejection is not a black mark. You fix the issue, reply in Resolution Center, and resubmit, usually into the same fast queue. Arguing rarely works; asking a clarifying question about what specifically failed usually does.

If you would rather not do any of this

Submission is genuinely a distinct skill from building, and it is the part where an experienced hand saves the most time. We handle accounts, signing, listings, questionnaires, and review responses as part of every build, and you own the accounts at the end. See how it works, what we have shipped in the portfolio, and our fixed pricing. If you are still scoping, the app brief wizard is a good place to start.

---

Your app. In the stores. Done for you. US APP Team designs, builds, and launches your iOS and Android app for a fixed price. Start your app brief or book a free intro call — both are free.

Want to poke around first? Every tool in our free tool library runs in your browser with no signup: an app cost calculator, an app name generator, a privacy policy generator, and more.