In-app browser not working on iOS
An in-app browser looks like Safari and is not Safari. Most of the confusion comes from the handful of things it deliberately will not do.
6 August 2026 by PAD team
What it is
Apps that open links internally use WKWebView, the same rendering engine as Safari, wrapped in their own interface. Pages render identically. The differences are in permissions and in what the container is allowed to hand off to the rest of the system.
The list of what breaks
| What fails | Why |
|---|---|
| App Store links | Apple redirects to itms-appss://, a scheme the WebView cannot hand off |
| Existing logins | separate cookie jar from Safari, so sessions do not carry over |
| Apple Pay and 3-D Secure | need a native sheet or a new window the container will not open |
| File downloads | no download manager in most containers |
window.open in new tabs | usually ignored or opened in place |
| Camera and microphone | permission prompts often suppressed |
The store link case in detail
This is the one that costs money, so it is worth understanding rather than working around blindly. When anything on iOS requests a store URL, Apple answers with a redirect:
GET https://apps.apple.com/us/app/example/id123456789
→ 302 Found
Location: itms-appss://apps.apple.com/us/app/example/id123456789Safari closes the page and opens the App Store. A WebView has no handler for that scheme and cannot pass it to another app, so navigation stops silently.
Neither Apple nor the app vendors consider this broken. Apple redirects to a custom scheme so the native store opens rather than a web page, and the apps keep visitors inside their browser to measure them.
Working around it
For store links, escape the WebView before Apple's redirect fires, using instagram://extbrowser where available and the store scheme directly elsewhere, with a visible button as the last resort. The full sequence with code is in the main write-up.
For logins and payments, the same principle applies earlier in the flow: get the visitor into the real browser before the sensitive step rather than discovering halfway through that the container will not cooperate.
For the store link case specifically, our link does the detection and the escape, and reports which taps made it out.