shipcheck

Guideline 4.2 — minimum functionality

Updated September 6, 2026 · published by Baker Ventures LLC · sources cited inline

Guideline 4.2 is a reviewer deciding whether your app does enough to justify existing as an app. Apple's framing is that an app should include features, content and UI that elevate it beyond a repackaged website, and that something which is simply a song, a book, a marketing page or a thin web view may not be appropriate for the App Store.

This is the one class of rejection no static tool can predict, including ours. There is no file to check. It is judgement, applied by a person, in a few minutes, against an app they have never seen.

What you can do is remove the reasons a reasonable person would reach that judgement — and most 4.2 rejections come from a small number of recognisable patterns rather than from an app genuinely being too thin.

The patterns that trigger it

A wrapped website. The most common. If the app is substantially a WebView pointed at your responsive site, the reviewer's question is why this is not a bookmark. It is not automatically fatal — but the burden is on you to show it does something a browser does not.

The value is behind a login the reviewer cannot pass. If the app looks empty until you have an account with data in it, and the demo credentials do not work or the demo account is empty, the reviewer sees an empty app. This is frequently misfiled as a 4.2 problem when it is really a Guideline 2.1 problem — and the fix is a working, seeded demo account. Review notes that work.

A single feature a mobile browser already does. A currency converter, a unit converter, a QR reader with nothing around it.

The good part is three screens deep. Reviewers do not explore. If the thing that justifies the app is behind an empty state and two taps, say so explicitly in review notes with the exact path.

A marketing app. An app whose content is entirely about your company, with no utility for the user, is precisely what the guideline names.

What actually helps

Genuine platform integration. Push notifications tied to real events, offline capability, Share Sheet extension, widgets, Siri and App Intents, background processing that serves a real feature, camera or location used for something the web cannot do. Each of these is an answer to "why is this not a website."

Native navigation and interaction. An app that scrolls like a webpage inside a shell reads as a shell.

Offline. The single clearest differentiator from a website, and frequently the easiest to add for a React Native app that already caches data.

A first minute that shows the point. Not onboarding — value. If a reviewer can reach the thing that makes your app worth installing within a minute of launch, 4.2 mostly stops being a risk.

Seeded demo data. A populated demo account converts "this app appears to do nothing" into "this app does a thing." It is the cheapest fix on this page.

What does not help

Arguing the guideline. A Resolution Center reply explaining that you believe your app has sufficient functionality is a reply about opinions. One that says "the offline sync and the widget are what make this more than our website; here is where to find them" is a reply about the app.

A feature list. They can see the app. Tell them where to go.

Adding filler. Bolting on a settings screen and a tip jar does not change the judgement, and it makes the app worse.

The 4.3 cousin

Guideline 4.3 (Spam) covers duplicate apps and apps that are one of many near-identical submissions. It is a related judgement and it catches template-built apps, white-label reskins, and categories with a lot of similar entries. Also unpredictable by any tool. Guideline 4.3 in detail.

Where a pre-submission scan actually helps

Not with 4.2 itself, and we are not going to claim otherwise. But several of the things that cause a 4.2 rejection are checkable:

Those are deterministic and local. The judgement on top of them is not, and shipcheck says so rather than pretending. What it checks — and what it will not do.

No tool can guarantee approval under 4.2. Anything claiming to predict a minimum-functionality outcome is selling certainty that does not exist. The honest claim is narrower: remove the avoidable reasons a reviewer reaches that judgement, and make the app-specific value impossible to miss.

Questions and answers

What is App Store Guideline 4.2?

Minimum Functionality. Apple's position is that an app should include features, content and UI that elevate it beyond a repackaged website, and that apps which are simply a song, a book, a marketing page or a web view may not be appropriate for the App Store. It is a judgement call by a reviewer rather than a checkable rule.

Why did my app get rejected for minimum functionality?

Usually one of a few patterns - the app is substantially a wrapped website, the core value is not reachable without a login the reviewer cannot get past, the app duplicates something a mobile browser already does, or the reviewer could not find the feature that makes it worth installing.

Can a WebView app pass App Review?

It can, but the burden is on you to show it does something a browser does not. Native navigation, offline capability, push notifications, device integration and platform-specific interactions all help. A thin wrapper around a responsive site generally does not.

How do I fix a 4.2 rejection?

Make the app-specific value visible and reachable in the first minute, add genuine platform integration rather than a feature list, and explain in review notes exactly where to find what makes it more than a website. Arguing the guideline rarely works; showing the functionality sometimes does.

Can a tool tell me if I will be rejected under 4.2?

No, and any tool implying otherwise is overselling. 4.2 is a human deciding whether your app does enough to exist. Static analysis catches deterministic configuration problems, not judgement.

Cite this pageshipcheck. “Guideline 4.2 — minimum functionality.” Baker Ventures LLC, September 6, 2026. https://shipcheck.bakerventuresstudio.com/rejections/guideline-4-2-minimum-functionality/