Guideline 4.2.2
Guideline 4.2.2 - Design - Minimum Functionality: Insufficient Native Functionality
Our Take
Apple is telling you that your app, as reviewed, looks and behaves like a website wrapped in a native shell rather than a genuine native application. This is one of the more substantive rejections in the guidelines — it is almost never a fully automated flag. A human reviewer opened the app, tapped through the core flows, and concluded there wasn't enough native value beyond displaying remote content (links, images, articles, feeds) pulled from the internet.
The root cause is usually one of two things:
1. The app genuinely is a thin content wrapper — a curated feed, bookmark list, or webview-based reader with no meaningful native features layered on top
2. The app does have native functionality (offline access, push notifications, personalization, native UI interactions, account features, saved state, widgets, etc.) but the reviewer didn't discover it during a short testing session because it wasn't obvious, wasn't demonstrated in the demo account, or was buried behind a login wall or empty state
If the app truly lacks native functionality, the guideline is explicit and unambiguous — no amount of appeal language will overturn it. The app needs real native features added before resubmission.
If the app already has native functionality that simply wasn't surfaced to the reviewer, this becomes a documentation and demo-access issue, not a design flaw, and is appealable.
Resolution Guide
Audit the app honestly
List every feature. For each one, ask: "Could a user get this same value from a mobile browser bookmark?" If most features fail this test, the app is a genuine wrapper.
Check demo access and empty states
Confirm the reviewer's demo account has full access to native features (saved items, personalization, offline mode). If features require setup, data, or a populated account to appear, provide working credentials with pre-seeded data in App Review notes.
If native functionality exists — document and clarify
Reply to the rejection or submit an appeal listing the specific native features (with screen names/screenshots) that go beyond web browsing: offline caching, push notifications, native navigation, widgets, share extensions, account sync, etc.
If native functionality is missing — build it
Add at least 2-3 substantive native capabilities relevant to your content: offline reading/caching, push notifications for new content, native bookmarking/collections, personalization/recommendations, native search, or device integrations (widgets, Siri Shortcuts, share sheet extensions).
Replace webviews where possible
Convert content display from embedded webviews to native UI components (native list/detail views, native image loading, native text rendering) even if the underlying data source is a web feed or API.
Resubmit with reviewer notes
In App Review notes, explicitly call out where to find the native functionality and why it differentiates the app from browsing the same content in Safari.
Prevention
Example Rejection Email
Consider Appealing
Appeal is viable only if the app already contains genuine native functionality that the reviewer likely missed — for example, features gated behind login, empty states, or account setup that weren't demonstrated. In that case, the guideline's requirement ('sufficiently differ from a web browsing experience') is being applied without the reviewer having seen the differentiating features, making this a documentation/access gap rather than a true violation. If, after an honest audit, the app genuinely has no native functionality beyond displaying aggregated web content, the guideline text is explicit and unambiguous, and appeal is not the right path — functionality needs to be added first.
Before & After
App displays a curated list of articles and links via an embedded webview, with tapping simply opening a browser-style page.
App renders articles in native UI, allows offline saving, sends push notifications for new curated content, and lets users build native collections.
What changed: Native rendering plus offline access and notifications create functionality unavailable through a standard browser.
Reviewer's demo account had no saved data, so personalization and offline features appeared empty or hidden.
Demo account is pre-seeded with sample saved items, offline content, and personalized recommendations visible on first launch.
What changed: Ensuring reviewers can see existing native functionality resolves rejections caused by testing gaps rather than actual deficiencies.
App is essentially a bookmark folder of external links opened in Safari view controller with no other features.
App adds native search across saved links, tagging/categorization, offline caching of key pages, and a widget showing recent saves.
What changed: Adding substantive native capabilities differentiates the app from simply bookmarking sites in a browser.
Community Solutions · 0
Sign in to share your solution.
More Guideline 4 (Design) rejections
- Guideline 4.0 - Design: App Does Not Include iOS Features
- Guideline 4.0 - Design: App Looks Like a Website
- Guideline 4.0 - Design: Apple Pay Button Not Following Guidelines
- Guideline 4.0 - Design: Blurry Icons or Low-Resolution Assets
- Guideline 4.0 - Design: Broken Layout on iPad
- Guideline 4.0 - Design: Content Clipped by Notch or Safe Area