# Guideline 4.2: why Apple says your app isn't app-like > Apple rejects under 4.2 when an app does nothing the website doesn't. Here's what reviewers compare, and the three ways out of a wrapper rejection. - URL: https://envisageapps.com.au/blog/app-rejected-guideline-4-2/ - Type: post - Published: 2026-08-17 - Tags: app-development, app-developer-brisbane, mobile-app-development ## Why was my app rejected under Guideline 4.2 — Minimum Functionality? Apple rejects apps under 4.2 when they don't do more than the website already does in Safari. If yours was built with Lovable, Bolt or a similar tool and then wrapped, that is usually the reason. The fix is real native capability — push tied to events, offline, biometric sign-in, widgets — not a cosmetic resubmission. Resubmitting unchanged risks a 4.3 spam flag on top. ## Related questions ### Can I just resubmit and explain that my app is different? Resubmitting with an explanation rarely clears a 4.2 rejection on its own. Review is comparing your app against what your website already does, so an explanation that doesn't point at new native behaviour tends to come back with the same guideline. Worse, repeated near-identical submissions are the pattern that attracts a 4.3 spam flag, which is a harder hole to climb out of. ### Does Apple reject apps for being built with AI? No. Apple does not reject code for having been generated, and there is no guideline that says so. It rejects what AI-assisted builds commonly ship: a web view with no native capability, a missing account-deletion path, a demo login that doesn't work, or an absent privacy manifest. The tool isn't the problem; the gaps it leaves are. ### Is a Capacitor or WebView wrapper always rejected? Not always, but the bar has moved. A wrapper that adds genuine native behaviour — push tied to real events, offline that survives airplane mode, Face ID, widgets, share extensions — can pass. A wrapper that only puts a chrome-less browser around the same pages increasingly does not. ### Do I need to rebuild the whole app natively? A full native rebuild is usually not necessary. Most 4.2 rejections Envisage sees are fixed by adding a native layer to what already exists, not by starting again. Which of the two you need is what an audit answers with evidence rather than a guess — and if the honest answer is that your product is a website, we will say so. ## What review is actually comparing A 4.2 rejection is not an aesthetic judgement. The reviewer opens your app, opens your website in Safari, and looks for something the app does that the browser cannot. If the answer is "nothing", the guideline applies regardless of how much work went into it. Apple's own wording is in [App Review Guideline 4.2](https://developer.apple.com/app-store/review/guidelines/#minimum-functionality), and it is shorter than most people expect. This is why the rejection feels arbitrary to founders who have shipped something genuinely useful. Usefulness is not the test. **Native capability is the test.** ## The three ways out **Add a native layer.** Push notifications tied to real events rather than marketing blasts, data that survives airplane mode, biometric sign-in, widgets, share extensions, background sync. One of these done properly usually clears the bar; four done badly does not. **Rebuild the shell.** Where the product depends on capabilities a web view cannot reach — HealthKit, reliable background work, real offline — the wrapper is a dead end and the money spent on it is spent twice. We call that second payment the **wrapper tax**: the cost of paying to wrap a web app, failing 4.2, and then paying again for the native layer that would have passed the first time. It is a tax because it is avoidable, and because the decision that incurs it is made early and cheaply while the bill arrives weeks later in the review queue. Identifying the case before you pay for the wrap is the whole saving. The term, and the rest of the vocabulary we use for these gates, is defined in the [lexicon](/lexicon/#wrapper-tax). **Stay on the web.** Sometimes the honest answer is that the product is a website and does not need an app at all. Saying so costs us a build and saves you one. Working out which of the three applies to your app is what an Envisage [Launch Gate Audit](/launch-gate-audit/) is for — five days, fixed fee, and a two-bucket report separating what blocks launch from what can wait. If you got here because you built with an AI tool and hit the wall, the fuller picture is in [from AI-built prototype to launched product](/built-with-ai/). ## What not to do Do not resubmit the same binary with new screenshots. Do not argue the guideline in Resolution Center without pointing at new behaviour. Both burn review cycles, and the second pattern is what escalates a 4.2 into a 4.3 spam review — a materially worse position, because 4.3 questions whether the app should exist rather than what it does.