Rejected Under Guideline 4.2? Here's the Honest Decision Tree

• Appeal only if the reviewer made a factual error (missed features behind a login). Otherwise you burn 1–3 weeks in Resolution Center limbo.
• Bolt on native features (APNs push, Face ID, native tabs, offline) improves your odds — but it's still a WebView underneath, so reviewers vary and each retry costs a cycle.
• Rebuild in React Native is the only path that removes the 4.2 category entirely. Real UIView, not DOM in a browser shell.
• The real question isn't "how do I pass review" — it's "how many review cycles can I afford to lose finding out?"

---

You shipped it. You waited. Then the email arrived:

Guideline 4.2 — Design — Minimum Functionality
We found that the experience your app provides is not sufficiently different from a web browsing experience, as it would be if displayed in Safari.

Here's the thing nobody tells you up front: most advice about 4.2 is written by people selling WebView wrappers. Their answer is always "add push notifications and resubmit," because their business depends on that working.

Sometimes it does. Often it doesn't. This is the honest version.

What Apple is actually saying

The full guideline text:

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or "app-like," it doesn't belong on the App Store.

The operative word is "elevate." Apple isn't banning web technology — plenty of major apps use WebViews internally. What they're rejecting is the ratio: an app whose primary value is showing you a website you could have visited in Safari.

That tells you what reviewers actually measure. Not "does this contain a WebView," but "would a user be worse off just using the browser?"

Your three options

Diagram released under CC0 — reuse it freely.

Path 1: Appeal

Reply in Resolution Center arguing the reviewer missed something.

Works when it's true. If your app genuinely has native features the reviewer didn't find — behind a login, or three taps deep — a targeted reply with screenshots pointing at specific capabilities does get decisions reversed.

Fails badly when it isn't. The Apple Developer Forums are full of people two weeks into an appeal with no response, watching a launch window close. One developer's app was tied to an event launching the following week, with the appeal pending a fortnight and no update.

Appeal if the reviewer made a factual error. Don't appeal to argue taste.

Path 2: Bolt on native features

The standard vendor advice: add push notifications, Face ID, offline caching, native tab navigation. Resubmit.

This is real advice and it does work — reviewers respond to APNs push especially, because it's hard evidence of native platform integration. Face ID is the other easy win.

But be clear about what you're doing: you're improving your odds on a dice roll, not removing the dice. The app is still a WebView underneath. Reviewers vary. The same binary that passes with one reviewer gets bounced by another, and each attempt costs a full review cycle.

Pattern worth watching: if you've bolted on features twice and been rejected twice, a third attempt is usually not the highest-value use of your week.

Path 3: Rebuild the UI natively

Move the interface to React Native (or Flutter). These compile to actual native UI components — real UIView and UIButton instances — rather than rendering DOM inside a browser shell.

This is the one option that removes the rejection category entirely. You're no longer in the "repackaged website" bucket, so 4.2 stops being a thing that can happen to you.

Honest cost: a genuine rewrite of your UI layer. Business logic, API calls, Supabase queries — those largely survive. The components don't.

The question worth asking

The reframe that actually helps:

The question isn't "how do I pass review?" It's "how many review cycles can I afford to lose finding out?"

Each rejection-and-resubmit loop is roughly a week. Pre-launch with no deadline? Gambling on Path 2 is cheap and reasonable. Launch date, investors, a client waiting? The expected cost of two more failed cycles usually exceeds the cost of doing the rebuild once.

It's a business calculation more than a technical one.

If you're coming from Lovable, v0, or Bolt

A lot of 4.2 rejections trace back to the same origin story.

You built a web app with an AI builder. It's good. Then you tried to ship it and discovered these tools generate React web apps — they don't produce native binaries. The App Store takes compiled .ipa files; Google Play takes .aab. A React web app compiles to neither.

So people reach for a wrapper, and land here.

If that's your path, Path 2 is a particularly weak bet — your app is the website, structurally, and there's not much to elevate. Path 3 is where you were always going to end up.

The rebuild is more mechanical than it sounds: your Supabase backend connects to a React Native app without migration, and your API layer ports mostly unchanged. It's the component tree that needs redoing.

If you'd rather not do that project yourself, RapidNative converts Lovable apps into real React Native + Expo builds and handles the full App Store and Play Store submission — signing, screenshots, and metadata included, with source code and full ownership.

The checklist, if you're taking Path 2 anyway

Sometimes bolting on is the right call — tight deadline, genuinely content-heavy product. Prioritise in this order:

1. APNs push notifications. Strongest single signal to a reviewer.
2. Face ID / Touch ID. Native API usage, easy to implement, easy to see.
3. Native tab bar and navigation. Not a hamburger menu rendered in HTML.
4. Real offline handling. If it shows "No Internet Connection" like a browser, that's a rejection risk on its own.
5. Rewrite your App Store description. If it says "access our website on your phone," you're asking for the rejection.

Three of these is roughly the threshold where reviewers start passing wrapper apps.

The takeaway

Guideline 4.2 isn't Apple being arbitrary. It's a floor on what an app is, and wrappers sit right on that line by design.

Appeal when the reviewer was factually wrong. Bolt on features when you have time to gamble. Rebuild when the launch actually matters.

Whichever you pick — pick it deliberately, rather than defaulting into another resubmit because it feels like the smaller decision. It usually isn't.

---

Been through a 4.2 rejection? Which path did you take, and did it work? The data on what actually passes is mostly anecdotal — more anecdotes would help everyone.