DEV Community: Ship Desk

Fixing ITMS-91053 "Missing API declaration" in a Capacitor/Flutter app: a plain guide to PrivacyInfo.xcprivacy

Ship Desk — Tue, 13 Oct 2026 12:25:12 +0000

If you shipped an app built with Capacitor or Flutter and uploaded a build to App Store Connect, you may have gotten an email that starts like this:

ITMS-91053: Missing API declaration - Your app's code in the "App" file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryUserDefaults.

It looks alarming, especially the first time. It usually isn't a rejection. It's Apple telling you that your build, or one of the native frameworks bundled inside it, calls a system API that Apple classifies as "required reason," and no privacy manifest in the build declares an approved reason for that call. Apple has required these declarations for new uploads since May 2024, and as of 2026 it applies to Capacitor, Flutter, React Native and any other wrapped app the same way it applies to a fully native one.

This post is a plain walkthrough of what the message means, how to read which file Apple flagged, how to pick a reason code honestly, and where the resulting file goes in a Capacitor or Flutter project. I work on rejection triage for wrapped apps, so this is written from what actually shows up in those emails, not from a general reading of Apple's docs.

What the email is actually telling you

Read the message closely. It names two things: an API category (for example NSPrivacyAccessedAPICategoryUserDefaults, NSPrivacyAccessedAPICategoryFileTimestamp, NSPrivacyAccessedAPICategorySystemBootTime, or NSPrivacyAccessedAPICategoryDiskSpace) and a file where the code referencing that API lives, quoted as "code in the '...' file references."

That file name matters more than people expect. It's usually one of two things:

Your app's own binary ("App"). This includes any code statically linked into your app target, including plugin code that got compiled directly in.
A framework bundled separately, shown as a path like Frameworks/Capacitor.framework/Capacitor or Frameworks/SomePlugin.framework/SomePlugin.

The distinction decides who has to fix it. If Apple points at your app file, the fix belongs in your app's own PrivacyInfo.xcprivacy. If Apple points at a framework, that framework needs its own manifest, and your app's file does not cover it, no matter what you put in it. In that second case, the real fix is usually: update the plugin to a version that ships its own manifest.

For Capacitor apps this often means updating the core: current Capacitor versions (4.8.2, 5.7.4, 6.0.0 and 7.0.0 and later by major version, per Capacitor's own documentation) include their own manifest for the framework's known API use. Running npx cap sync ios after updating pulls that in. If the flagged framework name matches a Capacitor plugin package rather than the core, update that specific @capacitor/* package.

For Flutter, the flagged framework is usually the Flutter engine itself or a Dart plugin compiled into a native framework. Names ending in _foundation, _ios, _darwin, _plus, or sqflite-style packages are common. The fix is flutter pub upgrade on the specific plugin, followed by pod install in ios/.

One honest caveat: not every plugin has caught up. If no updated version exists that ships a manifest, you either wait, ask the maintainer, or replace the dependency. There isn't a way to declare on a third-party framework's behalf.

When it's your own app's job

If the flagged file is your app binary, you need a PrivacyInfo.xcprivacy in your own app target, and for each category Apple named, at least one reason code that actually matches what your code does.

The most common category in wrapped apps is user defaults (NSPrivacyAccessedAPICategoryUserDefaults), usually triggered by @capacitor/preferences, Flutter's shared_preferences, or similar storage plugins. If your app only reads and writes its own settings, the fitting reason is CA92.1, "read and write data that only this app can access." That's the common case. It is not correct if you're sharing data with an app extension or widget through an App Group; that's 1C8F.1 instead. And it does not cover reading data other apps or the system wrote, or writing data other apps can read; there's no code for that, because the API doesn't support it.

File timestamps (NSPrivacyAccessedAPICategoryFileTimestamp) show up from filesystem and cache plugins: @capacitor/filesystem, path_provider, sqflite, image caching libraries. If the code only reads metadata of files inside your app's own container, that's C617.1. If users pick files through a document picker, add 3B52.1 for that separately; it's a different reason for a different access pattern, and picking one doesn't cover the other.

System boot time (NSPrivacyAccessedAPICategorySystemBootTime) usually comes from timers, animations, or analytics SDKs measuring elapsed durations. 35F9.1 covers measuring time between in-app events; 8FFB.1 covers computing absolute event timestamps from boot time. These are close but distinct: the difference is whether boot time itself ever leaves the device (it must not, under either) and what exactly you're calculating.

Disk space (NSPrivacyAccessedAPICategoryDiskSpace) is common with download, caching, or device-info plugins. E174.1 fits checking free space before writing or cleaning up when space is short, but the API requires your app to behave differently in a way users can see, not just log a number quietly. 85F4.1 fits only if you actually display free space to the user.

The pattern across all of these: don't pick the code that sounds closest, pick the one that matches what your code observably does, because Apple can review manifest entries against actual behavior. If you're not sure which plugin is responsible for a category with no clear file hint, that's worth checking in your plugin list before guessing a reason code.

A minimal example

Here's a minimal manifest for an app that only stores its own settings locally and doesn't track:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyTracking</key>
    <false/>
    <key>NSPrivacyTrackingDomains</key>
    <array/>
    <key>NSPrivacyCollectedDataTypes</key>
    <array/>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

Set NSPrivacyTracking to true and list your tracking domains only if the app actually tracks users across other companies' apps or sites. This is a separate question from the required-reason APIs above, and it's worth double-checking your App Store Connect App Privacy answers match whatever you put here.

Where the file goes

Capacitor: ios/App/App/PrivacyInfo.xcprivacy, added to the App target in Xcode (File > New File > App Privacy, or drag in an existing one and check "Add to target: App" in the file inspector). It has to actually be a target member, not just sit in the folder, or Xcode won't bundle it.
Flutter: ios/Runner/PrivacyInfo.xcprivacy, added to the Runner target the same way.

After adding it, do a clean build and re-upload. If the earlier ITMS-91053 only listed your app file's categories and you addressed all of them, the email won't return for those categories. If it still lists a framework path, that one wasn't yours to fix with this file; go back to updating that plugin.

It's a warning until it isn't

As of when this was written, ITMS-91053 by itself is usually informational: the build still uploads. But Apple has been tightening this, and a missing or wrong manifest can turn into a Guideline 5.1.2 rejection at review, particularly when it's paired with App Privacy answers that don't match what the app does, or an SDK doing something the manifest doesn't disclose. Don't defer it because the email didn't block the upload; treat the categories it lists as a fix, not a note to file away.

If you want to skip the copy-paste plist writing: we built a free generator that takes the ITMS-91053 email text, shows you which categories came from your app versus a framework, and walks you through reason codes with plain-English explanations for each. No signup, and nothing is sent off your device: https://neumax-labs.github.io/privacy-manifest.html

Related, if you build with Claude Code: the ebook Shipping with Claude Code and the Claude Code harness pack.

How to write App Review notes that stop the "Information Needed" rejection (Guideline 2.1)

Ship Desk — Tue, 29 Sep 2026 13:01:06 +0000

If you shipped an app from Lovable, Bolt, v0, or Replit and got a Guideline 2.1 rejection that just says "Information Needed," the good news is that it's usually not a bug. It's a question. The reviewer could not get far enough into your app to judge it, and in most cases that means they hit a login screen with nothing to sign in with.

This one is worth fixing carefully, because it's avoidable in a way crashes aren't. A crash needs debugging. A missing demo account just needs you to fill out a form correctly before you submit.

Why this happens with AI-built apps specifically

Builder-tool apps tend to get tested by exactly one person: the person who built it, already signed in, on their own phone, with their own data already in the app. The reviewer is the opposite of that. They are a stranger, on a device you probably didn't test on (iPad shows up a lot), with a brand-new account and zero saved state.

That gap between "works for me" and "works for a stranger with nothing" produces most of the Information Needed findings we've seen. The App Review Information section in App Store Connect is supposed to close that gap, but it often gets left half-filled when you're rushing a submission out.

What the reviewer actually needs from you

Five things, roughly in the order they'll hit them:

1. A demo account that works on a fresh device, right now. Not the account you used six weeks ago. Not an account behind email verification or an SMS code. A reviewer cannot check their own phone or a shared inbox for a code, so any account that requires one is functionally the same as no account at all.

2. Where the paid features are. If your app has a subscription or in-app purchase, tell the reviewer how to reach it. Don't make them guess through five screens to find the paywall, and don't assume they'll stumble into it the way an ordinary user might.

3. How to reach account deletion. This is a separate guideline (5.1.1(v)) but reviewers often check it in the same pass, and if your demo account doesn't have visible access to whatever menu holds it, that's a second rejection stacked on the first one.

4. What any hardware feature does, and how to test it without the hardware. If your app uses a barcode scanner, Bluetooth device, or camera-based feature tied to physical equipment the reviewer doesn't have, explain in the notes what the feature does and, if possible, provide a way to see the result without the hardware (a demo mode, sample data, a video isn't a replacement but a clear text description is better than silence).

5. A sandbox purchase path that actually completes. If you have in-app purchases, the reviewer may try to buy one. Make sure the sandbox product IDs match what's in App Store Connect and that a purchase completes end to end, since a paywall that errors out or spins forever produces a related but separate rejection (2.1(b)), and it's worth ruling out before you submit.

A copy-paste notes template

Fill in the brackets and delete anything that doesn't apply to your app. Keep it to three to five lines if you can; a wall of text gets skimmed, not read.

Demo account:
Username: [demo email or username]
Password: [current password, tested today]

After signing in, tap [screen/tab name] to see [the main feature].

Paid features are under [path, e.g. "Settings > Upgrade"]. The demo
account is on the [free / trial / active subscription] plan.

Account deletion is under [path, e.g. "Settings > Account > Delete
Account"].

[If applicable] This app uses [hardware, e.g. a Bluetooth scale /
barcode scanner]. Without the hardware connected, [what the reviewer
will see instead, or how to see sample results].

Before you submit, log in with that exact account on a device you haven't touched in a while, in a fresh browser session or after signing out completely. If anything in the notes is stale, the reviewer will find it before you do.

Four mistakes that cause this rejection even when the notes exist

The demo password expired. A lot of these accounts get created once, at launch, and never touched again. If your backend expires passwords or sessions after 90 days, or if the account got swept up in a "clean up test users" script, the reviewer hits a login error and reports it as Information Needed even though notes were technically provided.

Two-factor authentication is on for the demo account. If your auth provider defaults to requiring 2FA for new accounts, that setting can quietly apply to your reviewer account too. The reviewer has no way to receive that code, and there's no field in App Store Connect for you to hand it to them. Turn 2FA off for this one account specifically, or build a separate reviewer role that bypasses it.

The notes describe a screen that moved. You wrote the notes for version 1.0, and by the time review actually happens you're on 1.3 with a redesigned nav bar. "Tap the third icon on the bottom" is now wrong. Notes describing paths through the UI go stale fast if you're shipping frequently, so it's worth a thirty-second check on every submission rather than assuming last time's notes still apply.

Marketing copy pasted into the notes field. The App Review Information notes field is not the App Store description. A reviewer reading "Revolutionary AI-powered productivity for everyone!" instead of "tap Projects to see the main feature" has to guess where to click, and guessing is exactly what produces the rejection you're trying to avoid. Write the notes like you're handing a stranger a set of directions, because that's what they are.

One more thing worth knowing

Not every Information Needed rejection requires a new build. Once you fix the App Review Information (demo account, notes, whatever was missing), you can usually reply in the Resolution Center without resubmitting a build at all. Save the new-build cycle for actual bugs; a missing or broken login is a paperwork fix, not a code fix.

If you want the fuller breakdown of what a 2.1 rejection can mean beyond Information Needed, including crashes, broken flows, and purchases the reviewer couldn't reach, I wrote a longer reference here: https://neumax-labs.github.io/guideline/guideline-2-1-app-completeness.html

7 two-minute tests to run before App Review (for Lovable/Bolt/v0/Replit apps)

Ship Desk — Sun, 27 Sep 2026 13:03:44 +0000

If you shipped your app with an AI builder, there's a good chance you've only ever opened it as yourself: same phone, same account, already signed in, always online. That's exactly the situation App Review never tests. A reviewer is a stranger with a fresh device, no history, and a habit of doing the one thing your happy path never expects.

Most rejections we've seen for AI-built apps aren't about missing features. They're about a two-minute scenario nobody ran before hitting submit. Here are seven of them, each cheap enough to run tonight.

1. First launch in airplane mode

What to do: Delete the app, reinstall it, turn on airplane mode, then open it for the first time.

What failure looks like: A blank white screen, an infinite spinner, or a crash. Nothing tells the person what happened or what to do next.

Why it matters: A reviewer sometimes tests on a poor or absent connection, and a failed first fetch that leaves a blank screen reads as a crash, not a network hiccup. This is a fast, common failure in apps built by wrapping a web app in a native shell, because the shell's first load usually depends on a network call that has no fallback. The fix is small: catch the failed request and show a message with a retry button. A reader pointed out this exact test after reading our full checklist, and it's now one of the fastest ways to fail an app that otherwise works fine.

This falls under Guideline 4.2, minimum functionality: whether the app is "sufficiently different from a mobile browsing experience" and behaves like a native app rather than a website with no error handling.

2. Fresh install on an iPad

What to do: If you built for iPhone, install the app on an iPad (a simulator is fine) and check both orientations.

What failure looks like: Layouts that overlap, buttons cut off at the edge, text that doesn't reflow, or a screen that only works in portrait when the reviewer tries landscape.

Why it matters: Review often runs on an iPad even for apps that were designed and tested only on iPhone. Many builders assume the reviewer uses the same device class you developed on. They frequently don't, and a broken iPad layout is treated the same as a broken iPhone layout: an app that doesn't work is an app that doesn't work, regardless of which guideline number ends up on the rejection.

This can land under Guideline 2.1, app completeness, the umbrella category for "the app doesn't function as submitted."

3. Sign up as a stranger on the free plan

What to do: Create a brand-new account using an identity you've never used with the app before, ideally a fresh Apple ID with "Hide My Email" turned on, and go through the free tier, not your own admin or test account.

What failure looks like: The sign-in call succeeds, but the screen doesn't change until you force-quit and relaunch. Or the account lands in a state your team never designed for, like a plan with no default data.

Why it matters: We've seen a real case where sign-in technically worked but the UI stayed frozen on the login screen until the app was restarted, and Apple reported it simply as "not responsive." Your own account has weeks of history and cached state that hides this. A stranger's account has none of that, so it exposes the empty states you never built a screen for.

If the app offers Google or another third-party login, this test also covers Guideline 4.8: Sign in with Apple needs to be offered as an equal option, using Apple's button style, and it needs to actually respond when tapped.

4. Delete the account from inside the app

What to do: Find the account deletion option and use it, end to end, on a real device, then confirm the account is actually gone rather than just logged out.

What failure looks like: There's no deletion option at all, or it only signs the user out, or it's buried three menus deep in a place nobody would look, or it just deactivates a flag in the database without deleting anything.

Why it matters: Guideline 5.1.1(v) requires that any app supporting account creation must let users initiate deletion from inside the app, and Apple sometimes asks for a screen recording of the flow on a physical device. AI builders generate sign-up and log-out by default because those are the common tutorial flows; deletion is rarely part of the template, and when someone adds it later, it tends to end up in the wrong place or short of "actually delete the data."

5. Restore purchases

What to do: If you sell anything through In-App Purchase, buy it on a sandbox account, delete and reinstall the app, then tap "Restore Purchases" instead of buying again.

What failure looks like: Nothing happens, the button doesn't exist, or the restored state doesn't match what the person actually paid for.

Why it matters: This sits close to Guideline 3.1.1, in-app purchase. Product IDs need to match exactly between App Store Connect and your billing code, and a mismatch is what makes a paywall come up empty or a restore silently fail for the reviewer. It's also good practice: a real user who reinstalls and can't get back what they paid for is a fast route to a one-star review and a refund request.

6. Deny every permission prompt

What to do: Go through the whole app and tap "Don't Allow" on every permission request: camera, photos, location, microphone, contacts, notifications, whatever the app asks for.

What failure looks like: A feature that just silently does nothing, a crash, or a dead-end screen with no way to grant the permission later without deleting the app.

Why it matters: This connects to Guideline 5.1.2 privacy questions and general completeness. Every prompt is supposed to explain, in a full sentence, why it's asking, something like "Used to attach photos you choose to your notes," not just the OS default text, and only when the user reaches that feature, not all at once at launch. Beyond the wording, the app still needs to work, or at least fail gracefully, when someone says no. Reviewers deny prompts more often than typical users do, since it's a standard part of how they test.

7. Demo account from the review notes, on a fresh device

What to do: Take the demo credentials exactly as you wrote them in App Review Information, and log in with them on a device or simulator you haven't touched before, following only what the notes say.

What failure looks like: The password has expired or was tied to a test environment that got reset, the account triggers an SMS or email verification step nobody mentioned, or the notes describe a screen that no longer exists because the app changed since you wrote them.

Why it matters: A missing or broken demo login is one of the more common causes of an "Information Needed" hold under Guideline 2.1, and it's entirely self-inflicted. The credentials were fine when written, but nobody rechecked them against the build actually being submitted. If the account needs email or SMS verification to get past login, it isn't a working demo account, and reviewers won't chase down a second factor to get in.

None of these take longer than a coffee break, and together they catch the failures that show up disguised as random-looking guideline numbers on a rejection. The full pre-submission list these came from, with plain-language explanations of each guideline, is free here: https://neumax-labs.github.io/checklist.html

What each App Store rejection guideline actually means for AI-built apps

Ship Desk — Sat, 26 Sep 2026 17:12:13 +0000

If you shipped your app with Lovable, Base44, Bolt, v0, Replit, or another AI app builder — or you're driving Claude Code / another coding agent directly — you'll eventually hit one of a small set of App Store rejections that show up over and over for this category of app. The guideline number Apple prints is a category, not a diagnosis, and treating it as a diagnosis is the single most expensive mistake you can make: it costs a full review cycle (typically 2-4 days) per wrong guess.

This is a plain-language breakdown of the five guidelines that account for most rejections in AI-built apps: 2.1 (App Completeness), 4.2 (Minimum Functionality), 4.8 (Login Services), 5.1.1(v) (Account Deletion), and 3.1.1 (In-App Purchase). For each one: what Apple actually means, why it shows up disproportionately in AI-built apps, and what fixing it actually looks like.

Why AI-built apps hit these specific five

There's a pattern behind why these guidelines cluster together for this category of app, and it's worth naming before going through them individually.

Apps built quickly with an AI builder or coding agent tend to pass their first review and fail later ones. The first version usually has a small "review surface" — maybe just email sign-in, no payments, no social login. Then over a few weeks the surface grows: Google sign-in gets added, then Apple sign-in, then in-app purchases, then an invite-code system. Each addition doubles what a reviewer can touch. And because testing tends to mean "click through it myself, logged in as me," nobody walks the new areas the way a stranger with a brand-new account would.

None of the five guidelines below are really about code quality. They're about what a reviewer, acting as a first-time user with no history in the app, can and cannot do.

2.1 — App Completeness

What it actually means: the reviewer hit something that didn't work — a crash, a button that does nothing, an endless spinner, a blank screen, a link to nowhere. Apple reviews on real, current devices, often an iPad even if you only designed for iPhone.

Why AI-built apps hit this: the most common cause isn't a bug in the traditional sense — it's a login or sign-up path that works fine for the account you've been testing with (which has months of history and every permission already granted) but fails for an account created fresh, thirty seconds before the reviewer clicks the next button. A second common cause: the layout was designed and tested on a phone simulator and never opened on an iPad, so a control is off-screen or covered.

What "fixed" actually looks like: get the exact device and OS from the rejection notice (open the submission in App Store Connect and read the full message — the summary email and the version-page banner are not the full text). Walk the exact path the reviewer describes with a brand-new account, not your logged-in one. If you genuinely cannot reproduce it, don't guess and resubmit — reply and ask for the exact reproduction steps. Apple's follow-up often names the real cause in one sentence, and that sentence is worth more than three days of guessing.

One thing worth knowing before you guess: a wrong hypothesis chased for days is a common trap here. If the rejection says "not responsive" and you can't reproduce it, the honest reply — "we could not reproduce this on [devices tested]; could you share the exact steps?" — is a better use of a review cycle than shipping five plausible-looking fixes and hoping one of them was right.

4.2 — Minimum Functionality

What it actually means: Apple thinks the app is a website in a wrapper, offering nothing a browser tab doesn't already give you. This is the single most common rejection specifically for apps made with web-based AI builders and then wrapped for iOS (Capacitor, WebView-based shells, etc.) — it exists almost entirely for this category of app.

Why AI-built apps hit this: the builder generates a responsive web app, and the path to "iOS app" is often just wrapping that same web app in a native shell with no additional native behavior. Apple can tell. Browser-style navigation (back arrows, links opening inside the wrapper), a blank white screen with no connection instead of an offline state, and zero use of anything the phone actually offers (notifications, camera, share sheet, haptics) are the tells.

What "fixed" actually looks like: this isn't a bug fix, it's an addition. You need at least one or two things that are specific to being on a phone: push notifications when something relevant happens, camera or photo input, a proper offline screen with cached content instead of blank white, a native tab bar instead of the website's header/footer. When you reply to Apple, name the specific native features you added — "we improved the app" gets you the same rejection again. "Build 1.2 adds push notifications when a booking is confirmed, offline access to saved items, and share-sheet export of reports" gets read.

4.8 — Login Services

What it actually means: you offer a third-party login (Google, Facebook, etc.) but not one that meets Apple's privacy conditions — in practice, Sign in with Apple. Or Sign in with Apple exists but is broken.

Why AI-built apps hit this: most auth templates generated by builders default to "Continue with Google" because it's the most common OAuth example in training data and documentation, and nobody adds the Apple equivalent until Apple asks for it. It's genuinely one of the cheaper fixes on this list — most auth providers (Supabase, Firebase, and others) support Sign in with Apple as a checkbox-level feature — but it has to be wired into your entitlements file and your backend's auth settings, not just added as a button.

A specific failure mode worth knowing in advance: Sign in with Apple can be technically working — the user genuinely signs in — while the app never tells the screen. This happens when the app decides "is this user signed in?" by checking a profile record that loads a moment after the sign-in session is created, rather than checking the session itself. Email/password sign-in often accidentally avoids this because of how the code happens to sequence, while Apple sign-in exposes the race. From the reviewer's side, this looks exactly like "not responsive" — tap the button, sign in successfully, nothing happens until you force-relaunch the app. If Apple reports Sign in with Apple as unresponsive, check the step after sign-in completes, not just the sign-in call itself.

What "fixed" actually looks like: add Sign in with Apple at the same size and visual weight as your other sign-in options, using Apple's actual button asset (not a generic apple icon from an icon library — reviewers, and contrast checkers, both notice). Test with an Apple ID that has genuinely never touched your app, including the "Hide My Email" relay option, and confirm the very next screen appears without a restart.

5.1.1(v) — Account Deletion

**What it actually means: **users can create an account inside the app but can't delete it from inside the app. Apple has required in-app account deletion since 2022 — not a support email, not a web form, an actual in-app path.

Why AI-built apps hit this: the feature is very often actually present and still gets rejected, because of where it's placed. A common pattern: account deletion lives on a settings screen that's only visible to users with an admin or elevated role, because "that's where settings live" in the generated UI. If the demo account provided to Apple isn't an admin, the reviewer genuinely cannot find the feature — even though it exists and works. A correct feature can fail review purely because of who's allowed to see it.

What "fixed" actually looks like: "Delete account" needs to be reachable from every account role, not just admins — it only ever deletes the current user's own account, so there's usually no security reason to gate it. Confirm once, then actually delete (or clearly start deletion of) the account and its data, and say in the UI how long that takes. If you use Sign in with Apple, revoke the Apple token as part of deletion. In your review notes, spell out the exact path — "Settings → Account → Delete Account" — rather than assuming the reviewer will find it.

3.1.1 — In-App Purchase Required for Digital Content

What it actually means: the app sells or unlocks digital features or content — premium features, credits, subscriptions to the app itself — using a payment method other than Apple's In-App Purchase, or links out to one.

Why AI-built apps hit this: Stripe checkout is the default payment integration in most AI builder templates, because it's the fastest thing to wire up and it's genuinely the right call for a web product. It is very often the wrong call for the iOS build of the same product. A "Subscribe" button in the iOS app that opens a web checkout for something used inside the app is close to a guaranteed rejection.

What actually needs to change, and what doesn't: the rule turns on what you're selling, not how you built the app. Digital features or content consumed inside the app generally need In-App Purchase. Physical goods and real-world services — deliveries, bookings, in-person coaching — can keep using your own payment processor, because they're consumed outside the app. If you have an "invite code" or similar unlock mechanism, document exactly what it does and doesn't unlock in your App Review notes; reviewers assume the worst about anything that looks like a payment bypass unless told otherwise, explicitly.

One detail that costs people a review cycle for reasons that have nothing to do with code: In-App Purchase product identifiers have to match, exactly, between what your app requests and what's registered in App Store Connect. If a note in your own project log says this was fixed, treat that as a claim about the past, not a fact about today — re-check the live dashboard, with today's date, before relying on it. And a release build that's missing the purchase configuration will show the reviewer a bare paywall error, which reads as a completeness bug even though the cause was a build step, not a bug.

The one habit that generalizes across all five

Every one of these guidelines is really asking the same underlying question from five different angles: what does this app look like to someone with no history in it, on a device you didn't personally test on, following exactly the path described? Read the full rejection text before writing a single line of code in response — the guideline number is a category, the message underneath it is the actual finding, and conflating the two is what turns a two-day fix into a two-week one.

If you want the full decision tree for a specific rejection message — which guideline it maps to, the typical causes for AI-built apps specifically, and a reply template — there's a free rejection decoder here: https://neumax-labs.github.io/decoder.html

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

Ship Desk — Sat, 26 Sep 2026 16:41:22 +0000

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