Safari on iPadOS13 – a web dev’s guide.

8 min readJun 9, 2019

iOS13 has appeared to bring us lots of goodies for developers and pro users, including a new browser on a new operating system; Safari on iPadOS. So what is in this latest browser for web developers?

Quick caveat — this article was written after WWDC19 with beta1, but all the information holds true with the shipping version of iPadOS13.1

To get it out of the way, we’re not getting multiple browser engines in 2019 – or at least not in the way we expected. That means no Blink on Chrome/MS Edge/Opera and no Firefox. That might seem “courageous” or foolish in a class-action-heavy world, but I’m more disappointed that it means I still won’t be able to check output across any other browser engines apart from WebKit – unless I use an online service such as BrowserStack. Next year maybe.

The “desktop class browsing” element of Safari on iPad OS is the tent pole feature and it’s both exciting and a little scary. I have to hold judgement until we all get to see it on many more websites for real, but it hopes to achieve this with several tricks – many of which seem very familiar to those building web experiences on iOS since the beginning.

User Agent string

The most obvious is it no longer identifies itself to web servers with the iOS Safari User Agent (UA) string, but with the MacOS Safari one instead. You can try this out today – just do a long tap on the reload button and a context menu will appear giving you the option to “Request desktop site”. This will now be the default.

90% of the time, this will (and should) make no difference, but some sites used it as the breakpoint between sending a desktop design, or a completely different “m.” mobile variant – that often falsely assumed the “iOS” in the UA string equated to “mobile”.

There was a bit of a backlash to some lazy responsive design practices a few years ago that made it a popular strategy. If done right and given resources, it gives focused user experiences, but often it just resulted in two lazily built code bases, one always lagging the other, with the mobile one sent to iPads. Apple is now trying to work around this mess.

Hover states

The trickiest optimisation to my mind is dealing with hover states. Touch devices don’t do :hover states for obvious reasons, but some sites use them to reveal content or navigation. To square this circle, Safari on iPadOS is trying to guess if:

a hover state is just a small aesthetic change – eg, a colour change – in which case a tap would still act as a regular click.
or it results in a “meaningful change” (Apple’s words) – eg, a mega-menu drop-down – wherein the first tap will carry out the hover state and a second tap will act as the click.

This all sounds very similar to WebKit behaviour on early versions of iOS, which was pretty unsatisfactory as it felt as if there was a random generator determining if a link worked, or just changed colour. But I’m guessing that improvements in CPU/GPU speed and off-canvas composition have made it possible to do more pre-rendering to decide on the course of action without increasing lag significantly. We’ll see.

Site resizing on screen

iPad Safari also has some changes to how it resizes websites on screen on initial page load. The blog reports so far have been confusing or a little misinformed – but the WWDC session on iPad Safari made it pretty clear.

This is essentially Apple accepting that there is often a gap between how responsive a site claims to be, and how much it actually is. Firstly, Apple is at pains to point out that if you use responsive design properly, this work-around isn’t necessary and you won’t find your site appearing different to how it did before.

But many sites paid lip-service to responsive design, and all too often added a device-width meta tag and then just catered for a fixed width mobile view and a fixed width desktop view, ignoring all screen sizes in-between. And to stand up for web devs, I’ve seen too many sites passed down as pixel-perfect desktop and mobile PSDs. Throw in a waterfall workflow and uninformed sign-off, and you logically end up in this situation.

Viewports between roughly 400px and 1000px wide (iPad-land) are susceptible to this problem, and contribute to this “not proper browser” feeling as you sometimes get half a desktop site on screen that scrolls horizontally.

Beth Dakin from the the WWDC session described the setting of the device-width meta tag as a promise to the browser, telling it that the site it’s about to parse is responsive. That promise is broken when it’s followed up with a fixed width site that doesn’t fit the screen size, resulting in the poor user experience.

Google Analytics user interface, I’m looking at you…

Safari on iPadOS13 no longer takes that meta tag as a guarantee of responsiveness. If the rendered site is too wide, it shrinks the site to fit the screen. I can’t help thinking if the WebKit team looked at their bag of tricks and realised they already had this solution, because this is the same behaviour as when a site has no device-width meta tag at all or one fixed to a set width (see daringfireball.net as an example).

I assume the difference between the old behaviour and new is similar to the hover state trick – iPads are now fast enough to do a pre-render and decide on the course of action whereas it was previously decided by the meta tag mark-up before the page needed to be rendered.

It seems a sound plan. The first question that comes to mind is with client-side rendered elements – a common example is with advert skyscraper sidebars on news sites. Will the iPad know the page is too wide before the ad-tech JS is rendered to screen? Or will it re-compose, re-paint once the page is built? It’ll be interesting to find out.

Dev tools

What Safari apparently hasn’t delivered is devtools on the iPad. You still need to hook up a Mac to get the full suite of Safari devtools (which does at least seem to have gained some nifty new energy use meters in MacOS Safari 13). So one of my biggest gripes – lack of client-side devtools – is still unsolved by Apple. The better news is that the Inspect Browser app has gained some new capabilities and gives hope for most basic on-iPad debugging, but there is a way to go before we have anything on the iPad that approaches the level of most desktop browser devtools.

Misc

One thing I’m massively looking forward to is better text selection in Safari. You can select any content text with all the new iOS13 selection gestures. An unironic “finally!”.
There are also lots more keyboard shortcuts, specifically to keep the pro web app users productive.
A download manager – including the ability to choose where you download to. The default at the moment is to download to a “download” folder on your iCloud folder. Remember your iCloud subscription limits!
The webkit-scroll-overflow hack is dead. All main frames and sub frames (iframes, overflow:scroll/auto divs) now have GPU accelerated scrolling and paint much larger areas too, so scrolling with no natural momentum, and white space whilst scrolling should be two horrors that are behind us.
There’s also mention (although little docs) about resizing hit areas for links – which is probably not a visual change but the browser optimising the virtual hit area. This could be interesting with dense link lists, although Apple’s existing track area in this area in has been amazingly reliable.
The old style iPad browser hasn’t gone away. iPad OS13 Safari alternates between the new “desktop class” rendering and the older, more familiar “mobile class” rendering, depending on the situation. For instance, in docked split-screen or slide over view it goes back to the “mobile” style rendering. And there’s even a menu to enable switching between the two.
I’m hoping that the good people at Google Analytics and Google Ads are thinking about iPad OS already. That new user agent string will certainly contribute to my GA figures seeing a fake swing from tablet to Mac OS – not a trivial mistake when marketing spend is considered. I’d think you could combine the UA string and some pointer event sniffing to spot the difference between “desktop class” Safari 13 on iPad iOS and “mobile class” Safari on all old iPads (and iPad OS13 when Safari is running docked or in slide-over – my head hurts thinking about interpreting the statistics).

Lastly, we come to two new major APIs supported in Safari 13:

Pointer events API, a modern user activated event system meant to bring together (and discriminate between) mouse, touch and even pen events. As with all great upgrades in APIs, we’ll have to live with a hell of a lot of devices with only traditional mouse and touch events support for a long time, but it’s the right thing to do and Apple held off implementing it whilst being vocal in the forming of the web standard with other vendors, so it should be a solid API.
Visual viewport API, another long-available-in-Chrome feature that suddenly seems a particularly good fit for the iOS. It allows the measurement of not only the virtual 100vw x 100vh viewport (100vh is a pretty problematic measurement on iOS), but also what part of it you can actually see. What does that mean? It means for the first time ever, we can tell when the keyboard is onscreen, and design layouts for it. How many times have you filled in a web form in iOS, only for the field you’re typing into to scroll out of view when the keyboard pops up? No more! (with a little code)

In conclusion

How exciting! Even with a few unanswered questions, as a web user and creator, it feels like quite an embarrassment of new features, most of them stemming from listening to user concerns – which were sometimes vague, but mostly very real. “Desktop class browser” is what the mob wanted, and that’s exactly what Apple billed this version of Safari as – only for the mob to suddenly ponder “yes but what does that mean”. Twas it ever thus.

What I’m wondering is if I need to think of iPad OS as a new browser target for web site development on top of Safari for pre-iOS13 iPads. A great many iPads will never get Safari 13 (or apps gain it’s associated webView), so I’m going to have to check sites on both for a long time. It seems unlikely to create a lot more work, but it’s one more platform (in two orientations and multiple resolutions) to add to the pile.

But iPad Safari is different enough and important enough that it’s going to hang around. And in their WWDC session, Apple went to great lengths to say they were building a better experience on top of standards and methodologies such as pointer events and responsive design, not offering new solutions. So that at least gives me comfort that the team is not going to accidentally balkanise the iPad OS into it’s own “desktop-ish” silo, but is aiming to optimise it on top of the modern web platform that we all aim to build for.

The public beta can not come quick enough for me.