Publishing your app to the App Store and Play Store

Your app is finished, it runs fine on your phone, and you think one button will put it live. Bad news: between a working build and a published app sits a series of steps nobody explains clearly. The good news is you can clear all of them in an afternoon, once you know what to prepare.

We assume your developer accounts already exist: the Apple Developer Program (99 dollars per year) on Apple's side, and the Google Play Console (25 dollars, one time) on Google's. If not, create them first, since Apple identity verification can take several days. Here, we tackle the next part: getting from code to store.

Before you even touch the stores, confirm your app is truly ready: no crash on launch, a privacy policy hosted online, and screens that hold up on a real device. If you are still unsure how your product was built, we wrote a guide on no-code versus custom for a first product.

With Apple, everything runs through App Store Connect, the web dashboard that manages your apps. The principle: you upload a build from Xcode, fill in the listing, then submit for review. Here is the sequence in order.

Once submitted, your app moves to Waiting for Review, then In Review. Expect 24 to 48 hours for a first verdict in most cases. If all is well, the app becomes Ready for Sale and ships per your chosen option. Otherwise, Apple explains the reason in the Resolution Center, and you fix it before resubmitting.

Google is more lenient than Apple on review, but now requires a testing phase before a new account can push an app to production. Everything is driven from the Google Play Console. Here is how it goes.

Google's review is largely automated and often takes from a few hours to a few days. Once approved, your app is available worldwide (or in the countries you selected). To equip this whole publishing cycle, take a look at our pick of tools that save a founder time.

This is where founders get stuck most often. Apple enforces its App Store Review Guidelines strictly, and a first rejection is almost a rite of passage. A rejection is not a disaster: you fix it and resubmit. But each round trip costs a day or two. Better to dodge the most common traps.

The most frequent reason is still the plain incomplete app: Apple opens your app, hits a bug or a login screen with no test account, and rejects. Always provide a demo account in the review notes if your app requires a login. It is the overlooked detail that blocks thousands of submissions.

“An Apple rejection is not a failure. It is a free checklist to make your app better before a real user ever sees it.”

Before you hit Submit, run through this list. Five minutes here saves you several days of rejections. It works for both stores, adapting the terms.

One last thing: keep your credentials, certificates and keys in a safe place shared with your team. Publishing once is simple, but shipping an update six months later without the right key is a nightmare. To structure all of this cleanly from the start, read our story on how we turned a side-project into a real SaaS.

Publishing to the App Store and the Play Store is not magic. It is a run of precise steps: a clean build, a complete listing, honest privacy declarations, and a little patience through review. The first time impresses you, but once the mechanics click, every later update becomes a few-minute routine. The gap between founders who ship easily and those who dread every release is rarely technical talent. It is preparation, and a habit of treating the store listing as part of the product, not an afterthought bolted on at the end.

If you want to avoid the round trips and get approved on the first try, the ideal is to prepare the submission from the design stage, not the end. That is exactly what we do at Figue: we build your app with its publishing and updates in mind, so launch day is a non-event.

“The best launch is the one that surprises no one: everything was ready, and review is just a formality.”