Chrome Custom Tabs
The Android answer to a question iOS still has not resolved, and the reason Android traffic rarely needs rescuing.
6 August 2026 ยท PAD team
What they are
A Custom Tab is Chrome itself, rendered inside another app's window. The host app controls the colours and a few buttons, and nothing else. The page runs in the real browser.
What follows from that
- Cookies and sessions are shared with Chrome, so users arrive logged in
- Store links open normally, because the browser can hand off
- Saved passwords and autofill work
- The host app cannot read the page or inject scripts
That last item is the trade. An app using Custom Tabs gives up the ability to observe what its users do on the web, which is exactly what the platforms with advertising revenue are unwilling to give up.
Who uses them
Telegram, many news readers, most utility apps, and a growing share of anything built by developers rather than by growth teams. Meta's apps do not.
The iOS comparison
SFSafariViewController is the closest equivalent, with the same properties: real browser, shared cookies, working store links. Apps that use it cause none of the problems described elsewhere on this blog.
The reason the in-app browser problem is an iPhone story is not that iOS lacks the mechanism. It is that the apps with the most iOS traffic choose the other option, and iOS lacks Android's intent:// escape hatch for when they do.
If you build an Android app
Use Custom Tabs for external links unless you have a specific reason not to. It takes less code than a WebView, and every store link your users tap will simply work.
For the apps that chose a WebView instead, our link handles the escape.