How to Publish an App Without Code in 2026 (Step-by-Step)
You built an app without writing a line of code. Now comes the part nobody warns you about: publishing it. The App Store and Google Play don't care that you used a no-code tool — they hand you the same developer accounts, the same metadata forms, and the same review process a funded startup gets. That's where most indie makers stall.
This is the end-to-end map. Follow it in order and you'll go from a finished build to a live listing on both stores, without a developer and without guessing. Every stage links to a deeper guide when you need one, but you can run the whole launch from this page.
Can you actually publish an app without coding?
Yes — and it's more normal than it sounds. Modern no-code platforms compile a real native binary (an .ipa for iOS, an .aab for Android) that's indistinguishable to the stores from something a developer wrote by hand. What you can't skip is the publishing work: creating developer accounts, generating store assets, filling out listings, and passing review. That work is all forms and files, not code, which is exactly why a solo maker can do it.
If you're weighing whether to even bother building first, the short version: the tools are ready, the stores accept no-code apps every day, and the whole process below is designed to be done by one person. See what a purpose-built publishing toolkit looks like on the Adalo Studio homepage — it exists specifically because this stage is the bottleneck for no-code makers.
The 9 stages of publishing a no-code app
Here's the full journey at a glance. The rest of this guide walks through each one.
- Finalize and test your build
- Create your developer accounts
- Prepare your legal documents (privacy policy + terms)
- Design your store screenshots
- Write your store listing and metadata
- Complete data & privacy declarations
- Upload your build
- Submit for review
- Launch, monitor, and iterate
Stage 1 — Finalize and test your build
Before anything store-related, make sure the app actually works. Reviewers reject apps that crash, show broken links, or contain placeholder content faster than for any other reason.
Do this before you move on:
- Test every core flow on a real device, not just a simulator.
- Remove test data, "lorem ipsum," and dead buttons.
- Confirm sign-up, login, and password reset all work.
- Check that the app handles no-internet gracefully.
- Set your app's version number and build number.
A stable build is the foundation. Everything downstream assumes the app itself is finished.
One more thing reviewers check hard: your app has to do something. A thin wrapper around a website, or an app that's really just a bookmark, gets rejected on both stores. Make sure your app delivers native value — offline behavior, push notifications, device features, or an experience that genuinely beats visiting a mobile site. If you've built real functionality in your no-code tool, you're fine; just don't ship a glorified web view.
Stage 2 — Create your developer accounts
You publish through official store accounts. Set these up early because Apple's can take a day or two to verify.
| Store |
Account |
Cost |
Notes |
| Apple App Store |
Apple Developer Program |
$99/year |
Individual or organization; organization needs a D-U-N-S number |
| Google Play |
Google Play Developer account |
$25 one-time |
Identity verification now required for new accounts |
You don't need both to launch. Plenty of makers ship to one store first to keep the process simple, then add the second once the first is live. If you only want the larger audience and cheaper entry, Google Play is the common starting point; if your audience is iPhone-heavy, start with Apple.
Stage 3 — Prepare your legal documents
Both stores require a privacy policy URL on your listing, even for a simple app, the moment it collects any user data — and almost every app collects something (analytics and crash reporting count). Many makers also add a terms of service.
You don't need a lawyer for a standard app. Generate a policy that reflects what your app actually collects using the app privacy policy generator, host it at a public URL, and keep the link handy for the listing forms. Do this now because you'll reference it in Stage 6, and your privacy policy must match the data declarations you make there. If you're unsure whether you even need one, read do you need a privacy policy for your app.
Stage 4 — Design your store screenshots
Screenshots are the single biggest driver of whether someone taps "Get." They're also a hard requirement: both stores reject listings without correctly sized images.
You need exact dimensions, and 2026 sizes are:
- iPhone 6.9" — 1320 × 2868 px
- iPhone 6.7" — 1290 × 2796 px
- Google Play phone — 1080 × 1920 px
Don't just paste raw screen captures. The best listings use framed devices, a headline caption per image, and a consistent background. Build them at the correct export sizes with the app store screenshot generator so you never get bounced for a wrong dimension, and see the full app store screenshot sizes guide for every device slot and iPad requirement.
Stage 5 — Write your store listing and metadata
This is your app's storefront copy, and it's also your search visibility. Both stores index parts of it, so it's worth doing deliberately rather than typing something at the last minute.
The core fields:
- App name — your brand plus, ideally, a keyword (30 chars on Apple).
- Subtitle (Apple) / short description (Google) — one line on the value.
- Keywords field (Apple only) — a 100-character comma-separated list.
- Description — the long pitch; Google indexes this, Apple doesn't.
- Promotional text (Apple) — updatable without review.
- Category and age rating.
Getting this right is app store optimization (ASO), and it directly affects downloads. Start with the ASO playbook for indie developers and, when you're writing the copy, how to write an app store description that gets downloads.
Stage 6 — Complete data & privacy declarations
Each store makes you formally declare what data your app collects and how you use it. This is separate from your privacy policy — it's a structured form — but the two must agree.
- Google Play — Data Safety section. Fourteen data categories, per-type questions on collection, sharing, purpose, and security. This is one of the most common rejection points for no-code apps, so follow the field-by-field Google Play Data Safety walkthrough.
- Apple — App Privacy ("Nutrition Label"). A similar set of questions in App Store Connect about what data you and your SDKs collect and whether it's linked to the user or used for tracking.
The trap in both: forgetting that analytics, ads, and crash-reporting SDKs collect data on your behalf. Declare those too.
A quick way to get these right: list every integration your app uses (auth, analytics, payments, push, maps, ads), note what each one collects, and answer the forms from that list rather than from memory. Then confirm your privacy policy names every data type you declared. When the policy, the Apple label, and the Google form all say the same thing, you've closed the single biggest source of no-code rejections.
Stage 7 — Upload your build
Now you push the actual binary to the store.
- Apple: Export the
.ipa from your no-code platform and upload it to App Store Connect (via Transporter or your platform's publishing flow). It appears under your app's builds after processing.
- Google Play: Upload the
.aab to a release track in Play Console. Start with internal testing or closed testing to sanity-check the store build on real devices before going to production.
Use the test tracks. Catching a problem in internal testing is free; catching it after a public rejection costs you days.
Stage 8 — Submit for review
With build, assets, listing, and declarations all in place, you submit. A reviewer (and increasingly, automated checks) will look at your app against the store guidelines.
Before you hit submit, run the complete app store submission checklist — it catches the small omissions (missing screenshot slot, broken privacy URL, mismatched data declaration) that cause most first-time rejections. If you do get rejected, don't panic; read the reason, fix that one thing, and resubmit. Most rejections are single, specific, and fixable.
Stage 9 — Launch, monitor, and iterate
Approval isn't the finish line. Once you're live:
- Watch your crash and analytics dashboards for real-world issues.
- Respond to early reviews — Google Play lets you reply publicly.
- Track your listing's conversion rate (views → installs) and improve the weakest screenshot or line of copy.
- Ship updates. Each update re-runs a lighter review, so keep your metadata and declarations current.
Publishing is a loop, not a one-time event. The makers who grow treat the store listing as something they refine, not something they set and forget.
A note on the two stores side by side
If you're publishing to both stores, it helps to see where they diverge so you don't assume one set of rules covers both.
| Area |
Apple App Store |
Google Play |
| Account cost |
$99/year |
$25 one-time |
| Review time (first release) |
~24–48 hours |
Hours to a few days |
| Search-indexed copy |
App name, subtitle, keywords field |
App name, short + full description |
| Data declaration |
App Privacy "nutrition label" |
Data Safety section |
| Required extra asset |
— |
1024 × 500 feature graphic |
| Metadata you can edit without review |
Promotional text |
Most listing fields |
The overlap is large — same screenshots concept, same privacy-policy requirement, same "your app must do something real" bar — but the details differ enough that you should treat each store's forms on their own terms rather than copy-pasting blindly between them.
How much does it cost and how long does it take?
Here's the realistic picture for a solo maker doing this without a developer.
| Item |
Cost |
Time |
| Apple Developer Program |
$99/year |
~1–2 days to verify |
| Google Play Developer account |
$25 one-time |
Hours to a few days to verify |
| Privacy policy |
Free–low with a generator |
Minutes |
| Screenshots + listing assets |
Free to design; small one-time unlock to export |
A few hours |
| App review (Apple) |
Included |
~24–48 hours |
| App review (Google) |
Included |
Hours to a few days |
Most makers get from finished build to live listing in one to three days of focused work, most of which is preparing assets and copy — not waiting on review. You can see exactly what the paid steps cost on the pricing page; designing screenshots and drafting listings is free, and you only pay to export final images or use the AI features.
The fastest path if you only remember one thing
Prepare everything before you touch the submit button: working build, developer accounts, privacy policy, correctly sized screenshots, finished listing copy, and honest data declarations. Rejections almost always come from a missing or mismatched asset — not from your app being "not good enough." Line the pieces up, check them against the submission checklist, and submit once.
First 3 moves this week
- Create your developer account for the store you're launching on first — start the verification clock today.
- Generate your privacy policy and host it at a public URL so it's ready for both the listing and your data declarations.
- Design your screenshots at the exact 2026 store sizes with the screenshot generator so nothing bounces at review.
Frequently asked questions
Can you really publish an app to the App Store without coding?
Yes. No-code platforms build native app binaries you can submit to both stores, and you complete the store paperwork yourself in App Store Connect and Google Play Console. You don't write code, but you do need developer accounts, store assets, and a privacy policy.
How much does it cost to publish an app without a developer?
Budget $99/year for the Apple Developer Program and a one-time $25 for a Google Play Developer account. Your no-code platform may have its own subscription, and asset tools like screenshot and privacy-policy generators range from free to a small one-time unlock.
How long does it take to publish a no-code app?
Preparing assets and store listings takes most makers one to three days of focused work. After you submit, Apple review typically takes 24 to 48 hours and Google Play takes a few hours to a few days for a first release.
Do I need both an Apple and a Google account to publish?
Only if you want to be on both stores. You need an Apple Developer Program membership to publish to the App Store and a Google Play Developer account to publish to Google Play. Many makers launch on one store first, then add the other.