Guideline 4.2, "Minimum Functionality," means your app does too little beyond what a website already does, so its experience is too close to mobile browsing. The most common cause is a webview wrapper, an app that mostly loads a website, or one that just aggregates web links, images, and content with little native functionality. The fix is to add genuine native features and lasting value, so the app does something a browser cannot, not a site with push notifications bolted on. You can revise and resubmit, or appeal if the concept was misunderstood.
Short answer
4.2 rejects apps that are not sufficiently different from a mobile browsing experience. Per Apple's App Store Review Guidelines, an app should include features, content, and a user experience that make it more than a repackaged website, and 4.2.2 specifically targets apps that only aggregate web links, images, or content with limited native functionality. The fix is to add real native features and lasting value, so the app does something Safari cannot. Adding push notifications or Core Location alone is not enough. You can reply in the Resolution Center and resubmit a revised build, or appeal to the App Review Board if your app's concept was genuinely misunderstood.
What guideline 4.2 actually says
Guideline 4.2, under Design, is titled Minimum Functionality, and it asks that an app be more than a thin layer over the web. Apple's wording is that apps providing a limited experience that is not sufficiently different from mobile browsing will be rejected, because using them feels like using Safari. The rule is about substance: an app should give people a reason to install it rather than just visit a site.
The most cited sub-clause is 4.2.2, which rejects apps that only include links, images, or content aggregated from the internet with limited or no native functionality. Together, these say the same thing from two angles: an app needs native capability and lasting value, not a wrapper around web content.
Why your app got a 4.2 rejection
Matching your rejection to its cause tells you what to build. The most common trigger is a webview app that mostly loads a website, which reviewers treat as too close to Safari. Others include apps that only aggregate web links or images, apps with a very limited feature set, and apps that feel like a marketing page rather than a tool. The table below maps causes to fixes.
| Cause | Why it triggers 4.2 | Fix |
|---|---|---|
| A webview wrapper of a website | Too similar to Safari | Add native features and content |
| Only aggregated web links or images | Little native functionality (4.2.2) | Build genuine in-app functionality |
| A very limited feature set | Not enough lasting value | Add compelling capabilities |
| Requires a config profile to work | Should work standalone (4.2.3) | Remove the dependency |
| A thin marketing app | Better as a website | Add utility users return for |
Reading the cause first keeps you from making a cosmetic change that does not address the rule. If the core issue is that your app is a website in a wrapper, no amount of restyling fixes it; adding genuine native function does.
The webview and wrapper trap
Webview and wrapper apps are the classic 4.2 rejection, because they are, by definition, a website shown inside an app shell. Reviewers consistently reject apps that serve web content not built for iOS, with limited web interactions and little native functionality, because the result is not meaningfully different from opening the same site in a browser. This is exactly what 4.2.2 describes.
A webview is not banned outright, but it cannot be the whole app. If your app is essentially your website in a frame, it will keep hitting 4.2 until it does something native and valuable on top. The fix is not to hide the webview better; it is to build real iOS functionality around it so the app stands on its own.
What "lasting value" and native functionality mean
"Lasting value" is Apple's way of saying an app should give people a reason to come back, by offering useful utility, entertainment, or capabilities they could not get otherwise. Native functionality means using the device and platform in ways a browser cannot: working offline, integrating with device features, providing a real in-app interface, or doing on-device processing. The point is capability, not decoration.
Apple is explicit that a few sprinkled iOS features are not enough on their own. Adding push notifications, Core Location, and sharing to an otherwise thin app does not, by itself, satisfy 4.2; the app still needs a fuller native experience. Think in terms of what your app lets someone do that a website cannot, and build that, rather than checking off individual APIs.
How to fix it: add real native features
Fixing 4.2 is about substance, so the work is to add genuine native capability and value, then resubmit. The checklist below gives a clear path to follow.
| Step | Action | Why |
|---|---|---|
| 1 | Name what your app does beyond a website | Identifies the gap |
| 2 | Add native features like offline and device APIs | The core of 4.2 |
| 3 | Provide value users come back for | The intent of the rule |
| 4 | Ensure it works standalone, no config profile | Meets 4.2.3 |
| 5 | Reply in Resolution Center and resubmit | The right channel |
| 6 | Appeal only if genuinely misunderstood | For a wrong call |
The single most important step is the second one: add native features that make the app do something a browser cannot. Everything else supports that. If, after your changes, you can describe a concrete thing your app does natively that Safari cannot, you have addressed the heart of 4.2.
What does not fix 4.2
Some changes feel like progress but do not resolve a 4.2 rejection. Restyling the app, changing colors or the icon, or renaming it does nothing, because the rule is about function, not appearance. Adding a single iOS feature like push notifications to a webview also does not clear it, since Apple says that is not enough on its own.
Padding the app with more web content is the other dead end. Aggregating more links or pages is precisely what 4.2.2 rejects, so more of it makes the problem worse, not better. The only reliable fix is native functionality and genuine value, so put your effort there rather than into cosmetic or content-volume changes.
Reply, resubmit, or appeal?
Your response depends on whether the rejection was correct. If your app really is thin, the productive path is to add native functionality and resubmit a genuinely improved build, replying in the Resolution Center to note what you changed. This is usually faster than arguing, because the reviewer is applying the rule as written.
Appeal only when you believe your app's concept and functionality were misunderstood, and you can point to the native value it already provides. You appeal to the App Review Board through Apple's Contact page with specific reasons. But be honest with yourself first: if the app is a wrapper, an appeal will not change the outcome, and building real functionality will.
If your app genuinely needs to be a webview
Some apps have good reasons to rely heavily on web content, such as a companion to a web service. Even then, 4.2 still applies, so the app must add native value around the web layer. Consider offline access, native navigation and interface, device integration, notifications tied to real functionality, or features that only make sense on the device.
The mindset that works is to treat the web content as one component, not the whole product. If the native shell genuinely adds capability the website does not have, a webview-backed app can pass; if the shell is empty and the web content is everything, it will not. Build the app so that removing the webview would still leave something useful behind.
Ship it securely too
Fixing 4.2 usually means adding native code, and native code adds security surface, so the moment you build real functionality is also the moment to check it. New device integrations, storage, and network calls can introduce their own problems, and App Review can reject on security and privacy grounds separately from 4.2, so it is worth not trading one rejection for another.
A scanner like PTKD.com analyzes your .ipa and returns findings ordered by severity and mapped to OWASP MASVS, so the native features you add to satisfy 4.2 are also checked for embedded secrets, insecure storage, and network issues before you resubmit. To be clear about the boundary: PTKD has nothing to do with guideline 4.2 and cannot resolve a minimum-functionality rejection. It covers the security side of a build that a design review does not examine.
What to take away
- Guideline 4.2 rejects apps that do too little beyond a website; the classic case is a webview wrapper.
- 4.2.2 specifically targets apps that only aggregate web links, images, or content with little native functionality.
- The fix is genuine native features and lasting value, not restyling or a single iOS feature bolted onto a webview.
- Add real functionality and resubmit, and appeal only if your app's concept was genuinely misunderstood.
- Scan the native features you add with PTKD.com, so fixing 4.2 does not create a separate security rejection.
