iOS in-app browser user agents
When a link opens inside an iOS app's embedded browser, the page renders with WebKit but the user agent often lacks the trailing Safari token that standalone Safari carries. That missing-Safari-token quirk, sometimes with an app-specific marker, is the clue that you are seeing in-app browsing on iOS rather than Safari.
The missing-Safari-token quirk
On iOS, apps embed web content using the system WebKit components. Standalone Safari's user agent ends with a Safari token, but an in-app webview frequently does not include that trailing Safari token, even though it carries the AppleWebKit and platform descriptors.
That absence is a recognised cue: a WebKit-based iOS string without the closing Safari token usually came from an in-app webview rather than Safari itself.
- iOS in-app webviews render with WebKit
- They often omit the trailing Safari token Safari carries
- Some apps add their own marker token to the string
Reading in-app iOS traffic carefully
Some apps append an app-specific token, but many do not, and the exact behaviour varies by app, by the webview API used, and by version. So the missing-Safari-token cue is a useful hint rather than a guarantee, and app-specific markers should be treated as hints too.
Because these specifics differ across apps and change over time, confirm exact tokens against each host app's developer documentation rather than assuming a fixed shape. This is why the entry is marked partially verified.
How it appears in analytics and logs
An iOS WebKit user agent that omits the trailing Safari token typically indicates an in-app webview rather than standalone Safari. The page is rendered inside another app, not in the Safari browser.
Diagnostic use case
Recognise iOS in-app webview traffic, distinct from standalone Safari, by the missing trailing Safari token and any app-specific markers.
What WebmasterID can help detect
WebmasterID recognises common iOS in-app webview patterns server-side and records a coarse in-app category, keeping ambiguous strings in an honest bucket rather than guessing standalone Safari.
Common mistakes
- Counting iOS in-app webview sessions as standalone Safari.
- Assuming every app adds a recognisable app-specific token.
- Hard-coding app marker tokens that differ across apps and versions.
Privacy and accuracy notes
These user agents describe the rendering context and device class, not a person. WebmasterID stores a coarse browser/context category, never a real visitor's raw string.
Related pages
- Android WebView user agent
Android WebView is the embedded browser component native apps use to show web content in-app. Its user agent is Chrome-like but includes a wv token, signalling the request came from inside an app rather than a standalone Chrome. This page explains the pattern and why WebView traffic is a distinct context.
- Safari user agent on iOS and macOS
Safari's user agent is built around WebKit and a Version token, and differs between macOS and iOS. A notable quirk is that iPadOS can present a desktop-class Safari user agent, which can make an iPad look like a Mac in logs. This page covers the pattern and the platform-specific behaviour.
- Bot vs human traffic
Separate real visits, including in-app browsing, from automation.
Sources and verification notes
- MDN — Browser detection using the user agentIn-app webview behaviour varies by app; verify exact tokens against host app docs.
- MDN — User-Agent header
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.