Rejected under App Store Guideline 4.2? Here's how to get approved

What Guideline 4.2 actually says

Guideline 4.2 is Apple's minimum-functionality bar: an app should include “features, content, and UI that elevate it beyond a repackaged website.” The version most web-based apps meet is 4.2.2, which targets apps that are “not sufficiently different from a mobile browsing experience” — in other words, apps where a reviewer opens it, pokes around for a minute, and concludes they could have just used Safari.

Note what it doesn't say: it doesn't ban apps built from websites. Plenty of household-name apps are web views in a native shell. Apple is judging the experience, not the architecture — which is good news, because experience is fixable.

Why your app got flagged

Reviewers spend a few minutes per app, so 4.2 rejections usually come down to first impressions. These are the tells that trigger them:

• A desktop layout squeezed onto a phone — hamburger menus that open full-width nav, tiny tap targets, horizontal scrolling
• A cookie consent banner — nothing says 'this is a website' faster to a reviewer
• Links that open Safari or show the page URL — everything should feel in-app
• Footer sitemaps, 'visit our website' buttons, newsletter popups, and live-chat bubbles designed for desktop
• Marketing pages as the landing screen — the app should open into the product, not the pitch

The fixes that get 4.2 rejections approved

You don't need to rebuild your product natively. You need the app to answer one question convincingly: why is this an app and not a bookmark? Work through these in order:

1. 1

   Open into the product, not the pitch

   Set the app's start URL to the logged-in or functional part of your site — the dashboard, the feed, the catalogue — not your marketing homepage. A reviewer should be using your product within two taps.

2. 2

   Make the layout unmistakably mobile

   Fix anything that scrolls horizontally, enlarge tap targets, and replace desktop navigation with mobile patterns. If your site framework has a mobile breakpoint you've been ignoring, this is the week to polish it.

3. 3

   Remove the website tells

   Suppress cookie banners inside the app, keep every link in-app, and drop the desktop footer. Each one is small; together they're the difference between 'app' and 'bookmark' in a reviewer's first thirty seconds.

4. 4

   Add a native touch or two

   Push notifications and sensible offline behaviour are the classic ones. They're not strictly required, but they directly answer the question 4.2 is asking: what does this app do that Safari doesn't?

5. 5

   Give the reviewer a working demo account

   If your app has a login, supply demo credentials in App Store Connect's review notes — and test them the day you submit. A reviewer who can't get past your login screen sees an empty shell, and empty shells get rejected under 4.2.

6. 6

   Explain yourself in the review notes

   Use the notes field to say what the app does, who it's for, and where the functionality lives. Reviewers spend minutes per app; point them at the good parts.

How to resubmit after a 4.2 rejection

Rejections arrive in App Store Connect's Resolution Center, and that's also where you respond. Don't just silently resubmit: reply describing what you changed, point by point. If your fixes were to the website itself (layout, cookie banner, landing screen), say so explicitly — the reviewer will re-check the live experience. If you changed the app binary (a new icon, push notifications), upload the new build first. Most resubmissions are re-reviewed within a day or two.

If you believe the rejection is genuinely wrong — the reviewer couldn't log in, or missed real functionality — you can appeal to the App Review Board instead. Appeals take longer than fixes, so use them for mistakes, not disagreements about taste.

Avoiding 4.2 in the first place

Almost everything on the fix list above is checkable before you ever submit. That's how Paludis approaches it: we run a readiness check on your site that flags the avoidable rejections — desktop layouts, website tells, missing review credentials — before your app goes anywhere near Apple. And every build carries our rejection guarantee: if Apple rejects, we fix and resubmit with you until it's approved, or refund you in full.

Frequently asked questions