Your iPhone is already on iOS 26, but a browser detection tool still reports iOS 18.6. What is going on here? The data showed iOS 26 adoption looking unusually low, a figure that was quickly read as slow upgrade momentum.
Daring Fireball and other technical outlets later pointed out that the real cause may not be users skipping the update at all, but analytics systems failing to handle the User-Agent (UA) change in Safari 26.
For developers who rely on UA to identify devices, this shift is worth a closer look. It does not just skew iOS version statistics; it can also throw off browser compatibility checks and device classification.

Let's start with two typical Safari UA strings.
iOS 18.6 Safari:
Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.6 Mobile/15E148 Safari/604.1iOS 26.0 Safari:
Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1The most obvious difference is the Version/ field, which moves from 18.6 to 26.0, while the iPhone OS field still reads 18_6. This is not a failed system upgrade. Apple deliberately changed what the UA reports.
One caveat: the frozen value may shift again with later Safari updates. Some subsequent builds already carry an 18_7 token. That means 18_6 should not be treated as a permanent condition for your detection logic.
Many UA parsers extract the system version from a field like this:
const ua = navigator.userAgent;
const match = ua.match(/iPhone OS (\d+\_\d+)/);
console.log(match?.[1]);Run that against the Safari 26 example above and it still returns 18_6. If your backend writes the result straight into a device statistics table, some iOS 26 users end up in the iOS 18.6 bucket, which drags down the share reported for the new system.
Another case: the parser checks both the system version and the Safari version. When the two disagree, it may return Unknown, or flag the record as needing verification.
Either way, Safari 26 UAs can no longer be parsed by reading the traditional system version field alone.
For a standard iPhone Safari UA, you can use the browser version as a secondary signal. Here is a simplified JavaScript example:
function detectIOSVersion(ua) {
const os = ua.match(/iPhone OS (\d+)[\_.](\d+)/);
const safari = ua.match(/Version\/(\d+)(?:\.(\d+))?/);
if (!os) return null;
if (/Safari\//.test(ua) && safari &&
Number(safari[1]) >= 26) {
return {
major: safari[1],
source: "Safari version"
};
}
return {
major: os[1],
minor: os[2],
source: "OS token"
};
}Run against the Safari 26 example above, this returns major version 26 instead of 18. That said, it is a simplified approach aimed at typical Safari UAs, not something to apply uniformly across every browser environment.
Safari version and iOS major version usually track each other, but minor and patch releases do not always line up one-to-one. So Version/26.x is a reasonable hint for the OS major version, not a definitive source for the exact build.
If all you need is whether a given web feature is available, feature detection with CSS.supports() or a JavaScript capability check is a better route than depending on a version number.
ua-parser-js has added handling for the iOS 26 UA change, and version 2.0.6 includes the relevant support.
Upgrading does not guarantee correct results in every case, though. Some versions can still misparse later tokens such as iPhone OS 18_7.
Check the release notes for the version you actually have installed, then run regression tests against several Safari 26 UA samples and confirm that getOS() returns what you expect.
It is also worth noting that Safari does not support Chromium's navigator.userAgentData interface, so that API is not a general-purpose way to obtain the real OS version on Safari.
Beyond iPhone Safari, iPad and in-app browsers can also produce device-type or OS-version misreads. UA characteristics differ between browser environments, so the same parsing rules do not carry over cleanly.
| Browser environment | UA characteristics | Common detection issue | Suggested handling |
|---|---|---|---|
| iPad Safari | Desktop-class UA by default since iPadOS 13, closely resembling macOS Safari | iPad is classified as Mac, skewing device statistics | Cross-check with navigator.platform and navigator.maxTouchPoints |
| iPhone Safari 26 | OS version token may be pinned at 18_6 or 18_7 | iOS 26 is misread as an older system | Use the Version/ field to infer the OS major version |
| In-app browsers such as Instagram and Facebook | Usually WebView-based, often carrying app-specific tokens | Browser type is misidentified, so traffic blends into Safari | Detect WebView environments separately and segment traffic data |
| Other iOS WebViews | UA format may vary with app configuration | Missing fields lead to incomplete parse results | Retain the raw UA and pair it with real feature detection |
Keep in mind that navigator.maxTouchPoints and UA fields are supporting signals only. They cannot guarantee accurate identification across all devices.
When iOS 26 shows up incorrectly, start by looking at what the browser actually sends, rather than assuming something is wrong with the device.
Open ToDetect's UA detection tool in iPhone Safari and review the raw User-Agent, the browser identification, and the device-related fields.
Focus on comparing iPhone OS against Version/. If the former reads 18_6 and the latter reads 26.0, that is your cue to cross-reference WebKit's UA change notes.
Language, timezone, screen parameters, and touch capability can also help you understand the browser environment, but none of those fields proves the real OS version on its own.
If you maintain a device statistics dashboard, keep the raw UA samples and re-check historical data after you update your parsing logic.
• iOS 26 shows up as iOS 18.6 — is the browser malfunctioning?
Usually not. Safari 26 changed the OS version token in the UA, so older parsers can end up reporting the wrong result.
• Does the same thing happen with Chrome and Firefox on iOS 26?
Different browsers handle UA differently, so Safari's rules do not transfer directly. Test the actual UA in each one.
• Why is the iOS 26 share in my dashboard so low?
Most likely your UA parsing rules have not caught up yet. Verify the raw data and the parser version before drawing conclusions about real adoption.
The Safari 26 User-Agent change makes one point clear: UA strings are no longer a suitable place to carry the entire burden of precise OS version detection.
For developers, the priorities are updating parsing rules, validating against real UA samples, and favoring feature detection. For site operators, it is worth re-checking whether your iOS version distribution was distorted by outdated statistics logic.
Reviewing browser UA and device environment details in ToDetect gives you a more direct reference when you are tracking down version detection anomalies.
Efficiently solve multi-account management, environment isolation, and account security