Stores & publishing

Publishing your app to the App Store and Play Store

Your developer accounts exist and your build runs: here is how to submit your app to the App Store and Play Store, step by step, without getting rejected.

8 min read
Publishing your app to the App Store and Play Store

What you need before you submit

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.

Submitting to the App Store, step by step

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.

1

Create the app in App Store Connect

Sign in to App Store Connect, go to My Apps, click the plus, then New App. Enter the name, primary language, bundle ID (the same as in your Xcode project) and an internal SKU. The name must be unique across the entire App Store: if yours is taken, find a variant.

2

Upload the build via Xcode or Transporter

In Xcode, select the Any iOS Device target, then Product, Archive. Once the archive is ready, click Distribute App, App Store Connect, and let Xcode sign and send it. The build shows up in App Store Connect after a few minutes to an hour, the time Apple needs to process it.

3

Test through TestFlight (recommended)

Before submitting to the public, invite yourself and a few people on TestFlight. It is Apple's testing channel: it lets you check the exact build that will go to review, on real devices, without waiting for publication. Bugs caught here save you a rejection or a bad rating at launch.

4

Fill the listing and submit for review

Add the screenshots (at the correct sizes), the description, keywords, support URL and privacy policy. Fill in the App Privacy questionnaire: Apple requires you to declare what you collect. Attach your build, choose manual or automatic release, then click Add for Review.

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.

Publishing on Google Play, step by step

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.

1

Create the app and fill the store listing

In the Play Console, click Create app, give the name, default language and type (app or game, free or paid). Then fill the listing: short and long description, icon, screenshots, feature graphic. Also complete the mandatory sections: app content, target audience, data safety and privacy policy.

2

Upload the AAB to a testing track

Google favours the Android App Bundle (AAB) format. First create a release on a testing track: internal (fast, a handful of testers), closed or open. Since 2023, a new personal developer account must have its app tested by at least 12 people for 14 days before reaching production. Plan for that delay.

3

Move to production and roll out

Once testing is validated, create a release on the Production track, attach your AAB, write the release notes, then send for review. You can roll out to 100 percent or do a staged rollout (say 20 percent of users) to watch for crashes before full distribution.

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.

Apple review: common rejection reasons

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.

Publishing lessons learned

Pre-submission checklist

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.

Conclusion

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.

Related articles

What is a product studio? Definition, model and pricing
Product studio

What is a product studio? Definition, model and pricing

Product studio: the word is everywhere, the definition nowhere. Here is what the model really covers, how it works, what it costs and who it fits.

How to integrate AI into your business: a practical, honest guide
AI

How to integrate AI into your business: a practical, honest guide

Everyone tells you to do AI, without saying where or for what gain. Here is where AI truly creates value in a small business, concrete use cases, custom vs no-code, costs, ROI and the mistakes to avoid.

Fractional CTO: what it is, when to bring one in, and how to choose
Tech leadership

Fractional CTO: what it is, when to bring one in, and how to choose

A product taking off, a small team, and no one to arbitrate the technical choices that will shape the next five years. A fractional CTO fills that gap without the cost of a full-time hire. When to bring one in, what they really do, how much it costs.

SaaS go-to-market plan: the first 8 weeks to win your first customers
Go-to-market

SaaS go-to-market plan: the first 8 weeks to win your first customers

A clean product that will not sell is almost always a go-to-market problem, not a tech one. Here is a concrete 8 week plan: positioning, channels, pricing, growth loop. Founder to founder.

No-code or custom: how to choose when launching your first product
Building

No-code or custom: how to choose when launching your first product

No-code to move fast, or custom to do it right? The real question is not the camp, it is the moment. Here is the grid to decide when you already have an audience or traction.

Tech as a Service: senior engineering reinforcement to ship 3x faster
Collaboration

Tech as a Service: senior engineering reinforcement to ship 3x faster

You have a technical team but a velocity bottleneck? Plug-and-play senior reinforcement lets you hit deadlines without hiring. Here is how, and when to use it.

ReactIn: from side project to full LinkedIn outreach tool
Case Study

ReactIn: from side project to full LinkedIn outreach tool

How an internal LinkedIn prospecting tool became a $6K MRR bootstrapped SaaS, with zero paid advertising or fundraising.

We tripled our prices: the real pivot behind our design offer
Pricing

We tripled our prices: the real pivot behind our design offer

How we went from a $2K/month design subscription to a $6K+ premium product studio. Fewer clients, 3x revenue per client, better quality.

Our best SaaS tools (and how we actually use them)
Tools & Stack

Our best SaaS tools (and how we actually use them)

The complete stack of a product studio building SaaS products: dev, design, growth and ops. Real tools, real costs, real lessons after 3 years.

Bootstrap vs fundraising, freelance vs agency, solo vs co-founders: our founder choices
Entrepreneurship

Bootstrap vs fundraising, freelance vs agency, solo vs co-founders: our founder choices

3 dilemmas that define your startup trajectory. A look back at our choices at Figue, with real numbers and hard-won lessons.

Product studio vs traditional agency: why it changes everything
Strategy

Product studio vs traditional agency: why it changes everything

Agencies optimise for volume. Product studios optimise for outcomes. Here's why that makes all the difference for your project.