WebView, in-app browser and Custom Tabs
The words are used interchangeably and describe three arrangements with very different consequences for anything you link to.
6 August 2026 by PAD team
The three arrangements
| What it is | Shares your browser session | Can hand off store links |
|---|---|---|
WebView (WKWebView, WebView) | no | no |
| In-app browser (a WebView with chrome) | no | no |
Chrome Custom Tabs / SFSafariViewController | yes | yes |
WebView
A rendering component embedded in an app. The app controls navigation and can read what happens inside. Cookies are separate from the system browser. Custom URL schemes cannot be handed to other apps unless the host app explicitly implements it.
In-app browser
A WebView plus an address bar, a back button and a menu. Instagram, Facebook, TikTok and LinkedIn all ship one. From a web page's point of view it is a WebView, with all the same limitations.
Custom Tabs and SFSafariViewController
A different thing entirely: the system browser rendered inside the app's window. It shares cookies and sessions with the real browser, and it can open store links because it is the real browser wearing a different frame.
Telegram on Android uses Custom Tabs, which is why store links generally work there while failing in Instagram on iOS.
Why apps choose the worse option
Measurement. A WebView lets the host app see and instrument what the visitor does. Custom Tabs do not. That is the whole trade, and it explains why the apps with the most advertising revenue use the most restrictive option.
What this means for you
You cannot influence which container your link opens in. What you can do is detect it and route accordingly: escape from a WebView, do nothing special in a Custom Tab or a real browser. Detection markers per platform are in the detection write-up.
We detect the container and only run the escape where it is actually needed.