App Store Guideline 4.2 Minimum Functionality: Diagnose It

What guideline 4.2 minimum functionality says

This is the core of the rule, from Apple's App Store Review Guidelines: "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." Check which number your message quotes. If it says 4.3 Spam, you have a different problem: that rule targets duplicate apps and multiple near-identical submissions. Under 4.2 the app is too thin. Under 4.3 it's too similar to something else. For MVPs, two sub-rules come up most often:

• 4.2.2: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."
• 4.2.3: "Your app should work on its own without requiring installation of another app to function."

Reading your 4.2 rejection message line by line

For a wrapped web app, the reviewer's note usually reads like this: "Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience. As such, the experience it provides is similar to the experience of using Safari. Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store." Here's what each part tells you:

• "Limited user experience... not sufficiently different from a mobile browsing experience." This is the diagnosis. The reviewer is judging the whole app, not one missing feature.
• "Similar to the experience of using Safari." The reviewer compared your app with your website and found them to be the same thing. Navigation, layout and page loads all felt like a browser.
• "Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience." Apple is telling you in advance that the usual quick fixes won't be enough. Plenty of founders add push notifications and resubmit anyway.

Whole product or one weak spot

If your note uses this wording, the reviewer judged the whole product. If it points to one specific weak spot, such as an empty screen or a section that only links out, the problem is narrower. Is your app already a web app in a frame? Then a patch rarely solves the problem. Our AI prototype to production service starts with an audit of what the builder generated and tells you whether to harden it or rebuild it. Then the app gets real iOS and Android screens.

What the reviewer checks before writing that note

You can run the same checks in five minutes on your own phone. For each check, here is what a wrapper shows and what a native app shows. For the full breakdown of why wrappers fail and what a native rebuild involves, see our iOS and App Store guides.

• Opens the app in Airplane Mode. What a wrapper shows: blank screen or browser error. What a native app shows: saved content or a clear offline state.
• Taps through the navigation. What a wrapper shows: web menus and page reloads. What a native app shows: native tab bar, swipe back.
• Compares it with your website. What a wrapper shows: the same pages. What a native app shows: screens built for a phone.

How to fix a guideline 4.2 rejection: patch or rebuild?

Answer these questions honestly before you touch the code:

• Does the app have a core action that only makes sense on a phone (camera, location, quick daily use)? If yes: a native build has a strong case. If no: ask whether you need the App Store at all.
• Is the app mostly your website's pages? If yes: rebuild the screens natively. If no: a patch may work.
• Did you already resubmit once with push or sharing added? If yes: stop patching, the reviewer has seen it. If no: one more careful attempt is reasonable.
• Do users pay for digital content inside the app? If yes: plan in-app purchases in a native build. If no: Stripe on the web may be enough.
• Is the launch tied to a date (investor demo, event, campaign)? If yes: rebuild on a fixed timeline. If no: you have room to test a patch.

Patch, rebuild or wait

Not sure which column you're in? Send us the reviewer's message on a free 30 minute call. Book a call and we'll tell you whether your app can be patched or needs native screens.

• Patch when your app already has native screens and the note points to one weak area, like a missing offline state. Fix that area and say so in your reply.
• Rebuild when the app is your web app in a frame. Every patch puts the same app back in front of the reviewer.
• Wait when your users only need a link and a login. Ship a good mobile web app now and go native later.

What a native rebuild costs

Our MVP package covers your app on the web, iOS and Android. See the details on our MVP development page. Here is what you get:

• Fixed at $3,460. Fixed quote given before we start.
• Around 20 days of work.
• Progress shown every week.
• Design included.
• Code 100% yours, on your GitHub.
• 2 weeks of fixes after launch.

What to write in your App Store Connect reply

Your reply won't change the verdict on an app that hasn't changed. A clear reply does help when you have actually changed it. Keep it short and factual:

• 1. Name the native screens and how to reach them. Write the exact path, for example: "Open the app, tap Scan on the tab bar, point the camera at a receipt." A reviewer can't approve a feature they never find.
• 2. Say what changed since the last build. Give the new build number and list the changes in plain words: "Native tab navigation replaces web menus. The app now opens offline and shows your last saved trips."
• 3. Give working sign-in details. If the core of the app sits behind a login, put a test account in the App Review Information section. Without one, the reviewer may only see your welcome screen.
• 4. Leave out what doesn't help. Don't argue that other apps do the same thing. Don't promise features for a later version. Don't paste marketing copy or explain your business plan. The reviewer tests the app in front of them, not your roadmap.

Mistakes we see after a 4.2 rejection

If you built with an AI tool and you're weighing whether to bring in a developer, our Lovable and AI builder guides cover that decision. The mistakes that come up most:

• Resubmitting the same build with a longer reply. Notes don't replace features.
• Adding features nobody uses. A random map or share button makes the app look padded, and Apple's message already says these aren't enough.
• Hiding the web view behind a spinner. The offline test still exposes it.
• Rebuilding everything at once. Your v1 needs the core loop to be native. Settings and edge cases can come later.

Get your app through review

A 4.2 rejection says your app has to work like an app. It doesn't say your idea is wrong. Send us the reviewer's message and your prototype link. We'll tell you whether a patch will do or what a native build involves, and you'll get a fixed quote before we start. Book a call.

What does guideline 4.2 minimum functionality mean?

It means Apple judged your app too thin for the App Store. Usually it looks like a repackaged website, or it doesn't do enough to be useful as an app.

Can a WebView app pass App Store review?

Some do, when the web content sits inside a real native shell with native navigation, an offline state and device features tied to the main use. A website alone in a frame usually doesn't pass.

How long does it take to fix a 4.2 rejection?

A targeted fix to an app that's already partly native can be quick. A native rebuild of an MVP with us takes around 20 days.

Should I appeal a guideline 4.2 rejection?

Only if you believe the reviewer missed native features your app really has. In that case, reply in App Store Connect and point to the exact screens. If the app is a wrapper, an appeal rarely changes the outcome. Changing the app does.