iOS UA lacks navigator.standalone (iOS-Safari-only surface) — not genuine iOS Safari
br.ios_no_standalone · convicts
What it catches
iOS-Safari-SPECIFIC engine surface, FINER than br.safari_ua_no_webkit_api (window.GestureEvent, which EVERY desktop Safari + WebKit also exposes). navigator.standalone is a read-only boolean defined ONLY on real iOS/iPadOS Safari — undefined on desktop Safari, desktop WebKit (Playwright's build), Chrome, and Firefox (confirmed present on iOS Safari through 2026: MDN Navigator + Apple SafariWebContent docs; it is the PWA home-screen-mode flag Apple keeps). So an iPhone/iPad UA with navigator.standalone === undefined is not a genuine iOS Safari: it convicts a DESKTOP-WebKit runtime wearing an iPhone device — the exact residual the KS_ENGINE=webkit iOS node (loop R3) leaves, which passes GestureEvent + apple_ua_nonwebkit because it IS WebKit, just DESKTOP WebKit not iOS. This is the check that beats R3's coherent-looking iOS device. EXPERIMENTAL (w0.4, corroborating): iOS in-app WKWebViews (Facebook/Instagram/Google-app in-app browsers) ALSO lack navigator.standalone, and they carry iOS-Safari-like UAs — so real in-app traffic would trip it. FP-safe promotion needs a UA gate (an app-token / clean-Version-Safari-token filter) or corroboration; the underlying surface is sound (real full iOS Safari always defines it). GROUNDED LIVE: the R3 WebKit iPhone 15 (desktop WebKit) and a Chromium+iPhone-UA both fire ios_no_standalone; a real iOS Safari (not testable in-sandbox) defines the property and would not.
Signals it reads
browser.ios_no_standalone
How it fires
present
Bypassed by 10
Frontier evaders that reach the detector uncaught (scored only suspicious, defeating every convicting tell) — this check is not one that stops them. The red-team frontier this detection still has to convict.