When the first beta of iOS 10 was released it didn't take long before some web developers discovered that user-scalable=no stopped working on their websites. Soon issues started popping up at Stack Overflow and drama happened. Probably some developers are already working on their JS plugins to fix this and gain some extra stars on Github.

But it shouldn't be a big drama, and frankly, we shouldn't make JS polyfills to fix this. Because it isn't broken. As we can see from the release notes of the first beta of iOS 10, Apple did indeed disable this intentionally.

Safari

  • Content Blockers may stop working after upgrading to iOS 10 beta 1. Workaround: Go to Settings > Safari > Content Blockers and toggle the content blocker switch.
  • Fixed a bug where no progress was shown while downloading large files.
  • You can now close all tabs in Safari at once by long tapping on the Tab View button.
  • To improve accessibility on websites in Safari, users can now pinch-to-zoom even when a website sets user-scalable=no in the viewport.

And they're right. By default a user on iOS can pinch to zoom on mobile websites, if they can't read something, want to zoom in on an image, you name it. It's the default user behaviour, and it makes sense. Some developers or designers like to prevent people from scaling so their website always looks pretty and like it was designed. Instead, just set an initial viewport scale and be done with it. Don't worry!

<meta name="viewport" content="width=device-width, initial-scale=1">

The only acceptable use case are embedded mobile web apps. Web apps that look like apps and feel like apps.

Luckily, this behaviour is only applying on Safari Mobile. So that means that web apps or apps with embedded web views will still respect user-scalable=no.

It's all good boys, keep calm and have a beer! 🍺

Comments (11)

  • Gravatar Hugo

    Even user-scalable=no doesn't fix this issue. Whatever I set, I can always zoom the webapp. This is bad, really bad.

  • Gravatar Wouter

    @Hugo: If it's really a web app (embedded in a webview) user-scalable=no does work. If you're talking about a mobile website, than no, that doesn't work. Expected behaviour in iOS 10.

  • Gravatar Werner

    By doing this they have effectively broken all web games that have there own double-tap and pinch functionality. By stopping developers from being able to control the scale, they've killed an entire application class (games) in favor of supporting a minority. A lot of people don't want to install an app to play a game, this move is crippling the web gaming experience and forcing people into apps where Apple can make a profit.

  • Gravatar Sean

    Not only is this terrible for games, but for any web app that has it's own zooming requirements. I have a full-screen google map application that relies on pinch to zoom. If the page itself zooms-in, then the user is completely screwed. The navbar is zoomed out of the view and then the maps zooming usually kicks-in and the so user cannot get back to the navbar. I guess I'll just have to disable zooming in Safari and force users to use the +/- buttons... what a terrible UX... thanks Safari!

  • Gravatar Kuk

    The only acceptable use case are embedded mobile web apps. Web apps that look like apps and feel like apps.

    Like games. Or basically anything not a standard A-1 blog or news-site. I get the "good intentions", however it royally screws with a bunch of completely legitimate use cases, which now have to - like us - try to write complicated workarounds that fail and cause second-hand bugs.

    This one was not thought through at all.

  • Gravatar Rui Nunes

    For the users, I mean. We developers are also users who sometimes prefer not to have to scale a webpage and we think about our web apps for our "target" audience. We do think about the experience of a user, using our app. Keep the option Apple.

  • Gravatar alban

    You do you do, there's alway a way to cheat apple tiranny: document.addEventListener('gesturestart', function (e) { e.preventDefault(); });

  • Gravatar Jan

    Keep calm... it's not that bad at all. If you have zooming events on your screen (like maps, games, etc.) they will be on priority before page zooming. Everything concerning Interaction is fine and will work as you expect. We have a maps feature on our website and all interactions are fine even on iOS 10.

    I think this is a good move from Apple, because it gives the user control over the page and size. I think "giving user control" is always a best practice advice for all UX efforts. For example, if you can't read text because it's too small for your personal eyes, you wan'T to zoom. Just think one moment about other people and not your personal point of view.

    On the other hand I'm thinking, how can you respect the iOS accessibility features on your website. For example there is a feature to increase font size. Native Apps do respect that, but how can you respect that on a website/webapp? Is there a CSS query available or is Safari content lost? Any suggestions?

  • Gravatar Georges

    Well of course i agree when it comes to zooming on text, but when it comes to creating some "story line" like websites, that uses lots and lots of animations and fixed position elements, it really destroys the idea. I don't think apple should force us developers to change website designs, after all it is a user interface and user experience approach and people have subjective opinions so why remove an option that is widely used for many use-cases ?

    It is the UX professional that should decide whether the user should be able to take control over the zooming not apple.

  • Gravatar Son

    In good apple spirit they're taking a shit on both your options and opinions. This breaks my SPA which have it's own zoom mechanisms on different elements, and so I have to spend time writing a javascript block for something that should have taken less than 10 seconds if they respected webstandards. The only thing apple achieved with this is giving developers the finger.

  • Gravatar Srdjan Prodanovic

    This article comes across as arrogant, especially for people looking to mitigate something they perceive as a problem. In that context, the article is not that useful, and it's a shame it ranks so highly for these keywords.

    The solution is to use a workaround like a container with fixed positioning, or update to the latest version of Hammer.js (if that's what you're using for capturing gestures).

Post comment

Avatar