Apple isn't rejecting AI-built apps. It's rejecting apps that look AI-built.

I build mobile apps. AI has made the build phase almost free — and made the last mile, getting through review, the part that actually decides whether you ship. Here's what I've learned, and the checklist I now run before every submission.

Give an AI coding tool a clear prompt and you get auth, a database layer and six working screens in a weekend. The boilerplate is gone.

Then you hit submit in App Store Connect, and everything stops.

The headline everyone gets wrong

"Apple is rejecting AI-built apps" isn't true, and chasing that story wastes your time.

Apple ships AI coding integrations inside Xcode. Nobody is reading your commit history.

Two separate things happened in 2026 and got compressed into one bad headline. In March, Apple blocked updates for vibe-coding platform apps like Replit and Vibecode under Guideline 2.5.2 — the rule against apps that download and execute code at runtime. That's about runtime execution, not authorship.

Separately, ordinary apps built with AI get rejected constantly under the ordinary quality rules. A reviewer opens your app, uses it for four minutes, and decides whether it feels like a real product.

The four guidelines that actually catch you

4.3 — Spam. The biggest bucket. AI produces competent, conventional UI, which is exactly the problem. When a hundred near-identical habit trackers land in the same week, reviewers stop evaluating and start pattern-matching. Rewrite at least half the generated UI and kill every placeholder.

4.2 — Minimum functionality. A WebView in a native shell isn't an app. Reviewers look for platform intent: widgets, App Intents, Live Activities. Generated scaffolds never include these unless you ask.

2.1 — Complete and functional. One crash in review is an instant rejection. AI code breaks on the cases your prompt never mentioned — airplane mode, denied permissions, empty states, malformed responses.

2.5.2 — Self-contained code. No fetching and executing logic from a server. Remote config that changes behaviour sits in dangerous territory.

Google Play isn't the escape hatch either — closed testing before production access, plus a Data Safety declaration that has to match what your code genuinely collects. AI-generated code routinely requests permissions it never uses, and the manifest gives you away.

The checklist I run before every submission

1. Break it on purpose. Airplane mode, denied permissions, empty states, malformed API responses, rapid back-navigation. Fix every crash before a reviewer finds one.

2. De-template the UI. If it looks like default AI output, it gets treated as default AI output.

3. Add native depth. At least one widget, App Intent or Live Activity — proof the app was built for the platform, not ported onto it.

4. Audit permissions. Every entry in the manifest must be used and justified. Delete the rest.

5. Match the privacy manifest to reality, including what third-party SDKs collect.

6. Confirm it's self-contained. No dynamic code loading, no behaviour-changing remote config.

7. Write reviewer notes. Demo account, core user flow, one line on what makes the app distinct. Free, and almost everyone skips it.

Already rejected? A cosmetic resubmission almost always fails. The appeal that works names the specific things making your app distinct in the first paragraph — reviewers work in short windows.

Where this leaves us

The bottleneck has moved. Generating a build isn't the scarce skill anymore. Getting it approved is.

That last 10% — hardening edge cases, de-templating the interface, aligning permissions and privacy manifests, adding real native functionality, writing appeals that get overturned — is where I spend most of my time now, on my own builds and on other people's.

If you've got an AI-assisted app stuck in review, or you'd rather have it audited before you submit and spend a rejection finding out, message me. It's a faster conversation than a second rejection.