How to Publish an App to the App Store and Google Play

What you need before you publish

Learning how to publish an app to the App Store starts well before you touch a single upload button. Two things gate the whole process, and if either is missing you will stall on submission day. The first is an Apple Developer Program membership, and the second is a Google Play Developer account. Both are developer registrations you pay for directly through Apple and Google, and both are required to distribute publicly. Apple charges an annual membership. Google charges a one-time registration to open a Play Console account. We do not quote figures here because they change and vary by region, but budget for both as a normal cost of doing business, and know that enrollment is quick to start and slow to finish if you leave documents until the last minute.

Enrolling as an individual is the fastest route, but most businesses should enroll as a company or organization. An organization account puts the legal entity's name on the listing instead of a person's name, which looks more credible to users and is often required if you plan to raise money or sell the app later. To enroll as an organization, Apple asks for a D-U-N-S number, which is a free business identifier issued by Dun and Bradstreet. Requesting a D-U-N-S number can take a couple of weeks on its own, so start that early. Google verifies organization accounts too, and now asks most developers to confirm identity and, for many account types, provide a verified address and phone number.

There is also a money side to accounts that is easy to forget until it blocks you. If your app will ever charge for anything, including paid downloads, subscriptions, or in-app purchases, you have to complete banking and tax forms in both consoles before a paid app can go live. Apple calls this the Paid Apps agreement plus banking and tax details, and Google asks you to set up a payments profile. A free app can skip most of this, but if there is any chance you will monetize later, fill these in early because tax verification can take days to clear and it is miserable to discover the delay on the day you planned to launch.

You also need a few practical assets ready before you begin. A privacy policy hosted at a stable public URL is not optional on either platform if your app touches any user data, and in practice almost every app does. You need a support URL or support email that a reviewer can actually reach. You need your final app icon in the exact sizes each store expects. And you need to decide who legally owns the developer account, because whoever controls that account controls your app's presence on the store. If you are working with an agency, make sure the account is registered under your company, not theirs. At mobileapplication.ca we always set up the accounts in the client's name so you keep full ownership from day one. You can read more about that principle in our guide on how to hire an app development company.

Preparing your build for release

A build that runs fine on your test phone is not automatically a build that is ready to submit. Release preparation is where a surprising number of first-time submissions go wrong, so treat it as its own stage rather than an afterthought.

Version numbers and build numbers

Both stores track two separate values. The version name (for example 1.0.0) is what users see. The build number is an internal counter that must increase with every upload. A very common first mistake is trying to upload a second build with the same build number, which both platforms reject instantly. Bump the build number every single time you upload, even for tiny fixes.

Signing your app

App signing is the cryptographic step that proves a build genuinely came from you. On iOS this happens through certificates and provisioning profiles managed in your Apple Developer account, and modern tooling can handle much of it automatically. On Android you sign the app bundle with an upload key, and Google Play then re-signs it with a key Google holds for you through Play App Signing. The single most important rule here is simple: never lose your signing keys. On Android in particular, if you opt out of Play App Signing and then lose your original key, you can lose the ability to update your own app under the same listing. Back up keys in a password manager or secure vault, and make sure more than one trusted person can reach them.

Build format

Apple takes an app archive uploaded through Xcode or a tool like Transporter. Google Play now requires the Android App Bundle (the .aab format) rather than a raw APK for new apps, and it generates optimized APKs per device from that bundle. If your team is still exporting a plain APK, switch to an app bundle before you submit.

Release configuration, not debug

Ship a release build, not a debug build. That means logging is turned down, test menus are removed, any pointing at a staging server is switched to production, and analytics keys are the live ones. Walk through the app one last time on a clean device signed into a normal account, not your developer account, to catch anything that only works because your machine is special. If you use a cross-platform framework, our comparison of how to build a mobile app covers how the release build differs from what you run in development.

Setting up App Store Connect

App Store Connect is Apple's web dashboard for everything about your iOS listing, and it is where you will spend most of your submission time on the Apple side. After your build finishes processing, the sequence looks like this.

First, create the app record. You give it a name, choose a primary language, pick a bundle ID that matches the one compiled into your build, and set an SKU, which is just an internal reference you invent. The name you enter here reserves that name on the store, so if the exact name is taken you will find out immediately.

Next, upload your build. Most teams push the archive straight from Xcode, or use Apple's Transporter app. Uploads do not appear instantly. Apple runs the binary through processing that can take anywhere from a few minutes to an hour, and only after it clears can you attach it to a version for review. Plan for that wait rather than uploading at the last minute.

Then fill in the version information. This is your description, keywords, screenshots, support URL, marketing URL, and the age rating questionnaire. Apple also requires you to complete App Privacy details, which is a structured set of questions about what data your app collects and how it is used. Answer these honestly and precisely, because a mismatch between what you declare and what the app actually does is a fast way to get rejected. If your app uses any tracking across other companies' apps and sites, you also need App Tracking Transparency in the app itself.

It is worth setting up your App Store Connect team properly at this stage. You can invite people with specific roles (Admin, App Manager, Developer, Marketing, and more) so your designer can upload screenshots without also being able to change your banking details. Getting roles right early saves you from sharing one master login, which is both a security risk and a headache when someone leaves. The same account and team also drive TestFlight, so the person managing beta testers is working in the same place you submit from.

Finally, set your pricing and availability (you can choose free, which most first apps are, and select the countries where the app should appear), attach the processed build, and answer the export compliance question about encryption. Once every required field shows a green state you can submit for review. If your app is iOS-first, our iOS app development team handles this entire flow for clients as part of a launch.

Setting up Google Play Console

Google Play Console is the equivalent dashboard for Android, and while the goal is the same, the layout and rules differ enough that you should not assume your Apple knowledge transfers one to one.

You start by creating an app, choosing default language, app or game, free or paid, and confirming a couple of declarations. Google then walks you through a set of tasks grouped under "Set up your app" and "Dashboard." These include the privacy policy link, an app access section where you tell Google how to log in if parts of the app are behind a sign-in, ads declaration, a content rating questionnaire, a target audience section, and a data safety form. The data safety form is Google's parallel to Apple's privacy questions, and just like Apple, your answers must match reality.

One Google-specific requirement catches many new developers off guard. For personal developer accounts created more recently, Google requires a period of closed testing with a minimum number of real testers over a set number of days before you can apply for production access. In practice this means you cannot always go straight from zero to a public launch on a brand new personal account, so build that testing window into your timeline. Organization accounts and established accounts have a smoother path. We cover the practical implications for Android launches in our Android app development service.

You upload your Android App Bundle to a release track (internal, closed, open, or production), review the release, and roll it out. Google's console is explicit about which tasks are still blocking your first production release, which makes it easier to see what is left.

Creating your store listing

Your store listing is your storefront, and it does more for downloads than almost anything else you control after launch. Two apps with identical features can convert visitors at very different rates purely because one has a clear listing and the other does not. Here is what each field is really for.

App name and subtitle

Your app name is limited to 30 characters on the App Store, so it has to be tight. The subtitle (Apple) or short description (Google) is your one-line pitch that appears right under the name. Say what the app does for the user in plain words, not a slogan. "Track expenses and split bills" beats "Money, reimagined."

Keywords and description

Apple gives you a separate, hidden keywords field of 100 characters that never shows to users but feeds search. Do not repeat your app name there, do not use spaces after commas (they waste characters), and do not stuff competitor brand names, which can get you rejected. Google has no separate keyword field; instead it reads your full description, so write naturally and include the phrases people would search. On both stores the description should open with the two or three lines that show before the "more" cut, because most people never tap to expand.

Localization

If your users span more than one language, both stores let you localize the listing, meaning translated names, descriptions, keywords, and even screenshots per language. A Canadian audience often means offering the listing in both English and French, and doing so widens your reach in search because each language has its own keywords. You do not have to localize on day one, but if a big part of your market speaks another language, a translated listing usually converts better than an English-only one shown to non-English speakers. Start with the languages that matter most and add more as the app grows.

Screenshots, icon, and preview video

Screenshots are the single most looked-at asset in your listing. Use captioned screenshots that show the value, not raw unlabeled screens. The first two matter most because they are visible without scrolling. Your icon needs to read clearly at small sizes, so avoid tiny text and busy detail. Both stores allow a short preview video, which can lift conversion for apps where motion explains the product, though it is optional. Listing optimization is an ongoing job, not a one-time task, and it connects directly to how you plan to grow and eventually make money from your app.

The Apple review process and timelines

Once you submit, a human reviewer at Apple checks your app against the App Store Review Guidelines. This is the step people worry about most, and it helps to know what actually happens. In our experience, most reviews complete within 24 to 48 hours, and a large share finish faster than that. It is not the multi-week wait it was years ago. That said, timelines stretch around major events, holidays, and the run-up to a new iOS release, so do not schedule a hard launch date with zero buffer.

Your app moves through a series of states you can watch in App Store Connect: Waiting for Review, In Review, and then either Pending Developer Release, Ready for Sale, or Rejected. If it is rejected, Apple attaches a message in the Resolution Center explaining which guideline you missed, often with a screenshot. You fix the issue, reply or resubmit, and you go back in the queue, though follow-up reviews are frequently faster because the reviewer already has context.

It also helps to know that not every rejection is equal. Some are metadata rejections, where the binary is fine but a screenshot, description, or privacy answer needs a change, and you can often fix those without uploading a new build at all. Others are binary rejections that require a code fix and a fresh upload. Reading the Resolution Center message carefully tells you which kind you are dealing with, and that determines whether you are looking at a ten-minute edit or another build-and-test cycle.

Two features are worth knowing. Expedited review lets you request faster handling for a genuine emergency, such as a critical bug affecting live users, but use it sparingly because it is a limited favor. And "Pending Developer Release" lets you pass review but hold the actual go-live until you press the button, which is how you line up a launch with a marketing push or a specific date. Apple publishes its full rulebook, and it is genuinely worth skimming before you submit: read the App Store Review Guidelines directly.

The Google Play review process and timelines

Google's review has historically been faster and more automated than Apple's, though that has shifted. For years an Android app could go live within hours. Today Google applies more review to new apps and new developer accounts, and first submissions on a fresh account can take several days, sometimes up to a week, while established accounts often clear much faster. The practical lesson is the same as with Apple: give yourself a buffer, especially for a first launch.

Google reviews against its Developer Program Policies rather than Apple's guidelines, and the two rulebooks do not always agree, so an app that passes one can still trip on the other. Google's process leans on automated scanning for policy and security issues, backed by human review where needed. You will see status in the console, and any rejection comes with a policy reference telling you what to fix. Google's distribution documentation is the best starting point for the Android side: see the Android distribution guide.

TestFlight and closed or open testing

Do not let the public store be the first place real people use your app. Both platforms give you proper testing channels, and skipping them is how avoidable one-star reviews happen in week one.

TestFlight on iOS

TestFlight is Apple's beta distribution tool, built into App Store Connect. You upload a build and invite testers by email or a public link. Internal testers (people on your App Store Connect team) get builds almost immediately with no review. External testers (up to a large group of invitees) get builds after a lighter beta review, which is quicker and less strict than full App Store review. TestFlight builds expire after 90 days, which nudges you to keep iterating. It is the cleanest way to gather real feedback, watch for crashes on devices you do not own, and confirm your onboarding makes sense to someone who has never seen the app. Apple documents the whole flow at TestFlight.

Testing tracks on Android

Google Play gives you a ladder of tracks: internal testing for your own small team, closed testing for a controlled group you invite, and open testing for a public beta anyone can join. As mentioned earlier, newer personal developer accounts now must run closed testing with a minimum number of testers for a set period before they can turn on production. Even when it is not mandatory, this ladder is the smart way to launch. Push to internal, then closed, then either open beta or straight to a staged production rollout once you are confident.

Whatever the platform, use this phase to test on a spread of real devices, not just the newest flagship. Cheaper Android phones with less memory and older iPhones surface problems your dev devices hide.

Give your testers a short, specific script rather than a vague "try the app." Ask them to complete the one or two journeys that matter most, sign up, make a booking, send a message, whatever your core loop is, and to report anything confusing, not just anything broken. Confusion is feedback too, and it is the kind you can only get from someone seeing the app fresh. Watch for the moments where a tester hesitates, because those hesitations become drop-offs at scale. A week of honest beta testing with ten to twenty engaged people will teach you more than a month of guessing, and it costs you nothing but the time to organize it.

Common reasons apps get rejected

Rejections feel personal the first time, but they follow predictable patterns. Knowing the usual causes lets you clear them before a reviewer ever sees them. Here are the ones we run into most often across submissions.

• Crashes and obvious bugs. The fastest rejection of all. If the app crashes on launch or a core feature does not work on the reviewer's device, it is done. Test on a clean device with a fresh account.
• Incomplete information. A reviewer cannot get past your login, a demo account is missing or wrong, or a feature needs hardware or a backend that is not available to them. Always provide working demo credentials and clear notes in the review information field.
• Privacy problems. A missing privacy policy, a privacy declaration that does not match what the app actually collects, or asking for a permission you never use. Apple and Google both take this seriously.
• Broken or placeholder links. Support URLs that 404, "lorem ipsum" left in the description, buttons that lead nowhere. Small, avoidable, and common.
• Payment and purchase rules. Selling digital goods or subscriptions through your own payment flow instead of the platform's in-app purchase system, where the rules require it, is a frequent and costly rejection. The rules here are specific, so read them for your case.
• Misleading metadata. Screenshots that show features the app does not have, a description that overpromises, or keyword stuffing with competitor names.
• Thin or low-value apps. Apple in particular rejects apps that feel like a repackaged website or offer very little beyond what a mobile browser already does. Give the app a real reason to exist as an app.
• Design and usability issues. Apple can reject an app that looks unfinished, has broken layouts on certain screen sizes, or ignores basic platform conventions. A build that technically works but feels rough can still be bounced, so polish the parts a reviewer sees first.
• Requesting sign-in for no reason. Forcing account creation before the user gets any value, or requiring personal details the app does not need, draws rejections. Where possible, let people use core features first and offer Sign in with Apple if you offer other social logins.

When you do get rejected, read the exact guideline number they cite, fix that specific thing, and reply in the Resolution Center or the console with a short note on what you changed. Arguing rarely helps; a clean fix and a calm reply almost always does. If you disagree on principle, both platforms have an appeal path, but use it only when you are genuinely sure the reviewer misread your app.

Launching with a phased rollout

Passing review does not mean you have to flip the switch for every user at once, and usually you should not. Both stores let you release gradually so that if something is badly wrong, only a small slice of users hits it before you can pull back.

On the App Store, Phased Release rolls a new version out to a growing percentage of users over about seven days, and you can pause it at any point. Note that phased release applies to updates, so your very first version goes out fully, but every update afterward can be staged. On Google Play, Staged Rollout lets you pick the exact percentage of users who receive the release, including the first one, and you can increase the percentage as your confidence grows or halt the rollout if crash rates spike.

The reason to bother is simple. Real users on real devices find issues your testing missed, and a staged rollout turns a potential all-users incident into a contained blip you can fix before most people ever notice. Watch your crash-free rate and your early reviews during the first day or two at a low percentage, and only widen the rollout once the numbers hold. For a first launch where you want a big splash on a set date, combine a held release (Pending Developer Release or managed publishing) with a staged rollout so you control both the timing and the blast radius.

What to do right after launch

The work does not stop when the listing goes live. The first days and weeks after launch are when you learn what your app is really like in the wild, and how you respond sets the trajectory. Here is where to put your attention.

Watch crashes and stability

Wire up crash reporting before launch, not after, and check it obsessively for the first week. App Store Connect and Play Console both surface crash and stability metrics, and a dedicated crash tool gives you stack traces. A crash-free rate that dips is your signal to pause a staged rollout and ship a fix.

Read and reply to reviews

Early reviews shape your rating for a long time because you have so few of them, so each one carries weight. Reply to reviews, especially the critical ones, because both users and future readers see that you respond. A calm, specific reply to a one-star review often turns it around, and it signals to everyone else that a real team stands behind the app. Prompt users to review at a good moment (after a win in the app, not on first launch) using the platform's built-in review prompt.

Keep improving the listing (app store optimization)

Your first listing is a starting point, not a final answer. App store listing optimization is the ongoing practice of testing different screenshots, subtitles, and keywords to see what pulls more installs from the same traffic. Google Play offers built-in store listing experiments that let you compare variants with real users, and on both stores you can revise metadata with each update. Small changes to the first screenshot or the opening line of the description can move your conversion rate more than a new feature would. Treat the listing as a living asset you revisit every few weeks, especially while you are still learning what resonates.

Track the numbers that matter

Look at installs, but look harder at retention, the percentage of people who come back the next day and the next week. Downloads feel good; retention pays the bills. Watch where people drop off in onboarding and fix the worst step first.

Plan your first update

Ship a small update within the first couple of weeks even if nothing is broken. It tells users and the stores that the app is alive and maintained, and it lets you act on the first real feedback while momentum is high. From there, settle into a steady release rhythm. If you are thinking about how launch feeds into revenue and growth over time, our guide on how to make money from an app picks up right where this one ends, and our pricing page explains how we structure ongoing support.

Pre-submission checklist

Run through this before you hit submit on either store. If every line is true, you are in good shape.

• Developer accounts are active and registered in your company's name, not an agency's.
• A privacy policy is live at a stable public URL, and it matches what the app actually collects.
• Apple App Privacy details and Google Data safety form are both completed and accurate.
• Build number is bumped, the build is a release configuration pointing at production, and it is signed correctly.
• Android build is an App Bundle (.aab), not a raw APK.
• Signing keys are backed up where more than one trusted person can reach them.
• App name, subtitle or short description, and description are final, with no placeholder text.
• Screenshots for every required device size are captioned and current, and the icon reads well when small.
• Support URL and marketing URL resolve and are not broken.
• Working demo credentials and clear reviewer notes are in the review information field.
• Age rating and content rating questionnaires are done on both platforms.
• Export compliance (encryption) question is answered.
• Crash reporting is wired up and confirmed working in a test build.
• You have tested on a clean device with a normal account, and on a spread of real devices, not just the newest one.
• You have decided between an immediate release, a held release, and a staged or phased rollout.

Publishing an app is mostly a game of preparation. The teams that sail through are not lucky; they are the ones who filled in every field honestly, tested on real hardware, and treated the store guidelines as a checklist rather than a surprise. Do that and the review process becomes a formality. If you would rather have an experienced team carry your app across the finish line, from account setup to a clean first-try approval, that is exactly what we do every week. Tell us about your app on our contact page and we will map out your launch.