New Interaction Behaviors in iOS 10

Feb 2, 2017

by Dean Jackson

Last year we published a blog post about getting more responsive tapping on iOS. With the release of iOS 10, we’ve made some minor adjustments to the behavior of our fast tapping, and an important change to a very common user interaction: pinch zooming.

Fast Tapping

A common complaint on iOS 9 and earlier was that events triggered by a user tapping the screen were slightly delayed. This was because the browser was waiting to see if the gesture was a double-tap, indicating the user wanted to zoom. Once a small delay had expired without seeing a second tap, the browser would know it was a single tap and dispatch the event. This made some pages that were designed for an instant reaction to tapping feel slightly slow.

As we described in our introductory post, iOS 10 detects situations when a page can support faster taps and dispatches the events instantly, making Web sites feel much more responsive. The feedback has been very positive. However, before iOS 10 shipped we made a few tweaks to the method described in the original article. Here are the current details.

Enabling fast tapping on iOS 10 requires pages to have the following:

  1. There must be a meta tag of type viewport
  2. The viewport must be defined to have width=device-width
  3. The content must be at a scale of 1, which means both:
    a. the user has not manually zoomed off a scale of 1 (e.g. they can have zoomed, but they must have returned to the original scale)
    b. the page content wasn’t so wide that the browser was forced to shrink it to fit

Note: Explaining 3.b, WebKit often sees pages that define width=device-width but then explicitly layout content at very large widths, often greater than 1000px. These sites are usually designed for a large screen, and have added a viewport tag in the hope it makes it a mobile-friendly design. Unfortunately this is not the case. If the browser respected a misleading viewport rule such as this, the user would only see the top left corner of the content—clearly a bad experience. Instead WebKit looks for this scenario and adjusts the zoom factor appropriately. Conceptually, this behaviour is the same as the browser loading the page, then the user pinch zooming out far enough to see all the content, which means the page is no longer at a scale of 1.

Zooming Everywhere

Safari on iOS 10 allows the user to pinch zoom on every page. As a developer, you should be aware of this, and make sure your content works well when zoomed.

What changed? Prior to iOS 10, Safari allowed the content to block the user from zooming on a page by setting user-scalable=no in the viewport, or appropriate min-scale and max-scale values. This unfortunately enabled pages to pick a text size that was unreadable while giving the user no way to zoom. Also, there is now such a wide range of devices with different display dimensions, screen resolutions, pixel densities… it is very difficult to choose an appropriate text size in a design.

Now, we ignore the user-scalable, min-scale and max-scale settings. If you have content that disabled zoom, please test it on iOS 10, and understand that many users will be zooming now.

As users, we’ve all come across content that is too small to comfortably read. We know that a huge number of people appreciate this zooming improvement, even though it might mean some sites that attempt to block zooming are broken until they update.

Zooming in WKWebView Content

You might have an app that mixes a WKWebView with native content, and having the user being able to scale only that content may be inappropriate. In these cases, you can prevent the user from zooming by setting a new property on WKWebViewConfiguration:

There is new API on WKWebViewConfiguration:

var ignoresViewportScaleLimits: Bool

The default value is false, which means that WKWebView content will allow the content to block zooming. This preserves behavior with older versions of iOS.

Meanwhile, Safari and SafariViewController set the value to true. If your app uses a WKWebView in a similar manner, such as showing a large amount of text, we encourage you to change the value to true too.

For feedback, email web-evangelist@apple.com or tweet to @webkit.