You built something in Base44, Replit or Lovable, wrapped it in a WebView, paid the ninety-nine dollars, submitted, and got four sentences back citing guideline 4.2. There is no list of what would be enough, and the obvious next move - resubmit with a longer explanation - does not work.
This is the most common outcome when you publish an AI-built web app to the App Store, and it is worth understanding properly, because the fix is a product decision rather than an appeal.
What the reviewer is actually doing
A human opens your app on a device, uses it for a short time, and forms a judgement about whether it is an app or a website in a frame. They are not running a static analyser looking for a WebView - plenty of approved apps use one. They are asking whether this thing does anything that a Safari tab would not.
So the question to ask about your own submission is not "is it technically a wrapper". It is: in the first thirty seconds, what does a reviewer see that they could not get by typing your URL into a browser? If you cannot answer that in one sentence, the rejection is correct and it will happen again.
Apple is not testing your implementation. They are testing whether the app has a reason to exist on the home screen.
What reliably clears it
In descending order of how convincing they are, from the submissions we have shipped:
- Push notifications that are actually part of the product - a job assigned, an order shipped, a message received - with categories the user can turn off individually. Not a marketing broadcast.
- Genuine offline capability: the data the user already has is readable with no connection, and actions taken offline queue and sync. This is the strongest single signal and it is impossible to fake.
- A device capability the product uses: camera for capture rather than upload, biometrics for unlock, location where the feature depends on it, calendar or contacts integration with a real purpose.
- Native navigation and interaction - a real tab bar, a real stack with swipe-back, a native share sheet, haptics. Cheap to add and it changes the feel immediately.
- Home screen widgets, Siri shortcuts, or Live Activities where the product has a state worth surfacing.
- Handoff, universal links, and app-specific deep links so a link opens in the app rather than bouncing to the browser.
You do not need all six. Two or three that are genuinely part of the product is usually enough, and reviewer notes that point at them explicitly help - not as an argument, but as a map.
What reliably does not
- A splash screen and an app icon. This is the most common attempted fix and it changes nothing.
- Hiding the browser chrome. The reviewer can tell, and it makes the app worse rather than more native.
- A longer explanation in the review notes. The notes cannot substitute for the thing being missing.
- Appealing without changing anything. The appeal board reviews the same binary against the same rule.
- Adding a settings screen with three toggles. It is still a website with a settings screen.
Everything else that gets checked
Clearing 4.2 gets you to the rest of the review, and each of these is small and individually capable of costing you a round trip:
| Requirement | What catches people | Effort |
|---|---|---|
| Account deletion in the app | If a user can create an account in the app they must be able to delete it there. A support email is not enough. | Half a day |
| App Privacy labels | The declaration must match what your SDKs actually collect - including the analytics you added and forgot. | An hour, after a dependency audit |
| Working demo account | Credentials in the review notes that still work and have data in them. Expired demo accounts are a rejection. | Minutes, and easy to forget |
| Login services | Offering Google or Facebook sign-in generally means offering Sign in with Apple alongside. | A day |
| In-app purchase | Digital goods and subscriptions go through IAP. Physical goods and real-world services do not. Rules on linking out differ by region. | Decide before building the paywall |
| Export compliance | A questionnaire, not a task. HTTPS counts as encryption and the exemption still has to be declared. | Minutes |
A sequence that works
- Answer the thirty-second question honestly. If there is no answer, stop and consider whether an installable web app is the right product.
- Pick two or three native capabilities that are genuinely part of the product and build them properly. Offline is the strongest.
- Walk the rest of the checklist before submitting, not between rejections. This is where the weeks are.
- Write reviewer notes that point at the native features by name, with a working demo account.
- Submit. Expect a day or two. If it comes back, read what it actually says rather than what you feared it would say - the second rejection is often a different, much smaller rule.
Written by Kato Chojiro
Takes AI-built MVPs to production: security, data, and the infrastructure underneath.
Connect on LinkedIn