The App Store checklist for apps built with Lovable/Bolt/v0

If you built your app with an AI app builder (Lovable, Bolt, v0, Replit, or similar) and wrapped it for iOS with something like Capacitor, you're going to hit App Review with a specific set of blind spots. Not because the app is bad — because the tools that generated it optimize for "it works when I click through it," not "it works from a stranger's brand-new account, on the free plan, on an iPad."

This is a stage-by-stage checklist built from actual rejection cycles: real guideline numbers, real causes. It won't guarantee approval — nothing does, Apple reviews every submission and makes the call — but it closes off the failure modes that keep coming back for apps built this way.

Why these apps get rejected in predictable ways

AI-built apps tend to pass their first review and fail later ones. The reason is almost always the same: the first version had a small "review surface" — maybe just email sign-in, no payments, no social login. Then over a few weeks you add Google sign-in, then Apple sign-in, then in-app purchases, then an invite-code system. Each addition doubles what a reviewer can touch. And because the builder tool (and the humans using it) tested by walking the same happy path over and over, nobody ever walked through the new areas as a first-time stranger would.

Keep that framing in mind as you go through this list: every stage below exists because someone, somewhere, shipped a feature that worked for them and failed for a reviewer with no history in the app.

Stage 1 — Before you touch sign-in

If your app offers any third-party login (Google, Facebook, etc.), Apple's Guideline 4.8 requires you to also offer an equivalent privacy-respecting option — in practice, Sign in with Apple. This is not optional and not negotiable, and it's cheap to add early and expensive to retrofit.

• [ ] If you offer any social/OAuth login, Sign in with Apple is also implemented natively (not just as a web view).
• [ ] Sign in with Apple is wired into your entitlements file and your backend's auth settings — not just the button on the screen.
• [ ] You've tested first-time sign-in with every login method on a device that has never used the app before.

The last item matters more than it sounds. A very common bug: the app's "is this a new user, send them to onboarding" logic was written when only one login provider existed, and never updated when a second one was added. Result: a new user via the second provider skips onboarding, has no account state set up, and every subsequent request silently fails. Nothing crashes, nothing shows an error — the screen just sits there, which to a reviewer looks exactly like "this button does nothing."

Stage 2 — Account deletion, and who can see it

Since 2022, Guideline 5.1.1(v) requires that any app letting users create an account must let them delete it from inside the app — not just via a support email, not just via a web page.

• [ ] "Delete account" exists inside the app, not only on a website.
• [ ] It's visible to every account role, not just admins.

That second point trips up more apps than you'd expect. It's common to build a settings screen that's admin-only, and then bury account deletion on it because "that's where settings live." If your test/demo account for reviewers isn't an admin, the reviewer literally cannot find the feature — even though it exists. A correct feature can still fail review because of where it's placed and who's allowed to see it.

Stage 3 — Payments, the part everyone gets wrong once

Guideline 3.1.1 requires that digital features consumed inside the app be sold through Apple's in-app purchase system, with narrow exceptions (mainly for goods/services consumed outside the app). If your builder-generated app routes users to a web checkout for anything used inside the app, expect a rejection.

• [ ] Any paid feature usable inside the iOS app is sold via StoreKit / in-app purchase, not a web redirect.
• [ ] Web checkout, if you have one, is reserved for your website only — not linked or referenced from the iOS app's paywall.
• [ ] Any "invite code" or similar unlock mechanism is documented in your App Review notes explaining exactly what it does and does not unlock. If it doesn't bypass payment, say so explicitly — reviewers will otherwise assume the worst.
• [ ] Your in-app purchase products are registered in App Store Connect and the identifiers match exactly what your app requests. (Mismatches here are a classic case of a note in a project log going stale — re-verify the actual dashboard state with a date, don't trust an old comment.)
• [ ] You can produce a release build that includes the correct purchase configuration — a build without it will just show a paywall error to the reviewer.

Stage 4 — Your demo account, treated as a real submission artifact

A huge fraction of "reviewer couldn't do X" rejections trace back to the demo account, not the code.

• [ ] The demo account in App Store Connect actually logs in, right now, today (test it fresh before every submission).
• [ ] "Sign-in required" is checked correctly in the App Review information if your app needs an account to do anything meaningful.
• [ ] Your review notes describe the current demo account — not a stale one from a previous submission.
• [ ] If your app has subscription tiers, provide a demo account whose subscription state matches what the reviewer needs to test (e.g., an account with an expired subscription if they need to test the renewal/paywall flow).

Stage 5 — Placeholder and unfinished content

Guideline 2.1 (App Completeness) covers a wide net: placeholder content, coming-soon labels, crashes, and unfinished features. AI-generated UIs are prone to shipping placeholder text that never got swapped out.

• [ ] No "your logo here," "lorem ipsum," or similar placeholder strings anywhere in the build a reviewer can reach.
• [ ] No buttons or nav items labeled "coming soon" that lead nowhere.
• [ ] No "beta" language describing the app itself, unless you're actually distributing via TestFlight beta review.
• [ ] Every plan/tier, including the free one, has been clicked through end to end, on the cheapest plan, without crashing.
• [ ] Testimonials or social proof, if present, are attributed to a real, checkable source.

Stage 6 — Test it as a stranger, on an iPad

This is the stage most builder-tool workflows skip entirely, because the builder's preview is usually a phone-sized web view.

• [ ] You've done a full run-through on an actual iPad (not just resized phone simulator), on the free plan, with a brand-new account.
• [ ] You've done the same run-through on a physical iPhone, not just a simulator — some things (Sign in with Apple in particular) behave differently on-device.
• [ ] If Apple's rejection asks for a screen recording, you're prepared to record it on a real device, not a simulator driven by automation. Simulator recordings may be accepted, but a reviewer who explicitly asked for a device recording is telling you they distrust simulator evidence.

Stage 7 — When you do get rejected: get the actual message

This isn't a pre-submission item, but it belongs in the checklist because it changes how you spend the days after a rejection.

• [ ] Don't diagnose from the guideline number alone. "2.1" covers crashes, placeholders, missing features, and broken flows — it is a category, not a specific cause.
• [ ] Open the actual rejected submission in App Store Connect and read the full message text, including any attached screenshots and the device/OS the reviewer used. The summary email and the version page are not the full message.
• [ ] Note the specific device mentioned (e.g., "iPad Air, current iPadOS") — if none of your own testing covered that device, that's your first lead.
• [ ] Match your fix list to what was actually said, not to everything you can find that might loosely relate to the guideline number. It's easy to spend days fixing seven real things when Apple only flagged three — and fixing the wrong six doesn't get you approved.

Stage 8 — Before you resubmit

• [ ] Every item Apple's message named specifically has a corresponding fix, and you can explain the fix in one sentence in your reply.
• [ ] Any external dashboard state you're relying on (payment processor, backend config) has been re-checked today, not assumed from an old note.
• [ ] Your reply to App Review states plainly what changed and, if useful, why the reviewer may have seen the described behavior.

Using this as a running list

None of this is exotic — it's mostly things that are obvious in hindsight and invisible in the moment, because AI builder tools are very good at making the happy path work and say nothing about the paths nobody walked. Treat this less as a one-time pre-submission task and more as a standing checklist you run every time you open up a new area of the app: a new sign-in method, a new plan tier, a new role.

We turned this into an interactive checklist (progress saved locally in your browser, nothing sent anywhere) if you'd rather work through it that way instead of copy-pasting a markdown list: https://neumax-labs.github.io/checklist.html