How to Publish an AI-Built App to the App Store

The hard part of putting an AI-built app on the App Store is usually not Apple. It is finding out, several weeks in, that the thing you built cannot go to a store at all.

We keep a capability record for every entry in the directory, built from vendor documentation rather than vendor marketing. Of the 185 entries carrying one today, 10 can reach a store for you, 5 hand you source code you have to ship yourself, and 3 produce a web app that installs to a home screen and cannot be listed. The rest are either assessed as web-only or are not app builders at all. That distribution is the real answer to "how do I publish this", and it is why most guides on this query are useless to the person asking it: they start at the point where you already hold a signed build.

So this one starts earlier. What you hold, what Apple charges, what Apple checks, and what to do in each of the three cases.

Step zero: find out what your builder actually produces

"Build mobile apps" appears on nearly every AI builder's landing page and means at least three different things. The distinction that matters is the artefact you are left holding when the tool has finished.

The ten that document a submission or build flow of their own are Bubble, Rork, Anything.com, Replit, Lance, FlutterFlow, A0.dev, Thunkable, Retool and Wix Harmony. The five that hand you code are Bolt.new, Rocket, Tempo, Capacity and PiPilot. Three document PWA or web-installable output: Base44, Jotform AI App Builder and GitHub Spark. Seven are documented as web-only, Lovable among them, whose own guide on native versus web is the clearest statement of it from any vendor in the set.

Twenty-one further entries are recorded as unverified, which means their documentation was checked and did not say. If your tool is one of those, the answer is in front of you the moment you look for the word "submit" in their docs, and its absence is itself informative.

The full table lives on the AI app builders hub, and the two adjacent pieces are AI app builders that can ship mobile and AI app builders for non-developers.

What Apple requires, whichever of the three you are in

Every path converges here. Nothing below is optional, and none of it is done for you by an AI builder that "publishes for you" except where the table above says so.

Two details catch first-time publishers. The seller name is the one you chose at enrolment, and changing an individual name to a company name later is an entity change rather than a settings edit, so pick deliberately. And the one SDK gate Apple currently publishes is in the future: starting April 2027, iOS and iPadOS apps uploaded to App Store Connect must be built with the iOS and iPadOS 27 SDK or later. Several vendor guides in this SERP state an earlier Xcode 26 cutoff as Apple policy. That date is not on Apple's upcoming requirements page today, and if your builder produces the binary, it is their problem rather than yours in any case.

The official sequence, which is shorter than it looks

Apple's own publishing overview lists five steps: choose your build, set pricing and availability, submit for review, watch the status and resolve issues, and request promo codes. App Store Connect restricts the submit action to the Account Holder, Admin or App Manager role.

The part people mis-plan is the end of it rather than the beginning. Apple states "On average, 90% of submissions are reviewed in less than 24 hours", and then, separately, "After your app is approved, it can take up to 24 hours to go live on the App Store." Two different clocks, and neither is a commitment. If you have told anyone a launch date, give yourself a week.

Before you submit anything, put the build through TestFlight. Guideline 2.2 is explicit that the store is not the place for a trial: "Demos, betas, and trial versions of your app don't belong on the App Store", and it names TestFlight as where they do belong. TestFlight is also where you find the crash that would otherwise cost you a rejection and a resubmission, and it takes external testers in numbers no early-stage app needs to worry about exceeding.

If your builder submits for you

This is the shortest path and it is still not a button. What the vendor automates is the build and the upload. What remains yours is everything Apple asks a human for: the paid membership in your name, the listing copy, the screenshots, the age rating questionnaire, the privacy details, and the answer to every review question that follows.

Two things to check in the vendor's documentation before you rely on the flow:

Whose account is it. Some builders submit under your developer account using credentials or an API key you provide. That is the arrangement you want, because the app belongs to you and survives your leaving the platform. Read what access they ask for and what happens to it afterwards.

Whether it is gated on a plan. Store submission is a paid tier feature at several of these vendors. Find that out before the build, not after.

If your builder hands you code

You own a React Native or Flutter project, and the store is a normal mobile release problem: signing certificates, a provisioning profile, an archive, an upload. Apple's description of its own toolchain is that Xcode "includes the tools you need to build and upload apps", which is the honest summary of where this path goes.

You do not strictly need a Mac on your desk. Managed build services build and sign in the cloud and submit from there, and several vendors document that flow. What you do need is a Mac somewhere in the chain, whether it is yours, rented by the hour, or inside somebody's build service. Any claim that no Mac is involved is true only inside the pipeline making it.

The first release is the expensive one. After that, the same chain runs in minutes.

If what you built is a website

This is the largest group, and the answer is the one nobody wants: you do not have a mobile app. You have a web app, and it can be excellent. It installs to a home screen, it updates without a review queue, and it costs 99 USD less per year than the alternative.

If it has to be in the store, someone wraps it, and then guideline 4.2 decides. Apple's wording is worth reading exactly: your app "should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or 'app-like', it doesn't belong on the App Store." Guideline 4.2.2 adds that apps "shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."

Wrappers do pass review. They pass when the app does something the browser tab cannot: push notifications people want, offline use, camera or location work, a widget, a genuinely native flow around the web content. They fail when the wrapper is the entire product, and the review note you get back will say so in the language above.

What actually gets you rejected

Apple publishes the distribution and it is not what first-time publishers expect: "On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness, which covers crashes, placeholder content, incomplete information, and more."

Almost none of that is about your idea. It is about the state of the submission. The guideline itself lists what it means: submissions "should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission", tested on-device, with "demo account info (and turn on your back-end service!) if your app includes a login."

A pre-submission pass, in the order things actually go wrong:

• Every URL in the listing resolves. Support URL, privacy policy URL, marketing URL. A 404 here is a rejection.
• No placeholder anything. Lorem ipsum in an empty state, a screen that says "coming soon", a settings row that does nothing.
• A working demo login, and the backend switched on. If the reviewer cannot get past your sign-in screen, nothing else about the app is assessed. Apple allows a built-in demo mode instead, with prior approval, when legal or security obligations prevent an account.
• In-app purchases that resolve in the review build. If a product cannot be found, explain why in the review notes rather than leaving the reviewer to guess.
• Privacy details that match what the app does. An AI-built app often carries third-party SDKs you did not choose deliberately. What they collect is still your declaration.
• Screenshots that do not make claims. Publishers report pricing language in screenshot artwork being treated as pricing information, which is a metadata question rather than an app question and is a slow way to lose two days.

When a rejection does arrive, the fastest route is usually the boring one: fix exactly what the note says, resubmit, and use the resolution centre rather than the appeal. Apple's appeal route exists for the case where "we misunderstood your app's concept and functionality", and that is genuinely not most first rejections. Expedited review is separate again, for a critical bug fix or an event-tied release.

When not to go to the store at all

This piece recommends a path, so here is where the recommendation is wrong.

If the app is for you, for your team, or for a few dozen known people, the store is the expensive answer to a question you do not have. A web app on a home screen needs no membership, no review, no screenshots at four device sizes, and no waiting to ship a fix. Developers make this argument to each other constantly, and for internal tools they are right.

The store earns its cost when you need what only the store provides: discovery by people who have never heard of you, the payment rail, push notifications on iOS, the trust of an install that came from Apple rather than a link, and the hardware access a browser will not give you. If you cannot name which of those you are buying, you are buying 99 USD a year and a review queue.

The second case against it is timing. Launching into review with a first version that is thin invites a 2.1 rejection on completeness, and the resubmission cycle is when most solo publishers lose their momentum. TestFlight first, store second, is not caution. It is the shorter route.

What to do next

If you have not yet chosen a builder, choose one whose output matches where you want to end up, and check that on the AI app builders hub rather than on the builder's landing page. If you already built something, the capability table tells you which of the three sections above is yours.

And if the answer turns out to be "you built a website", that is worth knowing today rather than after the 99 USD, the screenshots and the rejection.

FAQ

How much does it cost to publish an app to the App Store?

Apple's membership page states "The Apple Developer Program is 99 USD per membership year, or in local currency where available." There is no separate per-app upload fee. If you sell anything inside the app, Apple's commission is 30%, or 15% under the App Store Small Business Program, and 15% for qualifying subscriptions.

Can I publish with a free Apple developer account?

No. A free account lets you run your own builds on your own devices through Xcode. Distribution on the App Store requires the paid membership.

How long does App Review take in 2026?

Apple states "On average, 90% of submissions are reviewed in less than 24 hours." That is an average rather than a promise, and approval is not the same as being live: "After your app is approved, it can take up to 24 hours to go live on the App Store."

Do I need a Mac?

Not always. Several builders submit on your behalf from their own infrastructure. If you hold source code instead, you need a Mac somewhere in the chain, whether it is yours or a build service's. Any universal "no Mac needed" claim is true only inside the pipeline making it.

Why do most apps get rejected?

Apple's own figure: "On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness, which covers crashes, placeholder content, incomplete information, and more." Most first rejections are about the state of the submission rather than the idea.

Will Apple accept a wrapped website?

Sometimes. Guideline 4.2 asks for features, content and UI beyond a repackaged website, and 4.2.2 rules out apps that are "primarily marketing materials, advertisements, web clippings, content aggregators, or a collection of links." A wrapper passes when the app does something a browser tab cannot.

What SDK does my build have to use?

Apple's submitting page currently lists one upcoming gate: starting April 2027, iOS and iPadOS apps uploaded to App Store Connect must be built with the iOS and iPadOS 27 SDK or later. Vendor guides quoting an earlier Xcode 26 cutoff are not repeating an Apple date from that page.

Can I put a beta on the App Store?

No. Guideline 2.2 says demos, betas and trial versions do not belong there, and directs you to TestFlight.

What happens if I am rejected?

Fix what the note says and resubmit, which usually costs days. Apple also runs an appeal to the App Review Board for the case where the review misunderstood the app, and expedited review for critical bug fixes and event-tied releases.

Who can press Submit for Review?

The Account Holder, Admin or App Manager role in App Store Connect. If someone built the app for you, check which role they hold before your launch day.

---

Every Apple figure and quotation on this page was checked against Apple's own documentation on 12 September 2026: the Apple Developer Program membership details, the App Review page, the App Review Guidelines, the App Store submitting page and the App Store Connect publishing overview. Capability counts come from the directory's own per-entry records, each sourced to vendor documentation. Apple changes fees, timings and guidelines; check the dates above before you rely on them.