A useful self-test before resubmitting: open your mobile website and your app side by side. If the app adds nothing the browser doesn't — no native flows, no accounts with saved state, no push, no offline, no device features — the reviewer will reach the same conclusion.
Got the actual message? Paste it into the free rejection decoder — it matches your rejection against documented store rules and returns the fix steps, the resubmission checklist, and a reply draft. Three free decodes, no account.
4.2 — Minimum Functionality
Apple judged the app too thin: typically a website wrapped in a web view, a single-purpose page, or an app whose features end at 'view our content'. The app must offer a lasting, app-like experience beyond a repackaged web page — native functionality, content, and interactivity.
Severity: blocker · Decoder confidence for this class: B (see the honesty note below)
The fix
- Identify why the app reads as a wrapper: if a mobile browser shows essentially the same thing, Apple will keep rejecting it.
- Add native, app-specific functionality: e.g., native navigation and flows, accounts with saved content, push notifications, offline access, camera/device integration, or in-app tools that don't exist on the website.
- Remove placeholder or 'brochure' sections; every tab should do something.
- Explain the native functionality explicitly in the review notes on resubmission, with the paths to reach it.
Resubmission checklist
- Real native functionality added (not cosmetic)
- No dead-end or brochure-only sections
- Review notes map the native features and how to reach them
Reply draft
What the decoder can diagnose here: The class (web-wrapper vs too-few-features) from Apple's wording, and that the fix is product scope, not metadata. What it cannot: Exactly how much functionality is 'enough' — there is no published threshold. As a rule, a resubmission that adds only cosmetic changes gets the same rejection; add real native capability (accounts, push, offline, native flows, device features) or a substantially deeper feature set.
Rule text: “Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store.” — App Review Guidelines §4.2, retrieved 2026-10-23
4.2.6 — Template / App-Builder Apps
The app was built with a template or app-builder service, and Apple requires such apps to be submitted by the content/business owner themselves — not by the builder or an agency account. It's usually an account-structure problem, not a code problem.
Severity: blocker · Decoder confidence for this class: A (see the honesty note below)
The fix
- Arrange for the app to be submitted from the business/content owner's own Apple Developer Program account.
- If you are the builder, transfer the app or have the client enroll and submit; provide them the build and assets.
- Differentiate meaningfully from the stock template (branding alone isn't enough — features and content structure count).
Resubmission checklist
- Submitting account is the content provider's own
- App differentiated from the base template
Reply draft
What the decoder can diagnose here: That the remedy is submission under the content provider's own Apple Developer account (or a substantially customized, differentiated app). What it cannot: Whether your app is differentiated enough to pass under your own account anyway — Apple decides that by comparison with sibling apps from the same template.
Rule text: “Apps created from commercialized templates or app generation services will be rejected unless they are submitted directly by the provider of the app's content.” — App Review Guidelines §4.2.6, retrieved 2026-10-23
4.0 — Design (General)
The reviewer found the app's interface broken, confusing, or below Apple's design bar — common triggers are layouts that break on some screen sizes, dead buttons, overlapping UI, or an interface that references another platform's design. Apple's message usually includes screenshots of the offending screens.
Severity: major · Decoder confidence for this class: C (see the honesty note below)
The fix
- Study the screenshots attached to the rejection — fix exactly what they show, then audit the whole app for the same pattern.
- Test on the device sizes Apple reviews with, including the largest and smallest iPhones and iPad if supported.
- Remove dead controls, fix overlapping/truncated elements, and make primary actions obvious without instructions.
- Attach your own screenshots or a short video in the reply showing the corrected screens.
Resubmission checklist
- Every screenshotted issue fixed
- Same pattern audited app-wide
- Tested on multiple screen sizes
Reply draft
What the decoder can diagnose here: Which screens Apple screenshotted (their attachments are the real diagnosis) and the general class: layout, navigation, or platform-appropriateness. What it cannot: The exact subjective bar — design rejections involve reviewer judgment, so fix everything visible in their screenshots plus the same pattern everywhere else in the app.
Rule text: “Apple customers place a high value on products that are simple, refined, innovative, and easy to use... Apps should comply with the Human Interface Guidelines.” — App Review Guidelines §4.0, retrieved 2026-10-23
Related guides
- Rejection decoder — paste your message, get the fix
- App Store Pre-Flight — the full check and $29 Founding pre-sale
- Google Play Pre-Flight — deadlines and declarations
- Guideline 4.3 — Spam and duplicates
Sources
- App Review Guidelines §4.2, retrieved 2026-10-23
- App Review Guidelines §4.2.6, retrieved 2026-10-23
- App Review Guidelines §4.0, retrieved 2026-10-23
Last updated October 23, 2026. Rules change; the retrieval dates above say when this page was last checked against the store's published text.
Decode your rejection — free
The decoder covers 41 documented rejection patterns across the App Store and Google Play, grounded in the stores' own published rules. Three free decodes; the $29 Pre-Flight Founding pre-sale unlocks unlimited decoding plus a full pre-flight check credit when the checker ships.
The decoder classifies and guides from the message you paste. It cannot see your app or your binary, and it never promises an approval outcome — that decision is always the store's.