In-app browsers in iOS 26

One quiet change broke detection code across the industry, and there was no announcement.

6 August 2026 · PAD team

The change

Some Facebook builds on iOS 26 stopped appending FBAV and FBAN to the user agent. Their WebView now presents a string indistinguishable from Safari.

Nothing was documented and no replacement marker was introduced. The first sign for most publishers was a drop in whatever metric depended on recognising that traffic.

Why it matters

Detection code written before the change classifies those visits as a real browser. That means it skips the escape sequence, sends the plain store link, and the tap dies on a blank page. The routing is technically working as written and failing in practice.

What to do instead

Treat an unmarked iOS visit as possibly in-app and run the escape anyway. In a real browser the first hop fails silently and the plain store link opens, so the cost of being wrong is nothing.

// combine signals rather than trusting one
const suspicious =
  typeof navigator.standalone === 'undefined' &&
  !/Version\/[\d.]+ Mobile.*Safari/.test(navigator.userAgent);

The broader lesson

Every escape route and every detection marker in this field is undocumented. They work until a platform decides otherwise, without notice, and the failure is silent on both ends.

That is an argument for measuring delivery continuously rather than testing once. A routing setup that reports how many taps escaped will show a change like this within a day. One that does not will hide it for months.