Apple Rejected Your Web App Under 4.2? How to Fix It

By Alejandro Morillo · Published 1 October 2026 · 8 min read

You wrapped your website in an app, submitted it, and got the email: Guideline 4.2 – Design – Minimum Functionality. It's the most common rejection for web-based apps, and the message rarely tells you what exactly to change.

This guide explains what the guideline actually says, what reviewers notice in a wrapped website, which changes make a real difference, and how to resubmit. It also covers two rules most articles skip — 4.2.6 and 4.3(a) — which matter as soon as you use an app builder.

Quotes are from Apple's App Review Guidelines, last updated June 8, 2026. Nobody can guarantee an approval — App Review decides case by case. What you can do is remove the reasons for a rejection.

What Guideline 4.2 actually says

The core of the rule is one paragraph:

"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."

And one sub-rule that names the typical web-app problems:

4.2.2 "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."

Two things follow:

Using web technology is not forbidden. Many approved apps render web content. The question is whether the result behaves like an app or like a browser with an icon.
The bar is subjective. "App-like" is judged by a person using your app for a few minutes. Your job is to make those minutes look and feel like an app.

What reviewers notice in a wrapped website

These are the signals that typically lead to a 4.2 rejection:

Browser behaviour. Pinch-zoom on a desktop layout, links that open Safari, a "page not found" from the web server, visible scrolling glitches.
Web navigation only. A hamburger menu and a footer full of links instead of an app-style navigation that is always reachable.
No offline handling. Airplane mode shows a blank screen or the system's "cannot connect" page.
A login wall without a demo account. If the reviewer can't get past the login, the app looks like an empty shell. (This is also a separate rejection reason under guideline 2.1, which asks for "demo account info" if your app includes a login.)
Marketing pages instead of functionality. If the first screens are a landing page — hero, testimonials, "download our app" banner — that's the 4.2.2 "marketing materials" case.
Nothing an app does. No reason to have it on the home screen rather than as a bookmark.

Fixes that actually change the outcome

Give the app a bottom tab bar with your three to five main sections (for a shop: Home, Categories, Cart, Account). It should be visible on every screen and work with one thumb. This single change addresses the "collection of links" impression better than anything else.

2. A proper offline state

Turn on airplane mode and open your app. If you see an error page, that's what the reviewer may see too. Show a branded offline screen with a retry button, and reload automatically when the connection returns.

3. Hide everything that says "browser"

Use a mobile layout everywhere; disable pinch-zoom where it only reveals a desktop page.
Keep internal links inside the app; open only truly external links in the browser.
Remove "download our app" banners, cookie walls designed for desktop and footer link farms from the in-app experience.

4. Start where the value is

The first screen after launch should be the useful part of your product — the catalog, the dashboard, the booking flow — not your marketing homepage. If you have a separate app start page, use it.

5. Device integration that serves a purpose

Push notifications for things users actually want (order shipped, appointment tomorrow), the share sheet, camera upload where your product needs it. Avoid decorative permissions: asking for location or camera without a visible reason is its own rejection risk, and every permission needs a clear purpose string.

6. Accounts done right

If users can create an account in your app, guideline 5.1.1(v) applies: "If your app supports account creation, you must also offer account deletion within the app." Web apps often have deletion hidden on a desktop settings page — make it reachable from the app. And give App Review a working demo account in App Store Connect.

What doesn't help

Adding a native screen nobody uses, just to have "something native".
A splash screen and an icon alone — necessary, but not enough.
Copying another app's look. Reviewers judge your app's usefulness, not its styling.

The rules nobody mentions: 4.2.6 and 4.3(a)

If you use an app builder or a template service, read these two before you submit.

4.2.6 "Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients […]"

In plain terms: the app must be submitted from your own Apple Developer account, not from the builder's. A service that publishes apps for you under its own account puts every one of those apps at risk.

4.3(a) "Don't create multiple Bundle IDs of the same app […]"

If you run several similar sites — one per city, one per franchise location, one per client of an agency — submitting a near-identical app for each is the textbook case of 4.3(a) spam. Consider one app with a picker instead, or make each app genuinely different.

Payments: one more trap for web apps

If your web app sells digital content or subscriptions, guideline 3.1.1 requires in-app purchase inside the iOS app ("If you want to unlock features or functionality within your app […] you must use in-app purchase"). A web checkout for a digital subscription inside the app is a separate, common rejection.

Physical goods are different: 3.1.3(e) says that for "physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase". A shop selling real products keeps its normal checkout.

How to resubmit

Fix first, then reply. Make the changes, upload a new build, then answer in App Store Connect.
Write specific review notes. Guideline 2.3.1(a) asks that new features be "described with specificity in the Notes for Review section". List what you changed and where to find it.
Add a demo account and, if your app has hidden features, a short screen recording.
Keep the tone factual. Reviewers respond to evidence, not frustration.

A reply that works as a starting point:

Thank you for the review. We've updated the app to address Guideline 4.2: – Added a bottom tab bar (Home, Shop, Cart, Account) available on every screen – Added an offline screen with automatic reload instead of a web error – The app now opens directly in the catalog instead of our marketing page – Account deletion is available under Account → Settings A demo account is included in App Review Information. Thank you for taking another look.

If you believe the rejection is wrong, you can appeal to the App Review Board — but only after you've made sure the points above are covered.

Checklist before you submit

Bottom navigation with your main sections, visible on every screen
Branded offline screen with retry, tested in airplane mode
No browser chrome, no desktop layout, no pinch-zoom on mobile pages
Internal links stay in the app
First screen = your product's core, not the marketing page
Only permissions you use, each with a clear purpose string
Account deletion reachable in the app (5.1.1(v)); demo account in App Store Connect (2.1)
Digital goods via in-app purchase (3.1.1); physical goods via your normal checkout (3.1.3(e))
Submitted from your own Apple Developer account (4.2.6); one app, not one per location (4.3(a))
Specific Notes for Review (2.3.1(a))

Where AppThunder fits

AppThunder builds the iOS and Android app around your existing website in the cloud. It handles the parts of this checklist that sit outside your site: native app icon and splash screen, purpose strings for the camera and location permissions you enable, a branded offline screen that reloads automatically, and a copy-paste bottom tab bar for your site. Builds are signed with your Apple credentials and uploaded to your App Store Connect, so you submit from your own account, as 4.2.6 requires. A built-in Guideline Checker flags common issues — missing privacy page, login wall, missing account deletion — before you submit.

What it can't do for you: decide what your first screen shows, give App Review a demo account, or make a marketing page useful. The checklist above is still yours.

FAQ

Can a WKWebView-based app be approved at all? Yes. Apple's rule is about the result, not the technology: features, content and UI that "elevate it beyond a repackaged website".

How long does a re-review take? Apple doesn't publish fixed times. Note that the guidelines warn that review "will take longer" if an app is "repeatedly rejected for the same guideline violation", so fix everything before you resubmit.

Does Google Play have the same rule? Google Play has no direct equivalent of 4.2, but its policies on minimum functionality and spam apply to apps that only display a website. The same improvements help on both stores.

Is a splash screen and an icon enough? No. They're expected, but they don't change how the app behaves — navigation, offline handling and a useful first screen do.