Safari 26.3 Is Here, and the iPad Is Still Pretending to Be a Mac

Safari 26.3 dropped yesterday with a new compression algorithm, some Navigation API improvements for single-page apps, and a handful of bug fixes. It’s a fine update. Perfectly competent. And it does absolutely nothing to address the fact that iPadOS Safari has been living a lie since 2019.

I’m talking about the identity crisis. When Apple launched iPadOS 13, they made a big deal about “desktop-class browsing” on the iPad. Part of that meant changing Safari’s user agent string so it was identical to macOS Safari. The iPad would tell every website it visited, “Hey, I’m a Macintosh.” And to this day, that’s exactly what it does. Safari on iPadOS 26.3 sends the exact same user agent string as Safari on macOS 26.3:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Safari/605.1.15

Your M4 iPad Pro running iPadOS 26.3 is telling every website it’s an Intel Macintosh running macOS 10.15.7 - an operating system from 2019, on a chip architecture Apple stopped selling years ago. Apple froze that string for privacy and compatibility reasons, and it’s the same on actual Macs too, but the result is that your iPad is wearing a disguise that doesn’t even match reality for the device it’s impersonating.

The idea was simple enough. Websites were serving iPad users dumbed-down mobile versions of their sites, and Apple wanted to fix that. By pretending to be a Mac, Safari on iPad would get the full desktop experience. And to Apple’s credit, they did a lot of work under the hood to make it function, adding pointer event support, adjusting viewport behavior, using heuristics to simulate hover interactions from touch input. It wasn’t just a user agent swap. They rebuilt a lot of how WebKit handles the gap between touch and mouse.

But here’s the thing. They didn’t actually give us macOS Safari. They gave us iOS Safari in a desktop costume. And that’s the real problem.

iPadOS came directly from iOS, and Safari on iPad has always behaved more like mobile Safari than its macOS counterpart. The rendering engine is WebKit on both platforms, sure. But the browser shell, the viewport handling, the input model, the way it manages keyboard focus - all of that comes from the iOS side of the family tree. That’s why position: fixed elements still break when the software keyboard appears. It’s why keyboard focus doesn’t work the same way as on macOS - clicking a button in Safari on iPad doesn’t focus it, which breaks accessibility patterns that work fine on the Mac. It’s why web apps still throw up those obnoxious banners telling you to install their iOS app. It’s why scrolling behavior, trackpad cursor handling, and window resize events all feel slightly off compared to the Mac.

Apple actually made this distinction themselves when it was legally convenient. When the EU classified Safari as a gatekeeper under the Digital Markets Act, Apple argued that Safari on iOS, iPadOS, and macOS are “totally different products” to try to avoid regulation. So even Apple admits they’re not the same browser when there’s something at stake.

The result is a browser that tells websites “I’m a Mac” but behaves like a phone. Websites that trust the user agent string serve you desktop layouts designed for mouse and keyboard. Websites that probe deeper discover you’re a touch device and serve you something else. And websites that don’t bother checking either way give you a desktop interface that half-works with touch because the underlying browser was never really built for it.

And websites can tell. They don’t just use the user agent string to figure out what you are. They check for touch events as a proxy for “mobile.” They look at viewport dimensions. They check navigator.maxTouchPoints, which returns 0 on a Mac and 5 or more on an iPad, instantly blowing the cover. They use CSS media queries. Some of them use fingerprinting services like WURFL that can see right through the disguise.

I run into this constantly. I use my iPad Pro as my primary device for writing, and the web experience is a minefield of half-working interfaces. A site serves you its full desktop layout because Safari told it you’re on a Mac, but then hover menus don’t work right because you’re tapping a touch screen. Or a web app detects the touch input, decides you must be on a phone, and crams everything into a narrow mobile layout on a 13-inch display. Google Docs is better than it used to be, but keyboard shortcuts and selection behavior still don’t match the Mac version. Certain banking sites still kick me to their mobile apps. MLB.tv has historically refused to stream in-browser on iPad, insisting you use the native app, because it can tell you’re not actually on a Mac no matter what your user agent says.

And now Safari 26 has made the identity situation even more convoluted. Apple extended the frozen user agent string to iOS too, so Safari on an iPhone running iOS 26 still reports the OS version as iPhone OS 18_6. The macOS string was already frozen at 10_15_7 for years, but now iOS joins the party. This actually broke analytics tools. StatCounter and MacRumors both reported absurdly low iOS 26 adoption rates earlier this year because they were only counting third-party browsers like Chrome and Firefox that still reported accurate version numbers. Safari users were invisible because the user agent was lying about the OS version. Nick Heer at Pixel Envy was one of the first to figure out what was happening, and StatCounter’s CEO eventually confirmed the error. On iPad, the string hasn’t changed at all since iPadOS 13, still claiming to be an Intel Macintosh running a six-year-old operating system.

I get why Apple did this. User agent strings have been abused by web developers for decades to serve different experiences to different browsers, and the whole concept is kind of broken. Apple freezing the version number is part of a broader industry push toward feature detection instead of device detection. In theory, websites should check what your browser can do, not what it claims to be.

In theory. In practice, we’re nowhere close.

The web is still full of sites that sniff user agents, check for touch events as a proxy for “mobile,” and make decisions based on screen size that don’t account for a 13-inch tablet. Apple’s own documentation recommends feature detection over user agent sniffing, which is the right advice, but it doesn’t help me when I’m trying to use a web app that was built by developers who didn’t follow that advice. And the Apple Developer Forums are full of developers who’ve been complaining about this exact problem since 2019, with no real resolution.

So when I saw the Safari 26.3 release notes today, I went looking for anything that might address this. Anything about how iPadOS presents itself to the web. Anything about viewport behavior, touch event handling, or the ongoing identity fraud that Safari on iPad commits every time you load a webpage.

I found Zstandard compression. A Navigation API abort signal. A fix for anchor positioning when a box is inside a display: none ancestor. A fix for HDR JPEG gain maps on positioned images. A fullscreen video dimming feature for visionOS.

All useful stuff, probably. Definitely not what iPad users need.

What frustrates me is that Apple clearly knows the iPad exists in this uncomfortable space. They’ve spent years making iPadOS more capable, adding Stage Manager, improving multitasking, pushing the hardware to laptop-level performance with M-series chips. They sell an iPad Pro that starts at over a thousand dollars and they market it as a computer replacement. But the web experience, the thing most people use a computer for more than anything else, is still fundamentally compromised by a six-year-old hack that pretends the iPad is something it isn’t.

The fix isn’t simple, I know that. You can’t just add “iPad” back to the user agent string without breaking the desktop site delivery that millions of users depend on. And you can’t force every web developer to adopt proper feature detection. But Apple could do something more fundamental. They could actually give us macOS Safari on iPad. Not mobile Safari pretending to be macOS Safari - the real thing. Or at minimum, they could close the behavioral gaps between the two so that the disguise actually holds up. Fix keyboard focus. Fix position: fixed with the software keyboard. Stop letting web apps detect that you’re on a touch device and shove their app install banners in your face. Make the browser behave like the thing it claims to be.

Safari 26.3 is a perfectly fine point release. But every time Apple ships one of these incremental updates without addressing the iPad’s web identity crisis, it reinforces the feeling that they’ve decided the current situation is good enough. For those of us who actually try to use the iPad as our primary device, it isn’t. Not yet.

Don’t get me wrong, I love my iPad Pro. I write on it every morning at 6am, and for most of what I do, it’s exactly the machine I need. But every time Safari pretends to be a Mac and a website calls the bluff, I’m reminded that Apple sold me a “desktop-class” browsing experience that’s really more of a costume party. The iPad shows up wearing a Mac disguise, and half the web isn’t fooled.

Makes me wonder if Apple even uses iPads to browse the web anymore.