Guideline 4.2 Minimum Functionality rejection checklist
Guideline 4.2 problems are product-shape problems. Adding more marketing copy rarely changes the review outcome.
Repair a 4.2 rejection by identifying the native job the app performs better than a website or static catalog, then showing that job from fresh install. Apple Guideline 4.2 addresses minimum functionality and app-like value. AppReviewReady interpretation: the fix must change what the user can do, not merely how the app describes itself.
Diagnose the wrapper risk
Ask whether the app is mostly a web view, PDF, catalog, list of links, static brochure, thin booking shell, or single-use marketing page. If the answer is yes, name what native capability changes the user's outcome.
A 4.2 fix should not depend on hidden future content. The submitted build needs enough value for the reviewer to complete a meaningful task today.
Define app-specific value
- A user can create, edit, save, compare, personalize, scan, calculate, communicate, or control something.
- Native device features improve the task instead of being decorative.
- Offline or poor-network states still provide useful behavior where appropriate.
- The app has a reason to be installed beyond opening a website.
- The main value appears before a long account, payment, or content-unlock wall.
Choose a real product repair
Repairs can include native capture, saved projects, personalized workflows, user-owned data, device integrations, local notifications tied to user action, or tools that make the content operational.
AppReviewReady interpretation: adding a tab bar, splash screen, or push notification does not necessarily create minimum functionality. The question is whether the app enables a durable job.
Resubmit with a reviewer route
- Open the app from fresh install and complete the primary task in fewer than five minutes.
- Show the new native value in Review Notes with exact steps.
- Remove screenshots that still make the app look like a static wrapper.
- If the app mirrors a website, explain what the app does differently.
- Test empty, signed-out, no-network, and first-content states.
Minimum functionality evidence
The response should state what changed in the build. Avoid arguing that a simple app is allowed unless the submitted product has a clear user job.
After approval, protect the app from drifting back into a thin container. Marketing pages, seasonal catalogs, and partner content updates should not replace the native workflow that earned approval.
If the product legitimately centers on content, make the content actionable. A recipe app can plan groceries, scale servings, save cooked meals, or guide timers; a plain recipe archive has weaker app-specific value.
For venue, school, association, or franchise apps, decide whether one container app with selectable organizations would better serve users. Minimum functionality and spam risk often appear together when many thin local apps share one template.
Measure first-run task completion after launch. If most users leave before reaching the native workflow, the product may still be vulnerable to future review questions even after one accepted build.
4.2 repair evidence: Rejected surface: [wrapper/catalog/etc.] Native task added: [task] How to test: [steps] User-created value: [data/project/action] Offline or device value: [behavior] Website difference: [specific] Screenshots updated: [yes/no]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check 4.2 repair evidence
Validate native value, reviewer path, and product depth before resubmission.
Open the tool