Under the Hood: Safari - The Apple iOS 9 Review

Deep linking takes care of the situations where a link in an application redirects to Safari. However, there are other ways that developers can handle links in their applications. The other major method is one you’ll find in apps like Skype and Facebook, and it’s basically a mini web browser built inside the application. These built in web browsers traditionally used UIKit’s UIWebView class, which was subject to performance constraints when compared to mobile Safari. iOS 8 introduced the WKWebView class which was just as fast as Safari, but had some issues of its own that made it difficult to implement in many situations. While iOS 9 fixes many of the issues with WKWebView, such as lack of support for loading local files with the file://URL protocol, it also comes with a much better method for developers to handle the transition from their app to Safari. This new feature is called the Safari View Controller.

The main reason for Safari View Controller’s existence is to provide a better user experience than the existing miniature web browsers that applications have built in to them to handle web links. When an application handles the rendering of web pages on its own, the user loses access to many features of Safari like their password keychain, their stored credit card info, their cookies, and more. The obvious solution to this is to just use Safari, but that has traditionally come with the cost of moving the user out of their current application. This is certainly improved with the addition of the back link in iOS 9, but it would be much better if those mini web browsers could just be replaced by Safari running inside of an application. That’s essentially what Safari View Controller is.

When an application uses Safari View Controller to handle web content, the user will be presented with the interface above after clicking on a link. It’s very similar to Safari’s interface, but with a few alterations to let the user know what has happened. For starters, there’s a button in the upper right that says “Done”, which is a fairly obvious control to return to the application. The URL bar at the top is also greyed out, which indicates that you can’t change it. If you do want to start surfing the web, there’s a button in the bottom right to open the actual Safari application. Developers can also specify a custom tint color for the UI so users remember what application they’re working within.

While Safari View Controller gives the user access to all of their data like passwords, credit cards, and cookies, none of this information is provided to the host application. This is because Safari View Controller is actually running in a completely separate sandboxed application, which means that users don’t have to worry about the security of what they input or where they visit. This is also helpful for developers who don’t want to deal with the privacy implications of having users input into their own built in mini browser. What’s also useful for both developers and users is the ability to specify custom options in the Safari View Controller share sheet, such as a button that can share the current web page to a social network or to a contact via an instant message.

Since applications haven’t taken advantage of Safari View Controller yet it’s difficult to really communicate the advantages it provides. However, I think everyone can appreciate the improved user experience that comes with having access to all your web browser content in a safe and secure manner within any application. Since Safari View Controller also makes a developer’s life a lot easier by taking away the need to build a mini web browser UI, I think it will see significant and speedy adoption among new and existing applications.

I mentioned earlier in the review that Apple News ends up freeing you from the terrible ads, trackers, and slow JavaScript code of the modern web. However, the fact of the matter is that almost every user will have to use Safari or another web browser to do things on their phone, and most will use one on a daily basis. If your task isn't reading news, then Apple News can't protect you from the cruft of the web. One solution is to use native apps for websites, but it's hardly the case that every website offers their own app. The other solution is what we get in iOS 9, with a new Safari feature called Content Blockers.

Safari Content Blockers are extensions that provide Safari with a list of rules which defines content or resources on webpages that should not be shown or even loaded. The list of rules is written in JSON, and the syntax is simple enough that it really wouldn't be that difficult for most people to figure out how to make their own Content Blocker on their own. Having a relatively user-friendly syntax is also important because iOS 9 now allows you to sideload applications and extensions without having to pay the yearly $99 for an iOS developer account so long as you're compiling from source. This means that users can write and install their own Content Blocker with Xcode, or download and install an open source one from the web.

Pretend that you're reading AnandTech, and you're really annoyed at the Twitter sidebar on the right for whatever reason. You decide to write a Content Blocker to remove it, and the code for that blocker is what's shown in the Xcode project window above. As you can see, it's fairly readable code. The action applies the css-display-none attribute to page elements matching the selector, which is article.twitter in this case. For the trigger section we have the url-filter set to .* which means anything, as we want to indiscriminately eradicate every part of the Twitter feed. To make sure it doesn't affect content on other sites we tell it to only apply if the domain matches AnandTech.com or any of its subdomains.

Once you install an application that provides a Content Blocking extension, a new Content Blocker menu will appear in the Safari section of the settings app. In that menu you can enable or disable the Content Blockers that exist on your device. There's not much more to it once you enable the Content Blocker. If you were to install this and load any page on AnandTech the Twitter sidebar would be completely gone. It's worth noting that Content Blockers can only be installed on ARMv8 devices, which limits it to any device with Apple's A7, A8, or A8X SoCs.

While blocking specific content is one application of Content Blockers, you can create rules that apply to large swaths of content. The application that I'm sure many users are thinking of is blocking advertisements, and trackers. It is true that you can make Content Blockers to remove advertising, and I have no doubt that there will be ad blocking apps available very soon. As a writer, I can only do my job because this website is funded by advertising revenue, which would disappear if everyone blocked ads. At the same time, I recognize the fact that ads almost always come along with privacy violating tracking, garbage JavaScript code, and a long period of network activity which keeps your device's radio working and drains your battery. I'm not going to get involved in the debate about the ethics of ad blocking, but I did make an ad blocker for AnandTech to show what changes it makes to load times and page sizes.

The top image show a timeline of the network activity, page rendering, and JavaScript execution for the AnandTech home page without any advertisements or tracking scripts disabled. The bottom shows those same metrics when they are all blocked using a Content Blocker that is only a couple of lines longer than the one above I used to remove the Twitter sidebar. As you can see, the difference is absolutely enormous. Without Content Blocking it takes 1.43 seconds to just load in the core site content, which is over double the amount of time with Content Blockers. 1.43 seconds doesn't sound like a lot when it's not even one second longer, but it's extremely noticeable once you see how quickly the page loads with the blockers. There's also a 2.5MB reduction in data usage, and it's worth noting that there are sites that load even more than 3.5MB with ads. I'm not in the business of public shaming, but other people have already published the results of using Content Blockers on other websites and all I can say is that while 3.5MB is not amazing, it can get even worse.

The most shocking thing of all is the reduction in network traffic. With no ads firing trackers your network requests end when the page loads. Without the Content Blockers you can see that the network requests continue. The results vary, but I've seen it go as long as 25 seconds. Those 25 seconds are a period where your data is being used, and your radio is actively in use which is draining your battery without you even knowing it.

Like I said before, I'm not going to take a stance for or against adblocking. I will say that as a user, one never really gives explicit permission to be tracked, and it's just implied by your use of a service which makes it less clear to the user what exactly they're consenting to. I'll also say that the ad experience on the web is nothing short of terrible. If ad blocking becomes a big thing in mobile the publishers and ad networks are going to have to fix the intrusiveness and slowness of ads, or move inside applications like Apple News where another company that does know how to implement them in a user friendly manner can do it for them.

ncG1vNJzZmivp6x7orrAp5utnZOde6S7zGiqoaenZIZ3fJRoq6GdXZ68tHmYZqmerpmaxHB9jw%3D%3D