WebView App Rejected Under Guideline 2.4.1: Fixing Your Website-Based App on iPad

Why did my WebView app fail Guideline 2.4.1 on iPad?

Your WebView app failed Guideline 2.4.1 because App Review tested it on an iPad and something didn't work or display properly there. For website-based apps, the cause is often invisible on an iPhone: on iPad, the web view asks your server for a desktop site, and your layout, share buttons and uploads meet screen sizes you never tested.

The guideline itself is two sentences:

To ensure people get the most out of your app, iPhone apps should run on iPad whenever possible. We encourage you to consider building apps so customers can use them on all of their devices.

An iPhone-only app still runs on iPad in compatibility mode, an iPhone-sized window, and reviewers may test it there. A universal app runs natively on iPad and has to handle every size, orientation and window. The review device details at the end of the rejection name the iPad model and iPadOS version. A crash on that iPad may also arrive as a completeness rejection – see Guideline 2.1 for WebView apps. Our Guideline 2.4.1 guide explains device families and native layout fixes; this article covers what is specific to apps built on a WKWebView.

The iPad surprise: WKWebView asks for your desktop site

Since iPadOS 13, iPad presents itself to websites like a Mac. Apple's WebKit team said so at WWDC19 – "So new in iPadOS, iPad will now present itself to websites as a Mac." – and showed that a WKWebView in an app built with the iOS 13 SDK or later "should request the desktop version by default" on an iPad Pro (WWDC19 session 203).

The documentation explains the mechanism. WKWebpagePreferences.preferredContentMode defaults to .recommended, "the content mode that is appropriate for the current device", and Apple notes that Safari "provides a desktop-class experience when displaying webpages on Mac and iPad". App Store uploads require a current SDK, so this default applies to your app. In practice:

• Server-side device detection fails. If your backend or CMS picks a mobile or desktop template by user agent, iPads get the desktop template – mega menus, hover navigation, small text.
• App detection can break. Replacing the whole user agent string can make services that parse it treat the app as an unknown browser. Apple recommends applicationNameForUserAgent, which appends your app name and lets WebKit "fill in the rest of the user agent".
• Analytics can mislead you. Tools that read the user agent may count iPad sessions from your app as Mac visits, so the problem hides in your dashboards.

How to fix it

1. Preferred: one responsive site. WebKit's advice from the same session: "build one responsive website instead of building parallel desktop and mobile sites" and "use feature detection instead of user agent sniffing".
2. If you must keep a separate mobile site, set preferredContentMode to .mobile – in defaultWebpagePreferences of your WKWebViewConfiguration or per navigation in webView(_:decidePolicyFor:preferences:decisionHandler:).
3. Or add an iPad marker your server recognizes to the user agent – to pick templates, never to make the app pass as a regular browser.

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 →

Breakpoints that break: desktop layouts and stretched phone layouts

Even with the right content mode, iPad widths expose layout assumptions. On a 13-inch iPad in landscape, the web view can be as wide as a laptop browser window; in a narrow Split View or Stage Manager window, it can be as narrow as a phone.

Pointer input adds a twist: with a trackpad or mouse attached, an iPad does hover. A desktop menu may work for one reviewer and fail for the next one using touch, so design for touch first and test both. Tap target sizes and hover rules are covered in our article on Guideline 4.0 for WebView apps.

Share sheets, pickers and uploads: the iPad crash list

UIKit is strict on iPad. Apple's documentation for the share sheet says: "On iPad, you must present the view controller in a popover." A popover needs an anchor – a sourceView with a sourceRect, or a bar button item. Without one, the app crashes the moment the reviewer taps Share. On iPhone the same code works, which is why the bug survives until review.

WebView apps get a special version of the problem: the Share button is HTML. When your page triggers native code through a custom URL scheme or a JavaScript message handler, there is no native button to anchor to. Use the web view itself as sourceView and pass the element's position from JavaScript (getBoundingClientRect()) as sourceRect, or fall back to a small rectangle near the top of the web view. The same goes for action sheets your native code shows in response to web events.

Standard web uploads are less risky than they look. WebKit presents the menu for an <input type="file"> itself – Photo Library, a camera option and Choose File – so your code presents nothing. What still goes wrong on iPad:

• A missing camera purpose string. iPads have cameras too; without NSCameraUsageDescription, choosing the camera option ends the app.
• Native file flows. Downloads, printing, opening documents and saving to Files have their own presentation rules – run each of them on an iPad.

Split View, Stage Manager and rotation

A universal app on iPad lives in windows that change size. Since iPadOS 26, users can resize app windows freely, and Apple has deprecated the old full-screen opt-out, UIRequiresFullScreen; the native side is covered in our guide. For your web content, three rules keep layouts stable:

1. Let the viewport decide. CSS media queries respond to the web view's width, which is exactly what changes in Split View. Code that reads the device's screen size or the user agent picks the wrong layout.
2. Re-layout on resize. Charts, maps, carousels and canvas elements that measure themselves once at load need resize handling, for example with a ResizeObserver.
3. Support both orientations. Many iPads sit in landscape keyboard cases. Allow all orientations on iPad and check that rotating mid-flow – during checkout or in a long form – keeps the user's input.

WebKit adds a nuance: Apple says Safari and Safari View Controller "automatically choose a browsing mode" in narrow windows, and the recommended mode of a WKWebView "does what Safari does". The same page can therefore switch between desktop and mobile content as the window narrows – one more reason for a single layout that works at every width.

What App Review does on iPad – and how to rehearse it

The rejection's review device details tell you which iPad and iPadOS version App Review used. Rehearse with a similar setup:

• Simulators: a smaller and a larger iPad model, each in both orientations. Launch an iPhone-only build on an iPad simulator too – it opens in the same compatibility window the reviewer saw.
• Real device: install the TestFlight build, sign in with the demo account and walk through sign-up, purchase, sharing, uploads and settings.
• Windows: open the app in Split View or Stage Manager and shrink it to its narrowest width.
• Input: touch first, then a hardware keyboard and a trackpad.
• Web inspection: with isInspectable enabled in a debug build, Safari's Web Inspector on your Mac shows which layout and user agent your server actually delivered.

Universal apps also need 13-inch iPad screenshots in App Store Connect; show real iPad layouts, not stretched iPhone captures – see our screenshot guide.

In your reply, name the iPad models and iPadOS versions you tested, describe each fix and attach a screen recording of the flow that failed. Web fixes are live without a new build; native fixes need one. If you're convinced the build works on the reported iPad, you can appeal to the App Review Board – one appeal per rejected submission – or request a 30-minute App Review appointment via Meet with Apple. If you'd rather not write the reply yourself, appsubmitter.io handles that part, too.

Where WebViewGold and appsubmitter.io help on iPad

WebViewGold, the website-to-app solution made by our team, has settings aimed at these iPad questions:

• Separate user agents for iPhone and iPad (useragent_iphone, useragent_ipad) – leave them empty for the default iOS user agent or set an iPad value your server understands.
• iPad orientation (orientationipad: portrait, landscape or auto), set independently of the iPhone.
• An iPad switch for the bottom bar (iPadBottombar), because the home indicator may not need the extra bar on larger screens.
• Native features such as the share dialog, file downloader and AirPrint that web buttons can trigger – test each on an iPad, like any native flow.

WebViewGold is a one-time purchase; you get the Xcode project and publish in your own account, or build in the browser with the separately sold Cloud Builder. It won't make a desktop-only website responsive – that stays in your web code, and no tool can promise an approval.

appsubmitter.io covers the submission side: AI-powered pre-submission checks with an App Specialist on top, screenshot guidance, review notes and the conversation with App Review. Book a free consultation call or choose the iOS package; code and layout changes are quoted separately 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 2.4.1 on [iPad model] running [iPadOS version].

We reproduced the issue on iPad and fixed it:

1. [Issue, e.g. the app displayed our desktop website on iPad] – [fix, e.g. our website now uses one responsive layout for all iPad sizes].
2. [Issue, e.g. tapping Share crashed the app] – [fix, e.g. the share sheet is now presented as a popover anchored to the tapped button].
3. [Issue, e.g. buttons were cut off in a narrow window] – [fix, e.g. the layout now adapts to every window width].

We tested on [iPad models] with [iPadOS versions], in portrait and landscape, in full screen and in Split View. [The website changes are live; build [build number] contains the native fix.]

To verify: [steps, e.g. sign in with the demo account, open an item, tap Share].

Demo account: [username] / [password]
A screen recording from an iPad is attached.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• The issue was reproduced on the iPad model and iPadOS version from the review device details.
• Your server doesn't pick desktop or mobile templates by user agent – or the app requests content that matches.
• App detection appends to the default user agent instead of replacing it.
• Layouts work from a narrow Split View window up to a 13-inch iPad in landscape.
• Navigation works by touch alone; hover is only an enhancement.
• Every native share sheet or action sheet triggered from web content has a popover anchor.
• Uploads, downloads and printing were tested on a real iPad, including the camera option.
• Charts, maps and carousels re-layout after rotation and window resizing.
• If you use WebViewGold, the iPad user agent and orientation settings match your website.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 2.4.1 Hardware Compatibility
• Apple Developer Documentation – WKWebpagePreferences.ContentMode
• Apple Developer Documentation – preferredContentMode
• Apple WWDC19 – Introducing Desktop-class Browsing on iPad
• Apple Developer Documentation – applicationNameForUserAgent
• Apple Developer Documentation – UIActivityViewController
• Apple Developer Documentation – webView(_:decidePolicyFor:preferences:decisionHandler:)
• WebViewGold documentation – Configure WebViewGold (iOS)

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.