WebView App Rejected Under Guideline 4.2: What to Change

Key takeaways

Guideline 4.2 asks for features, content and UI beyond a repackaged website – wrappers fail when their main journey is identical to Safari.
Native features persuade only when they serve the core journey: account push, offline access, Face ID re-login or scanning beat a splash screen.
Remove what gives WKWebView away: site header and footer, app-install banners, pinch zoom, link previews, dead target="_blank" links and raw error pages – and restyle cookie consent instead of dropping it.
WebViewGold, made by our team, ships native navigation, push, offline fallback, biometrics and scanners as modules – use them in the core journey.

Our recommended solution

Rebuild your wrapper with WebViewGold – a real app, not just a website in a frame

WebViewGold turns your website into native iOS and Android apps with push notifications, a native offline screen, deep links, a QR scanner and more – the building blocks App Store reviewers look for. Built by our own team, and we submit WebViewGold apps all the time.

Get WebViewGold How it helps ↓

What the rejection typically looks like

Guideline 4.2 - Design - Minimum Functionality

Your app provides a limited user experience: it is not sufficiently different from browsing your website on a mobile device, and the experience is similar to using Safari.

Next Steps: Revise the app to offer a more robust experience with native iOS functionality, or consider distributing a web app from your website instead.

Paraphrased example – the exact wording in your message may differ.

Why a WebView app gets rejected under Guideline 4.2

A WebView app is rejected under Guideline 4.2 when App Review concludes that the app adds nothing to what your website already does in Safari. The fix is not a different framework but a different experience: native navigation, device features tied to your core journey, no browser giveaways and review notes that show the reviewer where all of this lives.

The guideline is short, and its first two sentences carry the whole argument:

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.

For wrapper apps, "repackaged website" is the operative phrase. Nothing in the guidelines bans WKWebView – many approved apps render web content – but the reviewer has to meet an iOS app first and your website second.

Here you get the WebView-specific side: the Safari comparison, the native features that move the needle and the web leftovers to remove. Sub-clauses such as 4.2.2 and 4.2.3 are covered in our complete Guideline 4.2 guide. If your message cites 4.2.6 instead, the issue is who submitted the app – read Guideline 4.2.6 for WebView apps.

The side-by-side Safari test: see your app like a reviewer

Before you change anything, find out how much of your app really is your website. Install the rejected build from TestFlight, open your site in Safari on the same iPhone and walk through both in parallel – signed out, then with the demo account.

Checkpoint	Same as Safari if…	Reads as an app if…
First screen	A web page with your site header, burger menu and cookie notice	A native start screen or tab bar, with content for signed-in users
Moving between sections	Every tap reloads a page and the back gesture walks through browser history	Persistent native navigation; each section keeps its state
Long-press and pinch	Link previews appear and the page zooms out	Long-press does nothing unexpected and the layout stays put
Airplane Mode	A blank view or your hosting provider's error page	A native offline screen; recently loaded content stays readable
Notifications	None, or generic marketing blasts	Events from the user's own account that open the matching screen
Device features	An upload button that opens a file picker – and nothing else	Camera scanning, Face ID re-login, share sheet, widgets

If most rows land in the middle column, a reply won't get you approved – the build has to change. If the right column wins and the reviewer simply missed it, for example because the native parts sit behind a login, a precise reply with test steps is the faster path.

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 →

Which native features change a reviewer's mind – and which are cosmetic

Apple has told wrapper-app developers in rejection letters that adding push, Core Location and sharing still didn't make the experience robust enough. The lesson isn't that these features are worthless. A feature counts when it changes how someone gets their main task done. Compare the strong and the weak version of the same idea:

Feature	Persuasive when…	Cosmetic when…
Native tab bar or sidebar	It holds your three to five main destinations and replaces the website menu	It only adds back and forward buttons on top of the site
Push notifications	They report account events – order shipped, appointment moved, reply received – and open the right page	They broadcast newsletters or "we miss you" reminders
Offline state	Users see a native screen with a retry button and keep what they already loaded	An alert pops up, followed by a blank view
Face ID or Touch ID	It brings a returning user back into a protected account within a second	It locks a public news feed nobody needs to protect
Scanning	QR, barcode or document scanning feeds the core task – ticket check-in, product lookup, receipt upload	A scanner exists, but nothing in the journey needs it
Widget	It shows something personal at a glance, such as the next booking	It shows a static logo
Share sheet	Users share a specific item, and the link opens that item in the app	The only option is "share this app"

Splash screens, pull-to-refresh, haptics and dark mode make an app feel finished, so keep them – just don't present polish as your answer to 4.2.

Remove the web giveaways that WKWebView exposes

A reviewer recognizes a website within seconds, usually by details your team stopped noticing long ago. Go through this list on a real device:

Site chrome. Your header with logo and burger menu, the footer with its sitemap, cookie banners and "Download our app" or Smart App Banner prompts. Hide them when the page runs inside the app; a consent dialog you still need can appear once, in the app's own style.
Pinch zoom. WKWebView honors the viewport's scale limits unless ignoresViewportScaleLimits is switched on (it is off by default), so a viewport with maximum-scale=1 and user-scalable=no stops the layout from zooming. Make text large enough that nobody needs to zoom.
Link previews and callouts. Long-pressing a link shows a preview, because allowsLinkPreview has defaulted to true since iOS 10. Turn it off and add -webkit-touch-callout: none to links and images in the app.
Text selection on controls. A button label that gets selected like text on a long press is pure browser behavior. Apply user-select: none (with the -webkit- prefix) to navigation, buttons and icons, but leave articles and messages selectable.
Error pages. WKWebView has no friendly error page of its own: a failed load leaves a blank view, and a server problem shows your host's or CDN's raw error page. Catch failures in WKNavigationDelegate and show a native screen instead.
target="_blank" and window.open. Unless your WKUIDelegate implements webView(_:createWebViewWith:for:windowFeatures:), WebKit cancels these navigations – the tap simply does nothing. Load them in the same view, an in-app browser sheet or Safari.
File inputs. On iOS, <input type="file"> opens the same chooser Safari shows, camera included. Without an NSCameraUsageDescription purpose string, the camera option can crash the app – add the key, and prefer native scanning where users really photograph documents or codes.

Detect the app with a custom user-agent suffix

Hiding web elements only inside the app requires your website to know where it runs. The cleanest signal is the user agent. Apple describes WKWebViewConfiguration.applicationNameForUserAgent as the app name that appears in the user agent string. On iOS, WebKit fills it with Mobile/15E148 by default, so set it to Mobile/15E148 YourApp/2.4: mobile detection that looks for "Mobile" keeps working, and the string now ends with your marker. Unlike customUserAgent, which replaces the whole string, the standard iOS part stays intact.

On the web side, add an in-app class to the root element when navigator.userAgent contains YourApp/, and let your stylesheet hide header, footer and banners under that class. Server-side, the same marker in the User-Agent header lets you skip web-only components entirely.

One rule keeps this safe: use app detection for presentation and native integrations, never to decide which features exist. Showing App Review a trimmed-down app while users get something else is the pattern behind Guideline 5.6 rejections of WebView apps. In WebViewGold you set a custom user agent per device type with useragent_iphone and useragent_ipad in Config.swift – keep the standard iOS string and append your marker – and its Custom CSS and JS feature injects app-only styles without touching your website.

The fastest fix for most WebView rejections

WebViewGold: native features for your web app

Instead of building native features from scratch, start from WebViewGold. You get ready-made Xcode and Android Studio projects for your website, with native modules you switch on in the configuration:

Push notificationsOneSignal or Firebase, for real, personal events
Native offline screenNo browser error pages when the connection drops
Native splash screenApp-like start instead of a loading web page
Deep linksLinks open the right screen inside the app
QR & barcode scannerDevice features the website alone can't offer
In-app purchasesNative purchase flows where the store requires them

No tool guarantees an approval: Apple still judges what your app offers. Use the native features in your main user journey – our App Specialists review your WebViewGold app before it goes to the App Store.

Discover WebViewGold Let us submit your WebViewGold app

The Capacitor server.url shortcut and other thin shells

Many 4.2 rejections start with a configuration that technically produces an app but in practice ships a bookmark. The best-known example is Capacitor's server.url. Capacitor's configuration reference describes it as loading an external URL in the Web View, intended for live-reload servers – and adds in bold that it is not intended for use in production.

With server.url pointing at your live site, the native project carries no web assets of its own and every screen comes from the server – exactly the "repackaged website" the guideline describes. A twenty-line Swift view controller that loads a production URL produces the same result.

If you stay with Capacitor, ship your compiled web assets from webDir, build native screens or plugins for the core journey and treat live updates with care, because downloading code that changes features collides with Guideline 2.5.2 (see 2.5.2 for WebView apps). If your website should stay the single source of truth, a wrapper with ready-made native modules is the shorter road.

Mapping WebViewGold modules to what 4.2 reviewers look for

WebViewGold is the website-to-app solution built by our own team. It is a ready-made Xcode project in Swift: you enter your URL in Config.swift and switch on native modules instead of writing them. Here is how those modules line up with the questions a 4.2 reviewer implicitly asks:

Reviewer's question	WebViewGold module	How to make it count
Can I get around without the website menu?	Native navigation footer or sidebar with SF Symbols icons	Link your main sections and hide the web menu in the app
Does the app tell me about my account?	Push via OneSignal, Firebase or Pushwoosh, with deep links	Send event-driven messages that open the right page
What happens without a connection?	Native offline fallback with a bundled local page and a reconnect button	Offer something useful offline, not only an apology
Is my account protected and quick to reopen?	Face ID and Touch ID	Use it for re-login into signed-in areas
Does it use the device?	QR and barcode scanner, VisionKit document scanner, NFC tag reading	Put scanning where users would otherwise type or upload
Does it exist outside its own window?	Widget Extension, Share Extension, Siri integration, native share dialog	Show personal data or accept shared content
Does it still behave like a browser?	Custom user agent, link-preview and zoom settings, URL handling for external and `target="_blank"` links	Clear the giveaway list above

WebViewGold is a one-time purchase, you own the project and you publish it in your own developer account. No Mac? The separately sold Cloud Builder builds the app in your browser, our team can set it up for you, and appsubmitter.io handles signing and submission. Still, no tool can promise an approval: Apple judges the journey you build with these modules.

After the rejection: reply, resubmit or appeal?

Choose your response based on what the Safari test showed:

Situation	Best move
Native features sit behind a login the reviewer didn't pass	Reply in App Store Connect with a demo account, a path to each feature and a screen recording
The app really mirrored your website	Change it, upload a new build and list each native feature in the Notes for Review
The reviewer misjudged a genuinely app-like product	Reply first, then appeal to the App Review Board with specific reasons (one appeal per submission)
You can't tell what is missing	Request a 30-minute App Review appointment over Webex and walk through the app together
A bug-fix update of a live app was rejected under 4.2	Ask to use the bug fix submission process and commit to addressing 4.2 in the next version

Describe features by user benefit, not by API: "members scan their card at the gym entrance" persuades more than "camera integration". And resubmit only once the change is real – Apple warns that repeated rejections for the same guideline make reviews take longer. If the letter also cites Guideline 2.3.1(a) for hidden features, read our article on the 2.3.1 and 4.2 combination before you answer.

appsubmitter.io takes this part off your plate: an App Specialist runs AI-powered pre-submission checks, writes the review notes, submits from your own developer account and answers App Review. Code changes such as new native screens aren't included, but we quote them upfront if you need them. Book the iOS service or talk it through in a free consultation call.

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]). We understand the previous build felt too close to our website in Safari and have reworked the core experience.

What changed in this build:
1. Native navigation: [Home, Orders, Account] are native tabs. The website menu, header and footer no longer appear in the app.
2. Account notifications: users receive a push when [an order ships / an appointment changes]. Tapping it opens the matching screen. To test: [steps or test trigger].
3. Offline state: without a connection, the app shows a native offline screen with a retry button and keeps [recently viewed content] readable. To test: enable Airplane Mode on [screen].
4. Device features: [Face ID re-login / barcode scanning for product lookup] in [location]. To test: [steps].
5. Browser behavior removed: no pinch zoom, link previews or dead links.

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

If anything still feels like a website to you, we would appreciate a pointer to the screen concerned.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

You compared the rejected build with your website in Safari on the same iPhone, screen by screen.
Your main sections are reachable through native navigation, and the website menu is hidden in the app.
Push notifications cover account events and open the matching page.
Airplane Mode shows a native offline screen with a retry option instead of a blank view.
At least one device capability – Face ID re-login, scanning, a widget or the share sheet – is part of the core journey.
Site header, footer and app-install prompts are hidden when the page runs in the app, and any cookie consent you need appears in the app's own style.
Pinch zoom, link previews, long-press callouts and text selection on controls are disabled.
target="_blank" links and window.open calls open somewhere useful instead of doing nothing.
The user-agent marker only changes presentation and native integrations, never which features exist.
The Notes for Review list each native feature with its location and test steps, plus a working demo account.

Frequently asked questions

Why was my WebView app rejected under Guideline 4.2?

Because App Review saw little difference between your app and your website in Safari. Typical signs are a web menu instead of native navigation, browser behavior like pinch zoom and link previews, error pages when offline and no device features in the main journey. Apple has no rule against WKWebView itself; it rejects apps whose core experience a browser already delivers.

How many native features does a WebView app need to pass 4.2?

Apple publishes no number, and counting APIs is the wrong approach. Reviewers judge whether the main journey benefits from being an app. Three well-placed features – native navigation, push for account events and an offline state – say more than ten features nobody uses. Describe each one in the review notes.

Is a native tab bar enough to fix a 4.2 rejection?

Rarely on its own. A tab bar shows that the app is organized like an app, but if every tab still loads a web page with browser behavior, little has changed. Combine it with features that change what users can do, such as push for their own events, offline access or Face ID sign-in.

Can I keep my website's design inside the app?

Yes. Your brand, colors and layouts can stay – Apple doesn't ask you to throw away your design. What has to go is browser-specific UI: the site header and footer, app-install banners, zooming, link previews and pages that only make sense on a desktop. Cookie consent stays, styled for the app. A shared visual design with app-specific navigation and native features is a legitimate approach.

Will WebViewGold get my app through Guideline 4.2?

No tool can promise an approval, because Apple judges the experience you build. WebViewGold, made by our team, gives you the native building blocks reviewers look for – navigation, push, offline fallback, Face ID, scanners and widgets – as configurable modules. Placed in your core journey and described in the review notes, they give the reviewer something to approve.

Should I build a PWA instead of a WebView app?

If you can't add native value, consider it. A progressive web app needs no App Review, and since iOS 16.4 web apps added to the Home Screen can receive web push notifications. You lose App Store discovery and some device integrations. Capacitor or a native rebuild are the other routes, depending on how much must be native.

Sources and further reading

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.

WebView App Rejected Under Guideline 4.2: From Repackaged Website to Real iOS App