Guideline 4.2 rejection: minimum functionality, decoded

Short answer: Apple judged the app too thin — most often a website in a web-view wrapper, or a feature set that ends at 'view our content'. 4.2 has no published threshold for 'enough', which is why cosmetic resubmissions fail: the fix is real native capability. Its sibling 4.2.6 covers template and app-builder apps, which must be submitted by the content owner — an account fix, not a code fix.

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

  1. Identify why the app reads as a wrapper: if a mobile browser shows essentially the same thing, Apple will keep rejecting it.
  2. 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.
  3. Remove placeholder or 'brochure' sections; every tab should do something.
  4. 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

Hello App Review Team,

Thank you for the feedback. In build [X] we expanded the app beyond the previous version with native functionality: [LIST — e.g., native account area with saved items, push notifications for X, offline access to Y, native Z flow]. These features are available at [PATHS] and are also described in the review notes. A demo account is provided if needed.

Thank you for your time.

[NAME]

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

  1. Arrange for the app to be submitted from the business/content owner's own Apple Developer Program account.
  2. If you are the builder, transfer the app or have the client enroll and submit; provide them the build and assets.
  3. 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

Hello App Review Team,

Thank you for the feedback. This app is now submitted under the Apple Developer account of [BUSINESS NAME], the provider of the content and services in the app. [IF APPLICABLE: The app has also been customized beyond the base template with [FEATURES].]

Thank you for your time.

[NAME]

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

  1. Study the screenshots attached to the rejection — fix exactly what they show, then audit the whole app for the same pattern.
  2. Test on the device sizes Apple reviews with, including the largest and smallest iPhones and iPad if supported.
  3. Remove dead controls, fix overlapping/truncated elements, and make primary actions obvious without instructions.
  4. 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

Hello App Review Team,

Thank you for the feedback and the screenshots. In build [X] we corrected [LIST THE FIXES MATCHING THEIR SCREENSHOTS] and audited the remaining screens for the same issues. Attached are screenshots of the corrected screens.

Thank you for your time.

[NAME]

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

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.

Open the free decoder

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.