WebView user agents on iOS

The string is the main signal available to a web page, and it has become less trustworthy in the last year.

6 August 2026 by PAD team

Anatomy of the string

An iOS WebView user agent starts out indistinguishable from Safari and gains an app-specific token at the end:

Mozilla/5.0 (iPhone; CPU iPhone OS 18_5 like Mac OS X)
AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148
Instagram 320.0.0.24.107 (iPhone15,2; iOS 18_5; en_US; …)

Everything before that last token is shared with Safari, so detection depends entirely on the token being present.

What is stable and what is not

What changed in iOS 26

Some Facebook builds stopped appending FBAV and FBAN, so their WebView presents a user agent that looks like plain Safari. Detection that relies on the marker classifies those visits as a real browser and sends them the plain store link, which then fails.

There is no replacement token. The practical response is to treat an unmarked iOS visit as possibly in-app and run the escape anyway, since doing so in a real browser is harmless.

Signals beyond the string

// Safari sets this, most WebViews leave it undefined
typeof navigator.standalone === 'undefined'

// in-app browsers keep their own chrome, so the viewport is shorter
window.visualViewport.height < screen.height * 0.72

// Safari reports a Version/ token, many WebViews do not
!/Version\/[\d.]+ Mobile.*Safari/.test(navigator.userAgent)

None is conclusive alone. Two together is a reasonable threshold, and it errs toward treating unknown iOS traffic as in-app.

Changing the string yourself

If you build an app with a WebView, you can set a custom user agent, and you should if any server-side logic depends on knowing your traffic. Appending your own token is the courteous version of what the big apps do.

Our routing keeps this detection up to date so you do not have to track platform changes.

Create a link

Related