Apple Rejected Your Lovable App Under 4.2. Now What?
“Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.”
If you’re reading this, you’ve probably got that sentence sitting in App Store Connect right now, under Guideline 4.2 - Design - Minimum Functionality. You wrapped your Lovable app in Capacitor or some “website to app” service, paid the $99 developer fee, waited two days, and Apple said no.
You’re in good company. This is the single most common rejection we see on Lovable apps, and it’s not random. The reviewer opened your app, saw your website with the browser chrome removed, and did exactly what the guideline tells them to do.
What the reviewer is actually checking
Apple doesn’t ban WebViews. Plenty of approved apps render big chunks of their UI in one. What they reject is an app where the WebView is the product, and nothing about it uses the phone.
In practice the reviewer spends maybe two or three minutes in your app. A few things make it look like a website instantly:
- a hamburger menu instead of a tab bar
- a “Sign up” page that opens Safari for the magic link and never comes back
- pull to refresh doing nothing, or worse, reloading the whole page with a white flash
- the same cookie banner and footer links you have on the web
One founder we worked with had been rejected three times. Each time they changed something cosmetic, a new icon, a splash screen, a different app name. The fourth submission had the same WebView with the same footer that said ”© 2026, view our website”. Rejected in 40 minutes.
What gets an app through
You don’t need to rebuild everything. You need enough native surface that the reviewer can tell it’s an app. Usually that’s three or four of these, done properly:
Push notifications that do something. Not “allow notifications?” on launch with nothing behind it. An actual notification when the thing the user cares about happens, which opens the right screen when tapped.
Native navigation. A real tab bar for the three to five main sections. This alone changes how the app feels more than anything else on this list.
Device features. Camera for uploads, Face ID sign-in, haptics on key actions, share sheet, offline handling. Pick the ones that fit your product. A habit tracker with a home screen widget reads as an app. A habit tracker in a WebView reads as a bookmark.
Auth that stays in the app. Magic links need Universal Links set up so they open your app, not Safari. And if you offer Google login, Apple will also want Sign in with Apple. That’s a separate rejection (Guideline 4.8) but it tends to show up on the same submission.
When you resubmit, say what changed in the Review Notes. Short and specific: “Added native tab navigation, push notifications for new messages, camera upload, and Sign in with Apple.” Reviewers read those notes. A vague “fixed issues” gets you the same reviewer making the same call.
The honest trade-off
Could you keep patching a wrapper until it passes? Sometimes, yes. We’ve gotten Capacitor apps approved by adding push, a native tab bar and a couple of plugins.
But we’ve also watched people spend a month fighting review on a wrapper and then hit the next wall: the app feels slow, scroll is janky on older Android phones, and the 1-star reviews say “it’s just the website”. At that point a proper Flutter or React Native build that talks to the same Supabase backend is often less work than the next round of patches. The backend, the database and the business logic you built in Lovable all stay. Only the screens get rebuilt.
Which way makes sense depends on what your app does and how much of it is really mobile. A booking tool people use twice a month? A good wrapper might be fine. Something people open daily on their phone? Build it native.
If your app is stuck in review right now, send us the rejection message and your Lovable link. We’ll tell you whether it’s a two-day fix or a rebuild, and if your backend still lives on Lovable Cloud, whether to move it to your own Supabase first.