Benjamin Mayo, writing for 9to5Mac:

Ad blocking extensions have been possible on Safari for Mac for a long time, but plugin architecture for Safari on iOS is much more limited. With iOS 9, Apple has added a special case of extension for ad blockers. Apps can now include ‘content blocker’ extensions that define resources (like images and scripts) for Safari to not load. For the first time, this architecture makes ad blockers a real possibility for iOS developers to make and iOS customers to install and use.

This has been, for me, the most puzzling new feature in iOS 9. Why is Apple doing this? Is the demand for ad blockers on iOS so high to justify the creation of a new extension point in Safari (and tons of questionable ad blockers coming to the App Store)? Could this be related to shady ad networks still finding ways to automatically redirect web views to the App Store?

The most plausible explanation I’m coming up with is that Apple wants to make it easier to develop third-party content filters (not necessarily ad blockers, like curbi) for parental and educational purposes without workarounds (like MDM and VPN certificates), but I’m not sure.

Apple already talked in the keynote about how it had reduced the amount of space required the iOS 9 OTA update from around 4.6GB to 1.3GB, but a more transformative technology only got a passing mention: App Thinning. In short, apps in iOS 9 will leave your phone or tablet with more free space in the first place.

Say you have an iPhone 5C, which uses a 32-bit CPU and a GPU that doesn’t support the Metal API. Download a modern universal game, and that binary includes 64-bit code, iPad and “3x” iPhone 6 Plus assets, and Metal API code that it doesn’t need. It only needs the 32-bit code, “2x” iPhone-sized assets, and the OpenGL graphics code. App Slices will let your device download just the chunks your device needs.

Andrew Cunningham has a good overview of the developer features powering App Thinning, Apple’s effort to reduce app sizes in iOS 9.

I forgot that I had a similar idea in 2012, when Apple was rumored to introduce a Retina iPad that would increase app sizes going forward (as it did). I wrote:

I see two solutions. Either Apple gets the carriers to agree to larger download sizes, establishing a new “average” that should work for most apps (let’s say 60 MB as Panzarino suggests), or they rebuild the download mechanism completely by allowing devices to “ignore” resources they don’t need. The second solution would be a “cleaner” approach, in that it would address the root of this likely scenario – that is, devices downloading apps containing all kinds of images and resources for Retina and non-Retina displays.

By “localizing” images in a way languages are localized on the OS, Apple could find a way to know if an image is destined to an iPad or not. And if so, if it’s also destined to a Retina iPad, or old-generation iPad. Furthermore, in theory, this would also allow Apple to differentiate between images used by an iPhone and iPad which, right now, are always downloaded within the same, single .app package.

App Thinning – and the three core features behind it – sound promising, but we’ll have to assess their effects in practice and wait to see how many developers start supporting them. Apple doesn’t seem to be willing to discontinue lower capacity iOS devices, but at least they’re trying to save space in other ways.

iOS 9 puts a big focus on getting into apps faster and returning to where you left off quickly. As I wrote last night:

To achieve such new level of contextual interactions between Siri and apps, Apple is relying on deep linking, a feature that’s been available on other OSes or through third-party frameworks and that will be enabled by default on iOS 9. Deep linking refers to the ability to return to a specific area of an app at any given time. In Siri’s case, a deep link will let you return from Reminders to a message, but the technology will also power other areas of iOS to allow users to easily get back to where they left off in an app. For example, deep linking will be used to index content within apps for search. To make the process of moving between apps faster, Apple has built a new back button that will be displayed in the top left of the screen to return to the previous app with one tap.

Besides blurring the line between app and OS, seamless transitions between the web and apps will also be a fundamental theme of iOS 9. The implications are profound – especially for Google.

Apple is taking a dual approach with deep linking: they’re making it easy for users to navigate across apps (not to just launch them) and they’re building new technologies to expose app content locally and link webpages to apps.

Apple calls deep links to native apps Universal Links, and they work by specifying the path to sections of an app with a JSON file on a website.

In iOS 9, your app can register to open web links (using https or http) directly, bypassing Safari. This connection between your app and website helps Apple surface your app content in search results.

Universal Links fall under the bigger initiative of Search in iOS 9, which encompasses the web, Siri, local apps, and even apps that aren’t installed on a device.

App Search in iOS 9 gives users great new ways to access information inside of your app, even when it isn’t installed. When you adopt iOS 9 Search, users can access activities and content deep within your app through Handoff, Siri Reminders, and Search results.

As Apple elaborates:

For an example of how this works, imagine that your app helps users handle minor medical conditions, such as a sunburn or a sprained ankle. When you adopt iOS 9 Search, users searching their devices for “sprained ankle” can get results for your app even when they don’t have your app installed. When users tap on a result for your app, they get the opportunity to download your app.

If this sounds similar to what Google announced in April, it’s because the underlying idea is very similar.

Upon skimming through iOS 9’s documentation, my first impression is that Apple wants to further cut out Google from search on iOS not by removing traditional web searches, but by building a superior user experience. In theory, looking for content from an integrated search box and having results seamlessly transition to native apps or prompt to install new apps seems better than asking users to go to google.com. The new back button, Universal Links, and app/web indexing technologies are aimed at finding information quickly, navigating between apps easily, and connecting webpages to apps directly.

It remains to be seen if Apple’s solution will be widely adopted and if it’ll actually be better than Google search. I have many thoughts, but I’ll save them for the future.