To publish an app, decide where it should live, make sure it's ready for strangers to use, and go live on the web first. For the app stores, you then set up an Apple developer account and a Google Play developer account, prepare a store listing for each, upload your app files and submit them for review. Many AI app builders handle the hosting and generate the store files for you, so most of the work is in the listing and the review.
The technical steps are the easy part. What catches most people out is the preparation around them: developer accounts that take days to verify, testing rules for new accounts, store listings that need screenshots and privacy details, and review guidelines about things like in-app payments. This guide covers all of it, from a finished app to a live link and approved listings. If you're still building, start with the guide on how to make a mobile app.
TL;DR: How to publish an app
Choose where to publish, make the app ready for real people, go live on the web, set up your developer accounts, prepare your store listings, upload your store files and submit them for review. Keep updating once you're live.
| Step | What you do | What the app builder handles |
|---|---|---|
| 01. Decide where to publish | Pick web, App Store, Google Play or private | Nothing yet, this is your plan |
| 02. Get it ready | Fix dead ends, add a privacy policy, run a security check | Security and store readiness scans, where available |
| 03. Go live on the web | Publish and share the link | Hosting, SSL and a web address |
| 04. Set up developer accounts | Register with Apple and Google | Nothing, these are your accounts |
| 05. Prepare store listings | Write descriptions, add screenshots and privacy details | Nothing, this is in the store consoles |
| 06. Upload store files | Upload the iOS and Android builds | Generating the IPA and AAB files, in some builders |
| 07. Submit and go live | Send for review and answer any feedback | Updates to the live app between releases |
Want to build an app you can publish without code? Start building with Base44.
Where can you publish an app?
There are four main places an app can live, and many apps use more than one.
| Web | Apple App Store | Google Play | Private or internal | |
|---|---|---|---|---|
| What people do | Open a link | Download from the App Store | Download from Google Play | Sign in with an invite or company account |
| Account cost | Usually none beyond your builder or host | 99 USD per membership year | US$25 one-time fee | Usually none beyond your builder or host |
| Review | None | Apple reviews every release | Google reviews releases | None, you control access |
| Time to go live | Minutes | Days for a first release | Days to weeks for a new account | Minutes |
| Best for | Going live fast, sharing links, SEO | iPhone and iPad users | Android users | Team tools and client portals |
The web is the fastest route. A web app works on any phone or computer through a link, needs no install and can be found through search. The app stores add discovery inside the stores, a home screen icon and native features like push notifications, in exchange for fees, review and more setup. Private distribution suits internal tools: people sign in with an invite, and nobody else can reach the app.
How to publish an app in 7 steps
01. Decide where to publish
Start from your audience. If people will find you through search, social posts or links you send, go live on the web first. If they expect to download an app, or you need push notifications, add the stores. If the app is for your team or specific clients, keep it private.
You don't need to do everything at once. Many apps go live on the web, gather feedback for a few weeks, then publish to the stores once the core flows are stable.
02. Get your app ready for real people
Before anyone outside your team sees the app, check that it works for a stranger:
- No dead ends. Every button leads somewhere, every screen has a way back and there are no blank or placeholder pages.
- Complete flows. Sign-up, the main task and any payment work from start to finish, including errors.
- A privacy policy. Required by both stores and by law in many places if you collect personal data. Link it from the app and the listing.
- A test account. Store reviewers need a login that works, with sample data, if your app requires sign-in.
- Accessibility basics. Readable text, strong contrast and large tap targets. See how to make an app accessible.
- A security check. Make sure people can only see their own data and that no keys or admin pages are exposed.
Expert view
Security Scan is the one most builders forget about. It catches the gaps you wouldn't think to check.
Rotem Eisenkot
Product Manager at Base44
Store reviewers test your app like a stranger would. They don't know your shortcuts, they won't read a help doc and they'll tap the button you forgot about. Hand the app to someone who has never seen it, give them only the store description and watch where they get stuck. Anything that confuses them is likely to confuse a reviewer too. For a fuller checklist, see how to secure an app and these common app security mistakes.
03. Publish it on the web first
Going live on the web gives you a working link to share, test with and include in your store listings, which ask for a website and support URL.
- Hosting. Most app builders host your app and give it a web address as soon as you publish. If you built it yourself, you'll need a hosting provider.
- Your own domain. Connect a custom domain like yourapp.com so the link looks professional and is easy to remember.
- Search basics. Set page titles and descriptions for your public pages so people can find the app on Google.
App builders such as Base44 host the app for you, so publishing on the web is a single click, and connecting your own domain is available on paid plans.
04. Set up your developer accounts
To publish to the stores, you need an account with each:
- Apple Developer Program. It costs 99 USD per membership year, with fee waivers available for eligible nonprofits, educational institutions and government entities. You manage your apps in App Store Connect.
- Google Play Console. It has a US$25 one-time registration fee, and you'll go through identity verification. If you register a new personal account, Google also requires a closed test with at least 12 testers opted in for at least 14 days before you can apply for production access, and asks you to verify access to an Android device.
Start both accounts as early as you can. Identity checks, organization verification and Google's testing period can each take days or weeks, and none of them can be rushed at the last minute. Setting the accounts up while you're still building means the store side is ready when the app is.
05. Prepare your store listings
Each store needs a listing before you can submit. Prepare these once and adapt them for each store:
- App name and subtitle or short description.
- Icon in the sizes each store asks for.
- Screenshots of your key screens on current phone sizes, and optionally a short preview video.
- Description that explains what the app does and who it's for in the first two lines.
- Privacy details. Apple and Google both ask what data your app collects and how it's used.
- Category, age rating and content questions.
- Support URL and privacy policy URL.
Write the listing for people, not keywords. The first lines of the description and the first two screenshots do most of the work, both for people browsing and for reviewers trying to understand what the app does.
06. Build and upload your store files
Each store needs a build of your app in its own format: an IPA file for Apple, which you upload to App Store Connect, and an AAB file for Google Play, which you upload in the Play Console. Before a full release, you can share test versions with testers through Apple's TestFlight and Google Play's testing tracks.
If you built with code, you produce these builds with each platform's developer tools. Some app builders generate the files for you. They check your app against store guidelines, help you fix issues and give you files ready to upload, while you still submit through your own developer accounts.
Check your payments before you submit. Both Apple and Google require their own billing systems for digital goods bought inside an app, such as subscriptions, premium features or in-app currency. Physical products and real-world services, like a delivery or a booked appointment, can use a regular payment provider. If your app sells digital content, the common approach is to sell it on your website and have the app unlock it for people who have paid, without a payment flow inside the app.
07. Submit for review, go live and keep it updated
When your listing and build are ready, submit for review. Apple publishes its current review guidance and timing on its App Review page, and Google shows the status of each release in the Play Console. A first release usually takes longer than later updates, especially on a new account.
Rejections are normal, especially the first time. The reviewer's message tells you which guideline the app didn't meet. Fix that issue, reply in the console if something needs explaining and resubmit.
Once you're live, keep improving. Updates to a web app go live as soon as you publish them. Store apps normally need a new build and review for each release, though apps that load their content from the web, like many app builder apps, can update content and design without resubmitting and only need a new build when the app's name, icon or device permissions change. To turn a live app into income, see how to create an app and make money.
Examples of publishing paths
Internal team tool
A stock tracker or approvals app for a 20-person team goes live on the web as a private app. Only people with company accounts can sign in. No stores, no review, live the same day.
Local booking app
A salon or fitness studio goes live on the web with its own domain, then adds the App Store and Google Play a month later so regulars get a home screen icon and appointment reminders. Payments for appointments use a regular payment provider, because the service happens in the real world.
Consumer community app
A hobby community app goes live on the web to test demand, then publishes to both stores once it has steady members. The team sets up both developer accounts during the web phase, so Google's testing period is already complete when they're ready.
Subscription content app
A course or premium content app sells subscriptions on its website and publishes to the stores as a free download that unlocks content for people who have already paid. Nothing in the app opens a payment flow, so it follows the stores' digital goods rules.
Frequently asked questions
Publishing on the web usually costs nothing beyond your app builder or hosting plan, plus a domain if you want one. The Apple Developer Program costs 99 USD per membership year, and Google Play has a US$25 one-time registration fee. Some builders also require a paid plan to generate app store files. For the full picture, see how much it costs to make an app.
It varies by store, account and app. Apple publishes its current review timing on its App Review page, and updates are usually quicker than a first release. On Google Play, new personal accounts must first complete a 14-day closed test with at least 12 testers, so plan for a few weeks before your first production release.
Yes, on the web. Many app builders, Base44 included, let you build and publish a web app on a free plan with the builder's own web address. Publishing to the App Store or Google Play always involves the stores' developer fees.
Yes. No-code and AI app builders let you build the app, host it on the web and, in many cases, generate the files the app stores need. You still set up your own developer accounts, write your store listings and submit through the stores' consoles.
Read the reviewer's message carefully. It names the guideline your app didn't meet. Fix that specific issue, add an explanation in the console if something was misunderstood, and resubmit. Most first rejections are about missing information, a broken flow, login access for the reviewer or in-app payments for digital goods.