Getting an AI-built app through App Store review in 2026

This is a field report, not a paraphrase of Apple's documentation. We operate a platform that generates Flutter apps and publishes them to the App Store and Google Play from each user's own developer account — and in 2026 we took our own companion app through Apple review as well, through a Guideline 2.5.2 exposure, an automated in-app purchase price check, and the metadata lockouts that surprise people mid-review. Every hard claim below is one of two things, and says which: our own submission experience, or a public fact you can check yourself — a store listing, a published guideline, a dated article. There are no invented statistics on this page.

Two pieces of 2026 context frame everything else. In March 2026, Apple moved against app builders that execute generated code on the device, and the public wreckage of that wave is the best available map of where the line actually sits. The same year, Apple's reworked global age-rating tiers changed what an unguarded WebView costs you. Both are covered below.

Does Guideline 2.5.2 ban AI app builders?

No — and the distinction it draws is the most useful sentence in this guide. The published rule (Apple, App Store Review Guidelines, 2.5.2) reads:

Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.

Read that as three separate cases:

• An app that AI built — a fitness tracker, a storefront, a game that happens to have been generated by a model — is not touched by 2.5.2 at all. It is an ordinary, self-contained binary. Nothing in Apple's guidelines asks who, or what, wrote the code.
• A builder app that previews — the phone shows a rendering of the user's project served from the builder's servers, while generation and compilation happen off-device — has a defensible shape, and every long-surviving creation app on the store has it (two sections down).
• A builder app that downloads and executes generated code on the device is what the guideline literally names, and 2026 enforcement matched the text: the products hit hardest were exactly the ones running generated native code on the phone.

Apple also publishes its own carve-outs, worth knowing before you argue with a rejection. Educational apps may, in limited circumstances, download code for teaching and testing purposes; and Guideline 4.7 explicitly permits mini apps and mini games — software running inside your app — when it is not native code and you take responsibility for moderating it. Neither carve-out covers arbitrary generated native code, but both explain patterns you will see on the store — including why enforcement pushed some builders toward Education listings rather than off the store entirely.

What did reviewers actually reject or reframe in 2026?

Everything in this section is a public, checkable fact — mostly store listings, which are the honest record of enforcement, because a developer rewrites a live listing under pressure, not for fun.

• Vibecode, the best-funded mobile app builder, had its iOS app retitled from "Vibecode - AI App Builder" to "Vibecode - Website Builder", refiled from Developer Tools into Education, with its description narrowed to building websites with HTML. Its Google Play listing kept the original positioning. That asymmetry — the iOS listing rewritten while Play stands untouched — is the fingerprint of Apple enforcement, not of a pivot. We pulled both listings through the public iTunes Lookup API on 2026-08-20; you can repeat the check in a minute.
• LastApp, the other product in the category that previewed native code on the device, shows the same distortion on iOS: a learn-to-code reframing plus an age gate — while web-preview builders (Replit, Lovable, Base44, v0) kept plain "build apps" language in Developer Tools and Productivity. Two independent products, the same reshaping, one platform. Public listings, checkable today.
• "Anything", a build-on-device app, disappeared from the store entirely.
• Bloom shipped its builder Android-first, then held an iOS approval for months before Apple reversed it. That one is reported rather than something we verified ourselves — but it is consistent with everything above, and it carries the harshest lesson in this guide: an App Store approval is not durable. Passing review in January does not mean the same binary passes in June.

For scale, the one independent measurement of this category is public too: TechCrunch wrote on September 23, 2025 that dedicated mobile apps for vibe coding had "so far failed to gain traction". And the submission wall is documented from the indie side as well — the founder of one builder wrote on Hacker News in May 2026 that competing tools "would only get you as far as TestFlight".

Note what is absent from this list: we can find no public 2026 case of an ordinary app being rejected because it was AI-generated. The enforcement wave was about builders executing code on devices, not about authorship.

What is the pattern that survives?

On-device creation tools that Apple has left alone for years exist, and their listings agree with each other. The ratings counts below are public App Store data, pulled 2026-08-20:

• Sticky – AI Game Maker — on the store since March 2020, 8,800 ratings, 4.5 stars, still updating. Six years of letting people create and publish games from a phone.
• Loopit (35,107 ratings), Aippy (22,966), and Expo Go (7,117) — the same survivable family.

Three things recur across those listings and architectures, and we treat the trio as the pattern:

1. A constrained runtime. What users create runs inside a sandboxed, interpreted environment the host app defines — never as arbitrary native code.
2. An explicit moderation clause in the listing. User-created content can be reported, and the developer commits to acting on reports — Sticky's listing states a 24-hour window.
3. A "for developers / learners" disclaimer that sets the audience expectation. Expo Go's "some programming experience is recommended" is the canonical example.

Our own architecture decision follows directly, and we recommend it to anyone building in this space: generation and compilation happen server-side; the phone app is preview and orchestration only; no generated code ever executes on the device. Two corollaries. Ship phone-side creation features Android-first, because Google does not enforce an equivalent of 2.5.2 against this category (see the Play section below). And never make "build it on your phone" the headline promise of your listing — it is a demo, not a promise, because Apple can revoke it after approval.

Will Apple reject an app just because AI wrote it?

There is no guideline about authorship, and App Review evaluates a binary and its metadata — it has no way to ask who typed the code. What actually catches AI-built apps is older and better documented:

• Guideline 2.1 (App Completeness): placeholder screens, dead buttons, filler text, links that 404. Generated apps fail here more than anywhere else, because a model will happily scaffold a Settings screen it never wired up.
• Guideline 4.2 (Minimum Functionality): the thin template app. If the app is a wrapped website or a single static screen, AI authorship is irrelevant — it was always rejectable.
• Crashes on the reviewer's device. Reviewers use real hardware. If you have only ever run your app in a simulator or a web preview, you have not run your app.
• Guideline 4.3 (Spam) deserves special mention in this category: many near-identical apps from one developer account is a named rejection pattern. A tool that publishes its users' apps from a single shared account manufactures a 4.3 profile on that account. Publishing from each user's own developer account avoids the shape entirely — that is a large part of why we built ours that way.

The honest one-line answer: Apple does not reject AI-built apps; it rejects unfinished apps — and AI is unusually good at producing finished-looking unfinished apps.

What should your App Review notes contain?

Review notes are the one channel where you talk to the reviewer before they form an opinion. Ours passed with our companion app's first approval, and they had three deliberate parts. This whole section is our own experience.

1. A demo video link. A hosted video of the core flow, recorded on a physical phone: create, build, preview, manage. A reviewer who has watched thirty seconds of the app working starts from "this is real" instead of "prove it".
2. An explanation of why there is no demo account. When an app requires sign-in, the default expectation is demo credentials. We explained instead: sign-up is free, self-serve, and works with any email address — and a fresh account shows the reviewer more of the product than a shared, pre-populated one would. If you cannot write that paragraph honestly for your app, provide the demo account.
3. A preemptive defense of the riskiest screen. For us, the preview tab. In substance:

The Preview tab displays the user's own project, rendered on our servers and shown in a WebView. The app does not download, install, or execute code; generation and compilation happen server-side, and nothing a user creates changes this binary's features or functionality.

That is 2.5.2's own vocabulary, used before the reviewer reaches for it. If your app has a screen that could be misread as on-device code execution, name it, explain it, and close the question in advance — not in a rejection appeal.

One mechanical footnote that cost us a morning: App Store Connect requires a review contact phone number, and the App Store Connect API refused to save our review notes until it was set. Fill in the contact block before you write the notes.

What metadata can you edit while In Review?

The mental model that saved us: once you submit, the version is a sealed envelope — the app around it is not. In our 2026 submissions, App Store Connect behaved as follows:

Apple shifts these edges between App Store Connect releases; treat the table as what held for our submissions, not as an API contract.

Two practices follow from it. First, pin the submitted build's source: we tag the exact commit and keep a release branch for it, and when a reviewer requests a change, the fix is cut from that branch as the next build number — never from the trunk, which by then contains unreviewed work. Second, treat promotional text as your only safe live-edit surface: because it is editable at any time without review, it is where time-sensitive listing copy belongs.

What triggers the automated IAP price check?

This one is under-documented anywhere, so here is our exact experience. Our companion app's first submission carried five in-app purchases: two monthly subscriptions and three consumable credit packs. The largest pack — $57.99 — drew a hold citing Guideline 3.0.0 (Business: Preamble), asking us to confirm the price was intended. The subscriptions and the smaller packs drew nothing.

The Business preamble is Apple's catch-all against pricing that looks like a mistake or a scam — its published text warns against apps that try to cheat users with "irrationally high prices". The check behaves like a threshold filter on expensive consumables: a pricey consumable is the shape that both fat-finger pricing mistakes and scam apps take, so a large one gets a human question before approval.

The fix was one paragraph in the reply box, and review continued without a new binary. In substance:

The price is intentional. The product is a consumable credit pack — the largest of three — and credits are the unit users spend on AI app builds. The same pack, at the same price, is sold on our website. Please continue the review.

Three notes if it happens to you: answer plainly and factually; point at an external price anchor if you have one (our web pricing page did that work); and do not preemptively lower the price — the question being asked is "did you mean this?", not "this is too expensive".

Why does the age-rating questionnaire matter?

Under the reworked global age-rating tiers Apple rolled out in 2026, one questionnaire answer dominates everything else for utility apps: Unrestricted Web Access. Answer yes — which any app with an unguarded WebView must — and your floor is 16+, regardless of content. Our companion app shipped its first version at 16+ for exactly this reason: its preview WebView could technically navigate anywhere.

A 16+ rating is not cosmetic. It interacts with parental controls and storefront filtering, and on a developer-tool listing it simply reads wrong.

The fix is architectural, not clerical: put a navigation guard on the WebView so it can only reach your own origins (external links hand off to the system browser), and the honest answer to the question becomes no — which drops the rating to 4+. The word honest is load-bearing. The questionnaire is a declaration, and the correct direction of travel is never "answer what you want to be true"; it is "change the app until the true answer is the one you want".

The pre-submission checklist

Every item here is either something that blocked us or something we watched block others:

• Run the release build on a physical iPhone (and, for Play, a physical Android device). Simulator-only testing is not testing.
• Sweep for 2.1 completeness: every button does something, every screen has real content, every link resolves. Empty states are designed, not accidental.
• Record the demo video on a real device and host it at a stable URL.
• Fill in the review contact, including the phone number, before writing review notes — App Store Connect will not save the notes without it (our experience, via the API).
• Provide a demo account — or an honest written explanation of why a free sign-up serves the reviewer better than shared credentials.
• Write the preemptive defense of your riskiest screen into the review notes, in the relevant guideline's own vocabulary.
• Complete the App Privacy questionnaire in App Store Connect by hand — in our experience it cannot be automated through the API, so budget founder time for it.
• Answer the age-rating questionnaire for the app you actually shipped — and if the honest answers produce a rating you dislike, change the app, not the answers.
• If you sell in-app purchases: attach the products to the first submission, keep store and web pricing coherent, and expect a price-confirmation hold on your most expensive consumable.
• Set ITSAppUsesNonExemptEncryption to false in Info.plist if you use only standard TLS and OS crypto, so the export-compliance question never stalls an upload.
• Tag the submitted commit and cut a release branch. A reviewer request two weeks later must be answerable with a one-line fix on that branch — not with a freeze of your trunk.
• If users create content your app displays: put a moderation clause and a report mechanism in the app and the listing — the survivable-pattern section above is the evidence for why.

Is Google Play any easier?

Different, not easier. The builders that were reframed on iOS kept their original Play listings — public evidence that Google is not enforcing a 2.5.2 equivalent against this category. What Play gates instead is paperwork and identity, and it bites earlier in the pipeline. All of this is our own experience shipping the Android twin of the same app:

• Production access is gated on declarations. The Data safety form, the content rating questionnaire, target-audience declarations, and the app-access section (Play's demo-account equivalent) must all be complete before a production release is possible.
• Developer verification can freeze your automation. Our Play API uploads returned 403s until account verification was finished — nothing in the pipeline was wrong; the account itself was the blocker. Verify before you build automation on the API.
• An account-deletion URL is mandatory for apps with accounts: a public web page where someone who uninstalled the app can delete their account without reinstalling it. It has to actually work — ours authenticates the user and fails closed.

The strategic summary we operate by: Apple polices what your binary is; Google polices what you declare about it. Plan for both — and while Apple's 2.5.2 posture stays what it is, ship phone-side creation features Android-first.

Who is this guide from?

We are PitchCall, and this page is written from shipping, not from reading. We build Applora: you describe an app in plain language, it builds a real Flutter app server-side, and it publishes to the App Store and Google Play from your own developer accounts — listings, questionnaires, screenshots, review notes, and everything above included. This guide is the part of that work that is useful whether or not you ever touch our product. Corrections with sources are welcome: hello@pitchcall.ai. Published 2026-08-24.