iOS 9 – New Opportunities with Search and Universal Links
Already within one week of launch, iOS 9 adoption has skyrocketed to 50% of active devices.
Two of the most significant developer features enabled for iOS 9 is the introduction of searchable app content and Universal Links. The new search capabilities introduced by Apple effectively turn Spotlight search, Safari search, and Siri suggestions into a Google-like search engine that can index app content from the millions of apps in the app store. Secondly, Universal Links make it possible to automatically intercept and redirect your web traffic on iOS devices to your mobile app (if installed).
Below we’ll take a high level look at these two new features.
To understand how Apple has enabled search, a good first step would be to largely abandon any understanding of how traditional web search operates.
The biggest reason for this difference is that in apps, content isn’t crawled or automatically indexed by a search store (with one exception), rather, developers must manually and pro-actively attempt to add and remove content from a search index.
For added complexity, Apple effectively provides two indexes that a developer can add content to. A private on-device index unique to each user / device and a server side index, similar in spirt to a major search index like Google.
- A private on-device index. Each device contains a private index whose information is never shared with Apple or synced between devices. When you [the developer] make an item available in a user’s on-device index, only that user can view the item in search results.
- Apple’s server-side index. The server-side index stores only publicly available data that you’ve marked appropriately on your website. * Taken from Apple docs.
To clarify, the private index is unique to each / device user. An example of a private search result that could show up in Spotlight is a specific travel itinerary for an upcoming trip booked through a travel app. This is private data unique to each users behaviour and previous interaction with an application.
The public index is non-unique to each device.
To participate in the above search indexes, Apple has provided developers with three technologies for implementing search:
- Core Spotlight Framework – Indexes any app content (private index)
- NSUserActivity – Indexes previously viewed app content (eligible for private and public indexes)
- Web Markup – Indexes app content on the web (public index)
Each of the above Apple technologies have similar and overlapping uses cases with slight differences.
1) Core Spotlight Framework – This iOS framework provides a way for content heavy apps to comprehensively index content. An appropriate example here is a recipe app with millions of recipes indexing each individual recipe so that they may be served as search results to users who have the app installed.
Think of this framework as similar to regular web search.
2) NSUserActivity – Based on Apple’s research, users tend to search for content they have already engaged with. Think of a user searching for the article they once read, the amazing recipe they once tried, etc. This Apple technology makes it possible to serve content in search that a user has already engaged with at some point inside the app. This could be public content (a previously viewed recipe) or private content (the booked travel itinerary).
Think of this as similar to your search history appearing while typing in Google search on desktop.
The power of NSUserActivity is allowing the developer to designate content as public (eligibleForPublicIndexing). If the content marked public is first privately searched for and engaged with enough times,** it will eventually begin to appear in search results publicly for all users with the app installed. This can have dramatic implications for content discoverability on iOS.
**Apple is intentionally vague about what it takes for a private result to begin showing in public search. Below are three factors Apple states will impact your search ranking:
- The frequency with which users view your content (which is captured when you use NSUserActivity)
- The amount of engagement users have with your content (determined by the engagement ratio, which is based on the number of times users tap an item related to your app and the number of app-related items that are displayed in search results)
- The popularity of a URL in your website and the amount of structured data available (To learn more about structured data, read the ‘Enriching Search Results’ section of the Markup Web Content docs)
3) Web Markup – If some or all of an app’s content is also available on an associated website, web markup can be used to give users access to content in search results. Using web markup lets the Applebot web crawler index web content in Apple’s server-side index, which makes it available to all iOS users in Spotlight and Safari search results. * Taken from Apple docs
There are a few pre-requisites for implementing web markup:
- Website must be discoverable by Applebot
- Website must contain markup for mobile deep links (smart app banners, universal links, app links)
- App must be able to open deep links or Universal Links
The main benefit of implementing Web Markup is that it enables your app content to appear in search results even if the user doesn’t have your app installed. Technically, it’s web content populating the search result but because there is an associated deep link (and / or you have Universal Links setup) Apple can know the content also lives inside the app.
Apple’s new search technologies are brand new and still relatively poorly understood outside a small group of developers. For a large number of brands and organizations, search represents a powerful new way to improve app content discoverability. This is especially true for apps that have web content which both mirror each other.
One limitation of search is that it’s still not possible to have app exclusive content appear in a search result for users who don’t already have the requisite app installed. Perhaps this will be addressed in future iOS releases.
Apple’s new search capabilities serve to dramatically improve the user experience on iOS; however, there is complexity implementing these Apple technologies. In the majority of cases, implementing search on iOS will not be choosing one of the above technologies, rather it will be implementing all three to work seamlessly together.
To understand Universal Links, it’s important to first understand deep links.
Deep links are nothing more than the ability to open up an application to a specific piece of app content. It’s akin to linking to a page other than a homepage on a website.
In order to deep link into an app, traditionally a developer had to register a protocol (i.e. instagram:// , twitter:// , facebook:// ) with the operating system when an app is installed. Subsequently, when an incoming request is received on the device to a registered protocol, the operating system launches the associated application, letting it handle the request (link).
This works well enough; however, if a developer has a website mirroring its app content it results in having to effectively manage, maintain, and synchronize two sets of URL schemes, one for the web and one for the app.
Universal Links try to solve this problem by enabling an app to handle incoming https:// requests (regular web requests).
On iOS 9, a user may navigate or click a link to a webpage and if that website is setup to handle Universal Links (and the app is installed on the device), the operating system will intercept the request (without opening Safari if not already open) and pass the request to the associated application.
Universal Links are an easy way to intelligently route web traffic to an application if available. It enables developers to make the app the default place to send web traffic on iOS, using the web as the backup destination if the app isn’t installed.
Universal Links may, in some cases, obviate the need for custom URL schemes.
Apple notes that supporting Universal Links is a three step process:
- Create an apple-app-site-association file that contains JSON data about the URLs that your app can handle.
- Upload the apple-app-site-association file to your HTTPS web server.
- Prepare your app to handle universal links
-Taken from Apple docs
In practice, setting up and serving the apple-app-site-association is a headache.
This is because the file must meet the following requirements:
- The file must be hosted on an https:// site with a valid certificate (for example, Safari must not issue a certificate warning when viewing the site).
- The file must not use any redirects.
- The file must have the MIME type application/pkcs7-mime.
- The file must be CMS signed by a valid TLS certificate.
Taken from Apple docs
Tapstream supports Universal Links by offering to host the apple-app-site-association file allowing Tapstream’s links will work seamlessly with Universal Links. If you’d like us to host your site association file, please email firstname.lastname@example.org.
Universal Links work hand-in-hand with app search and together can dramatically alter how customer experiences are delivered on iOS devices. Together these topics are vast, require not only initial implementation, but also ongoing management.
We hope this will serve as a launch point to further research to determine if and when you want to take advantage of these new advanced technologies on iOS.