In-app browsers on Android

The same apps, the same WebViews, and a very different outcome, because Android gives the page a way out.

6 August 2026 by PAD team

Two containers

Android apps open links either in a WebView they control or in Chrome Custom Tabs, which is the real browser rendered inside their window. Custom Tabs share cookies with Chrome and can hand off to other apps, so store links work without any intervention.

Telegram, many news apps and a growing number of others use Custom Tabs. Meta's apps use their own WebView, as on iOS.

Why even the WebView case usually works

Android exposes intent://, a URL format that names a target package and carries a fallback:

intent://details?id=com.example.app#Intent;scheme=market;
package=com.android.vending;
S.browser_fallback_url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.example.app;
end

If Play cannot take it, the browser opens the fallback URL. Nothing is lost. iOS has no equivalent, which is the entire reason the blank page problem is an iPhone story.

The numbers

In our own routing, taps arriving from social apps were overwhelmingly iOS. Android accounted for a small fraction, and none of those needed a manual rescue. If you are deciding where to spend engineering effort, that ratio should decide it.

What still breaks on Android

• App Links that fail verification, sending users to the browser instead of the app
• Devices without Play, where market:// and intent both fall through
• Aggressive battery savers killing the browser mid-redirect on some vendors

The first is by far the most common, and it is covered in the App Links write-up.