App Development

iOS 9 & Content Blocking: What You Should Know

Content blocking 2 blog feature image-510x296

The advent of iOS 9 was accompanied by some magic words users had been waiting for a very long time to hear: content blocking. While iOS has been great, the fact that Safari was as riddled with ads as old as your grandma’s web browser was not ideal, so this promise to bring Safari into the modern era was received warmly. But before you download the first three apps that pop up when you search ‘content blocker’ in the App Store, you should have a good handle on what content blocking means in this context. It’s a little bit different than the long-standing desktop extensions and add-ons that you’re used to.

What actually _is_a content blocker?

Xcode has a Content Blocker App Extension template that will come with, among other things, a folder called ContentBlocker, which is what we’re interested in. That folder has only three files:

  • ActionRequestHandler.swift, the only swift file needed, contains the code required to run the app.
  • Info.plist, which contains the settings for the extension.
  • blockerList.json, which contains the meat of this update, or the actual array of rules.

When it gets down to it, the code that actually does the blocking is nothing more than a list of rules.

{
	“action”: {
		“type”: “css-display-none”,
		“selector”: “#advertisementDiv”
	},
	“trigger”: {
		“if-domain”: [“google.com”],
		“url-filter”: “.*” 
	}
}

Above is an example of a rule that you might find in blockerList.json. It contains an action and a trigger. According to Apple, an action tells Safari what to do when a trigger is met, and a trigger tells Safari when it should perform the corresponding action.

In this example, the type of action is css-display-none, which simply means that the targeted element will load, but be invisible. Another type of action is block, which prevents the targeted element from loading entirely. The selector represents our targeted element. Here, it is a div with an ID called #advertisementDiv, so any element with this ID will be affected. Now that the action has been defined, what’s the trigger?

In the trigger portion of the rule, we target the google.com domain. This way, if #advertisementDiv is the name of a random div in another website, it won’t be affected. The URL filter is denoted with .\*, which here means a wildcard and that any resource under the  google.com domain is game! To sum it all up, this rule is telling us that it will make any element with that particular selector under the  google.com domain invisible. And because the Swift file is written for you, technically, only JSON knowledge is needed to write one of these blockers. Pretty nifty, huh?

It should be noted that when you add a content blocker, not only does it change your Safari browsing experience, but it is also applied to any app that uses the new SFSafariViewController that came with the advent of iOS 9 as well.

That’s great, now how do I add one?

Installing a content blocker is a surprisingly simple task. First, do what you’re used to! Research all of the blockers on the market and choose an experience that best fits you. Some apps make it as simple as flipping a switch, and others itemize what they block, and even allow whitelisting for greater user control. Once you’ve chosen the app(s) that suit your purposes, go ahead and download it. If you attempt to open the app right after install, you’ll probably be met with a prompt telling you that blocking can’t start until you take further action.

  • In order to activate the content blocker, you’ll likely have to go to Settings, then Safari, and finally Content Blockers to toggle the blocker you chose. Here’s a video example of how to turn on a content blocker.

blog-post-image iOS-9-contentblocking RS-301x282@2x

  • After this, depending on the app you’ve chosen, you can go back into it and customize your web browsing experience! Now, you get to choose what you do and don’t want to see.

Okay, I know how. But should I do it?

Whether or not you should use content blockers is up to you. If you’re looking for a reason to take advantage of this new feature, they abound:

Reason 1: It’s ad blocking! Finally! Ad blocking has been around for a while now, so it was only a matter of time before Apple caught up its mobile devices. With ad-blockers, you have the potential to save a ton of CPU time and RAM. Things like auto-playing movies, screen-length ads, or late-loading ads that show up just before you tap something and cause you to tap it instead, are a thing of the past.

Reason 2: At the time of writing, there are already numerous highly-rated ad-blocking apps in the App Store, both free and paid. They have different levels of user involvement, so whether you are a power user that likes to choose which individual cookies to block, or if you’re just looking for a generally more pleasant browsing experience, odds are the App Store has you covered.

Reason 3: Apple addressed speed and privacy concerns fairly well here: when you switch on the blocker, iOS runs the app and finds the blockerList.json file, generates optimized bytecode based on the rules parsed, and passes that to Safari. Because bytecode can be read quickly, Safari knows equally quickly what content to block without letting that information get in the hands of third-parties. Information only flows one way, and your preferences aren’t exposed to those who might want to find them.

However, all new technology comes with unexpected setbacks and hindrances, and Apple’s new content blocking feature is no exception:

Warning 1: Removing ads and trackers can hurt the companies we love. One reason why there are so many ads in the first place is because a lot of companies (especially those that offer their services for free) thrive on ad revenue. In the grand scheme of things, if you appreciate your free cloud storage or email service, this is something you should consider.

Warning 2: There is always the potential to take things too far. Some larger-name ad-blocking companies have thousands of rules in their JSON files that ultimately slow down Safari further because they need to be read. If you don’t have the latest iDevice, you might have a tougher browsing experience than expected.

Warning 3: Keep in mind that because this is new, nothing is set in stone. Currently, if the compiler detects a set of rules that negatively impacts your experience, then it will refuse to load your rules. As one can imagine, this could have disastrous effects on apps with tons of ad-blockers, and limits more ‘creative’ ad-blocking. Also, if you meant to limit blocking to Safari alone, you’re out of luck because the rules apply not only to Safari, but to any app that uses the new SFSafariViewController. Currently, there is no way to change this.

The final verdict

Content blocking is something that we highly value—in fact, it’s one of the reasons why Internet browsing is more than just tolerable. Most of us have had blockers on so long that we’ve forgotten what an unfiltered web looks like. Though the tech is new, it is still very effective! While there are limitations and other hindrances to consider, whether you want to either try your hand at creating a blocker or install one on your favorite iDevice, both tasks are surprisingly easy to accomplish. Furthermore, developer and user feedback only make the features better for us all. Happy experimenting!

Quickstart-Guide-to-Kotlin-Multiplatform

A Quick Start Guide to Kotlin Multiplatform

Kotlin Multiplatform, though still experimental, is a great up-and-coming solution...

Read the article