Guideline 4.2 Rejection: How to Fix Minimum Functionality Issues and Resubmit
Guideline 4.2 — Design: Minimum Functionality — is Apple's "why is this an app?" rejection. It hits apps that are little more than a website in a WKWebView, single-purpose utilities with almost no interactivity, or content that would work equally well as a web page or PDF. Unlike a crash fix, there is no one-line remedy: you have to make the app do more, or do it in a more native way. It is also one of the guidelines where borderline apps get inconsistent outcomes, so a focused improvement plus a good reviewer note matters.
What Apple's rejection email says
"Guideline 4.2 — Design — Minimum Functionality. We found that the usefulness of your app is limited by the minimal amount of content or features it includes. Specifically, your app only includes a web view of your website. Next Steps: We encourage you to review your app concept and incorporate different content and features that are in compliance with the App Store Review Guidelines. Apps should include features, content and UI that elevate them beyond a repackaged website."
Typical App Review wording for Guideline 4.2. Exact text varies per app.
Why apps get rejected under 4.2
- Web wrappers. The app loads your responsive site in a web view and adds nothing: no native navigation, no offline behavior, no push, no device integration. Apple's own wording — the app must be more than "a repackaged website" — is aimed squarely at this.
- Thin utilities. One static screen, a single calculator field, a flashlight-tier feature, or an app whose entire content fits in one label. If the App Store already has the OS feature built in, 4.2 is likely.
- Content better served as media. A band's discography, a restaurant menu, a PDF brochure paginated into screens — "would this be a web page?" is the reviewer's test.
- Everything behind a paywall or login with nothing to review. If the reviewer can't reach meaningful functionality, the app can read as empty. (Provide a demo account; see Guideline 2.1.)
- Marketing-only apps. Apps that exist to advertise a company rather than to do something for the user.
Step-by-step fix
- Diagnose honestly which bucket you're in. Wrapper, thin utility, or content-as-app. The fix differs; a wrapper doesn't need "more content", it needs native behavior.
- For web wrappers, add genuinely native capabilities that the website cannot deliver: push notifications for user-relevant events, offline caching of core content, native navigation (tab bar, swipe gestures) instead of the site's header, biometric login (Face ID), widgets, Share extension, camera or location integration where it makes sense. Two or three real ones beat ten gimmicks.
- For thin utilities, deepen the core loop. Persist user data, add history, settings, iCloud sync, a widget or App Intents/Shortcuts support — features that make the app a tool rather than a single interaction.
- Move rendering native where feasible. Even keeping a web backend, rendering content in native lists and detail views (rather than one full-screen web view) changes how the app reviews and feels.
- Make the functionality reachable. Demo account in App Review Information, seeded content, no empty states on first launch.
- Write reviewer notes that enumerate native features. In the App Review Information notes field, list exactly what is native and where to find it: "Push notifications for order status; offline mode (toggle airplane mode after first sync); Face ID login; home-screen widget." Reviewers won't hunt for it.
How to resubmit
A 4.2 fix always needs a new build. Upload it, update the reviewer notes with the list of added native functionality, and submit for review. If you believe the reviewer genuinely missed existing functionality, reply in the App Review thread pointing to it before considering an appeal — about 85% of appeals are denied, and 4.2 appeals in particular tend to fail unless the app clearly changed. Expect that a second borderline submission gets extra scrutiny; ship the strongest version you can rather than iterating one small feature at a time.
How AscAuto handles 4.2 rejections
4.2 is a product-level rejection, and AscAuto is honest about that: no tool can automatically "add enough app". What it does is classify the rejection correctly, tell you which 4.2 bucket you're in based on Apple's specific wording, and generate a concrete diagnosis — including a proposed feature checklist and a draft reviewer note. If parts of the fix are mechanical and your repo is connected, it can propose scaffolding (e.g. a push-notification registration flow) as a GitHub PR for your review. The resubmission itself is handled for you once you approve.
FAQ
Are web-view apps banned entirely?
No. Plenty of shipping apps render content in web views. The line is whether the app offers meaningful functionality beyond the website — native navigation, push, offline, device features. A pure wrapper with none of those is what 4.2 rejects.
How many features do I need to add to pass 4.2?
There is no published number. In practice, two or three substantive native capabilities (push notifications, offline mode, widgets, Face ID, camera/location integration) that fit your product — plus reviewer notes that point them out — is the pattern that gets borderline apps through.
Is it worth appealing a 4.2 rejection?
Rarely. Around 85% of appeals are denied, and 4.2 is subjective enough that the board usually backs the reviewer. Adding real functionality and resubmitting with clear notes has a far better success rate.
Could I ship as a web app instead?
If your product truly is a website, a Progressive Web App added to the home screen avoids review entirely — Apple's guidelines themselves suggest the web for content that doesn't need app features. Many teams do both: PWA now, richer native app later.