# Guideline 4.2.2 - Design - Minimum Functionality: Insufficient Native Functionality

**Guideline:** 4.2.2 · **Store:** Apple App Store · **Severity:** high · **Fix difficulty:** hard · **Typical turnaround:** 1-3 days for clarification/demo access fix; 1-3 weeks if native functionality must be built

Canonical URL: https://appstorereject.com/rejections/apple/4/guideline-422-design-minimum-functionality-insufficient-native-functionality

## Description

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.

## Common variations

- Your app only includes links, images, or content aggregated from the Internet with limited or no native functionality.
- The app does not provide any features beyond viewing web-based content, which does not sufficiently differ from a web browsing experience.
- Your app appears to be a wrapper around a website or webview with minimal native iOS functionality.
- We were unable to locate sufficient native functionality during our review. Apps that only display curated web content are not appropriate for the App Store.
- This app's primary function is displaying content pulled from the internet without adding meaningful value through native app functionality.

## Example rejection email

```
Guideline 4.2.2 - Design - Minimum Functionality

Issue Description

We noticed that the app only includes links, images, or content aggregated from the Internet with limited or no native functionality. Although this content may be curated from the web specifically for your users, since it does not sufficiently differ from a web browsing experience, it is not appropriate for the App Store.
```

## Resolution steps

## Quick Assessment
- **Risk level:** High
- **Resolution path:** Depends on audit findings — Fix & Resubmit if genuinely thin, Clarify Without Change if native functionality exists but wasn't surfaced
- **Typical turnaround:** 1-3 days (clarification) to 1-3 weeks (adding native functionality)

## The Fix

01. **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.

02. **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.

03. **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.

04. **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).

05. **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.

06. **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
- Before submitting, test your app as if you were a first-time reviewer with no context: does it feel like an app or a bookmarked website?
- Ensure any content-aggregation app includes account-based personalization, offline access, or device integration from the first release.
- Always provide a fully populated demo account so native features are visible without extra setup.

## Appeal guidance

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 examples

**Before:** App displays a curated list of articles and links via an embedded webview, with tapping simply opening a browser-style page.
**After:** App renders articles in native UI, allows offline saving, sends push notifications for new curated content, and lets users build native collections.
**Why it works:** Native rendering plus offline access and notifications create functionality unavailable through a standard browser.

**Before:** Reviewer's demo account had no saved data, so personalization and offline features appeared empty or hidden.
**After:** Demo account is pre-seeded with sample saved items, offline content, and personalized recommendations visible on first launch.
**Why it works:** Ensuring reviewers can see existing native functionality resolves rejections caused by testing gaps rather than actual deficiencies.

**Before:** App is essentially a bookmark folder of external links opened in Safari view controller with no other features.
**After:** App adds native search across saved links, tagging/categorization, offline caching of key pages, and a widget showing recent saves.
**Why it works:** Adding substantive native capabilities differentiates the app from simply bookmarking sites in a browser.

## Common questions

**Can you appeal a 4.2.2 rejection?**

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.

**How long does this typically take to fix?**

Typical turnaround is 1-3 days for clarification/demo access fix; 1-3 weeks if native functionality must be built (difficulty: hard). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-422-design-minimum-functionality-insufficient-native-functionality*