Guideline 4.2 Minimum Functionality: How to Get Your WebView or Simple App Approved

What Guideline 4.2 actually means

Guideline 4.2 is Apple's quality floor. Its core sentence asks that your app "include features, content, and UI that elevate it beyond a repackaged website" (App Store Review Guidelines, 4.2). An app that isn't useful, unique or "app-like", or lacks lasting value or utility, may not be accepted. Apple's App Review page is even more direct: "Websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app."

As of October 2026 (guidelines last updated June 8, 2026), these sub-points matter most:

• 4.2 (general) – the clause used against WebView wrappers and very thin apps.
• 4.2.1 – ARKit apps need rich, integrated AR; dropping a 3D model into a scene is not enough.
• 4.2.2 – other than catalogs, apps shouldn't primarily be marketing materials, ads, web clippings, content aggregators or a collection of links.
• 4.2.3 – the app must work without requiring another app, and any extra download on first launch needs its size disclosed and the user's consent.
• 4.2.6 – apps from a commercialized template or app generation service are rejected unless the content provider submits them.
• 4.2.7 – specific rules for remote desktop clients; thin clients for cloud-based apps are not appropriate for the App Store.

For the reviewer, the question is simple: does this app do anything Safari doesn't already do with your website? Rejection messages for wrapper apps have even stated that push notifications, Core Location and sharing on their own are not a robust enough experience. Apple isn't counting APIs. It wants the core of your product to behave like an iOS app.

Common reasons apps get rejected under 4.2

One more trap: if reviewers can't get past your login, the app looks even thinner than it is. Check our guide on 2.1 Information Needed to get demo access right.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

What native value Apple expects from WebView apps

There is no official feature quota. What works in practice: make the core user journey native and add device capabilities that serve it. Web content can stay for help articles, legal pages and rarely used settings.

Hybrid done right

Using web content is not a rejection reason in itself; many approved apps are hybrids. A reviewer should land on a native home screen, move through native tabs and only meet web content in clearly scoped screens. In those screens, use WKWebView, hide your site's header, footer, cookie and app-install banners when the site detects the app (for example via a custom user agent suffix), disable pinch-zoom, open third-party links in SFSafariViewController and use native loading states.

Don't show reviewers a native version and switch back to web content via remote config later. Guideline 2.3.1 forbids hidden, dormant or undocumented features, and Apple treats egregious or repeated behavior as grounds for removal from the Apple Developer Program.

Capacitor, React Native, Flutter and no-code builders

Apple rejects experiences, not frameworks. Some AI app builders and no-code wrappers ship a web build in a thin native shell – exactly what 4.2 targets. Flutter and React Native apps with a real app UI are judged on their features and content, not on the framework. Capacitor, Cordova and Ionic apps can pass when the UI is designed as an app and uses plugins for push, biometrics, camera and storage. If your config simply points the WebView at your production URL (for example Capacitor's server.url, which Capacitor's own docs say is meant for live reload and not for production), that is your root cause.

How to fix a 4.2 rejection step by step

1. Pin down the sub-clause. Check whether the message cites 4.2, 4.2.2, 4.2.3 or 4.2.6. If App Review attached screenshots, they show which screens looked like a website.
2. Run the Safari test. Open your site in Safari next to your app on the same iPhone. Mark every screen "identical", "partly native" or "native only". Identical screens in the main journey need work.
3. Rebuild the core journey natively. Take the three to five most used screens (home, list and detail, cart or bookings, account) and build them with native components fed by your existing API.
4. Add capabilities that fit your use case. E-commerce: order-status push, offline wishlist, Apple Pay for physical goods. Content: offline reading, personalized push, a widget. B2B portals: Face ID login, document scanning, offline forms that sync later.
5. Configure them in Xcode. Under Signing & Capabilities, add Push Notifications and Associated Domains. Host the apple-app-site-association file (no file extension) at https://yourdomain.com/.well-known/apple-app-site-association with a valid certificate and no redirects. Add specific purpose strings such as NSCameraUsageDescription to Info.plist; vague ones invite a Guideline 5.1.1 rejection.
6. Remove every web giveaway. No website header, footer, cookie banner or "get our app" prompt, no dead ends. Test in Airplane Mode: you need a native offline state.
7. Write specific review notes. In App Store Connect, open the new version and fill in App Review Information > Notes with each native feature, how to test it and demo credentials. Guideline 2.3.1 requires new features to be described specifically.
8. Update your metadata. Screenshots should show the native features, not your website – see 2.3.3 Screenshots.
9. Ship a new build. Increment the build number, upload via Xcode Organizer or CI and test it through TestFlight on a real device. Then select the new build in the version's Build section in App Store Connect and submit it for review.

How to reply, resubmit or appeal

Reply in App Store Connect

In Apps, select your app, click the unresolved issues link, choose Resolve next to the submission and then Reply to App Review. As of October 2026, replies are limited to 4,000 characters, you can attach files such as screenshots or supporting documents via Attach File, and you need the Account Holder, Admin or App Manager role (App Store Connect Help). Reply when the reviewer missed something: features behind a login, an untested offline mode, broken demo credentials.

Resubmit with a new build

If the app really was a thin wrapper, a reply won't change the outcome. Fix it, then summarize the changes in the review notes. Apple states that repeated rejections for the same guideline make reviews take longer, so resubmit once the fix is substantial.

Appeal to the App Review Board

Appeals are meant for cases where App Review misunderstood your app's concept and functionality or treated you unfairly. Use the appeal link on Apple's App Review page: one appeal per rejected submission, open information requests answered first, specific reasons tied to the guideline. Appeals are strongest when you can point to overlooked native functionality or the 4.2.2 catalog exception. "Other apps like mine were approved" is a weak argument.

Talk to App Review

Apple offers 30-minute one-on-one video appointments with App Review to discuss the guidelines and common rejections. Find them in the Meet with Apple schedule linked from the App Review page and request an App Review consultation. After repeated 4.2 rejections, one call can save you another round of guessing.

How to argue

Name each native feature with the user problem it solves, explain what users can do that Safari can't (offline access, account push, scanning, biometric login) and give exact test steps. Don't promise future features; reviewers judge the build in front of them.

If a bug-fix update to an app already on the App Store gets a 4.2 rejection, reply in App Store Connect that you'd like to use Apple's bug fix submission process and plan to address the issue in your next submission. Per the guidelines, bug fixes aren't delayed over guideline violations except those related to legal or safety issues.

4.2.2, 4.2.3 and other special cases

Catalogs, brand apps and news

4.2.2 makes an exception for catalogs, but the catalog still has to be an app: native search, filters, favorites, store availability and product pages make the case far better than a page that only promotes the company. Marketing apps need something customers return for, such as loyalty cards, bookings or order tracking. News and blog wrappers become reader apps with native article lists, offline reading, saved articles and topic-based push.

Companion apps and first-launch downloads (4.2.3)

An app that only works with another app installed fails 4.2.3(i) – give it standalone value or merge it into the main app. If you need extra content on first launch, show the download size and ask first; a silent download fails 4.2.3(ii).

Agencies and template platforms (4.2.6)

Template-based apps must be submitted directly by the provider of the app's content; in practice that usually means the client's own Apple Developer account, with the agency added as a team member. Template providers can also offer a single "picker" app that hosts all client content, for example a restaurant finder with a page per restaurant. Near-identical binaries also risk Guideline 4.3 Spam.

Shipping on Google Play too?

Google Play uses different rules: its Minimum Functionality policy targets apps with limited functionality and content, and its Webviews and Affiliate Spam policy targets apps that show a website without the owner's permission or mainly drive affiliate traffic. The native-value fixes above help on both stores – see our Google Play WebView policy guide.

How to avoid 4.2 next time

You can see a 4.2 rejection coming before you upload. Build these checks into your release process:

• Native coverage review: before major releases, confirm every screen in the main journey is native. Treat a new WebView in a core flow as a code review flag.
• Airplane Mode UI test: an XCUITest (or your framework's equivalent) that launches offline and asserts a native offline state.
• CI configuration checks: fail the build if purpose strings or the push and Associated Domains entitlements are missing, or the apple-app-site-association file is unreachable or invalid JSON.
• Review notes in the repo: keep review notes versioned next to the code and update them with every feature change; store demo credentials in your CI secrets, not in the repository.
• TestFlight is not a preview of App Review: passing TestFlight App Review for external testers doesn't mean your App Store submission will pass.

AI-assisted checks help – flagging screens that match your website, scanning builds for missing entitlements, drafting precise review notes – but they work best with human judgment about how a reviewer reads your app. Want a second pair of eyes? Book a free consultation call with appsubmitter.io, or let our team handle CI/CD, submission and review communication, even if your code isn't 100% ready. Code changes aren't included; they're discussed and quoted upfront.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]) and for your feedback regarding Guideline 4.2 - Design - Minimum Functionality.

We have revised the app so that its core experience is native and no longer mirrors our website. In this build:

1. [Native feature, e.g. native Home, Bookings and Account tabs] – [user value]. To test: [steps].
2. [Offline access] – [user value]. To test: open [screen], enable Airplane Mode, [expected result].
3. [Push notifications for e.g. booking changes] – [user value]. To test: [how to trigger one].
4. [Device feature, e.g. Face ID sign-in or document scanner] – [user value]. To test: [steps].

Web content is now limited to [help articles, legal pages], shown in scoped screens with native navigation.

Demo account: [username] / [password]
[Optional: A short screen recording of these features is attached.]

[Optional: The previous review may not have reached [feature], which is available after sign-in under [path].]

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• The first screen after launch is native, not a web page with your website header.
• The three to five most used screens are native components, not WebView pages.
• No website header, footer, cookie banner or "download our app" banner appears in the app.
• In Airplane Mode the app shows a native offline state and loaded content stays usable.
• Push notifications cover user-specific events, permission is requested in context, and the app still works if the user declines.
• Universal links open the matching native screen and the apple-app-site-association file is reachable.
• Every permission has a specific purpose string in Info.plist.
• Third-party links open in SFSafariViewController or Safari, never in a dead end.
• App Review notes list each native feature with test steps, plus a working demo account.
• Screenshots show the native features, and the build was tested on a real device via TestFlight.

Frequently asked questions

Official source: App Store Review Guidelines – 4.2 Minimum Functionality. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.