October 27th, 2015
Core Spotlight Framework was released in early September 2015 to much excitement. It was the first time in history that developers would be able to list pure app content in search. The possibilities seem endless!
Fast forward to today and we don’t see anyone using it. We keep hoping that developers will adopt the functionality because of the many neat things that can be done. This blog post is meant to provide inspiration for the types of features that could be created with Spotlight Search.
Let’s get those creative juices flowing.
First off, let me take a minute to describe how Spotlight Search works. The process of listing something new in Spotlight is simple. You specify a set of properties on a CSSearchableItem, then tell Core Spotlight to list the content.
Some of the key attributes of content:
The identifier is an important parameter since it indicates to the operating system whether the content conflicts with a pre-existing one. If you don’t want to worry about tracking whether the content has already been created from within your app, be diligent about maintaining unique identifiers. That way, you can just keep listing without concern of duplication.
Title, description, and image represent the visual appearance of the content when the user sees it in Spotlight. It’s easy to see which corresponds to which. Note that description will be cut off if it is longer than two rows.
Search works very, very simply in this tool. It’s basically just a text match of the query string to the words within the title or description. From testing, it appears that relevancy is determined by recency, so the most recently listed content will appear first. It’s possible that there are more mechanisms at work, but we have yet to find a single app that actually leverages Spotlight, so the only results across all our phones were our test listings. Maybe in the future, this will be more popular.
Another important note is that these Searchable Items will only appear if the app is currently installed on the phone. When the user uninstalls your app, all of this content is cleared from the local search index. Also, users who have never installed your app will not be able to find your listings. This means that the only functional use case is for users to re-engage with your app after they have it installed.
In the implementation of this feature, Apple gives you the complete freedom to manipulate Spotlight rankings. In the FAQ, they describe that they’ll never do anything to manipulate or monitor the local Spotlight index since they believe it to be a violation of user privacy. It’s a green field for you as the developer.
It could be tempting to just flood the local Spotlight search index with every piece of content in your app the minute it’s installed. For an extreme example, it’s perfectly acceptable to just write a for loop that lists a piece of content for every combination of every letter in local Spotlight to ensure that you always appear at the top of the search results no matter the query.
Please don’t do this. Think of Spotlight as an opportunity to help foster the relationship with your user. Spamming their results with garbage will most certainly earn you a delete and a poor review.
In this post, we’ll avoid going into the details of implementation, and instead focus on some high-level suggestions for use. As discussed above, Spotlight can only be used for re-engagement and we don’t want to surprise or spam the user with too much content. Here are a couple of gentle upsells that we would recommend implementing depending on your use case.
If a user interacts with content in your app as part of the use case, you could imagine that they might want to go back and find the things that they had previously viewed.
As an example, let’s say you’re a Yelp-style restaurant listing. If a user has viewed a few restaurants, you could set up a policy where you list the restaurants in Spotlight as they are viewed. This way, when the user encounters them in their search results for a given query, they are already familiar with the content. This would be a gentle way to re-engage.
There is a great opportunity to allow the user to discover various aspects of your service through Spotlight. If you’re not going to list the entire content database there, you can filter down possible listings by leveraging information that you know about the user.
For example, you might use location if your content has a location component. For a Yelp-style app, you could read the location of the user with GPS or an IP to Geo lookup, then only list the restaurants within a 25-mile radius of the user’s location. In this case, you might want to occasionally monitor if the user has moved to update the list of indexed content. Core Spotlight allows you to delete previously listed content that you determine is no longer relevant.
Another example might be to leverage social information. Once you know more about the network of a given user, you can use that to help filter the listable content. Perhaps you only list content that was generated by the set of users who are listed as friends or who the user is following. This way, Spotlight only reveals a highly targeted subset of your overall database.
In some cases, the user is creating or editing content within the app. It would be completely reasonable and desirable for the user to discover this content while looking through Spotlight.
An example would be a run-tracking app, where the user has tracked themselves on multiple runs since downloading. The records for these runs should be discoverable by the user while looking through their phone.
See our Best Practices for Spotlight for more suggestion on setting up Spotlight.
Since users can’t search for your indexed content without the app installed, users without the app are not able to find your app based on the content that resides inside. However, Apple has hinted that in the future this index won’t be restricted to a single phone. Apple appears to be working on a cloud search mechanism that will allow users to find this content even when the app is not installed. It will be interesting to see how they provide relevancy on top of this content, as it will be challenging for them to know if one piece of content is more popular than another.
For now, we’d recommend holding off on trying to list your content publicly. It’s a very different use case than the local Spotlight search, and you don’t want to risk annoying your users by polluting their phone. In the future, the publicly indexable methods will likely change substantially to keep the use cases separate.
We recommend that you use Branch to list your content in Spotlight, as it offers a bunch of great features layered on top of the search mechanism. For example, if you configure your deep link routing with Branch for all other channels, when a user clicks your Spotlight result, they’ll automatically be deep linked to the correct page in your app. Secondly, Branch will report all of the clicks/re-opens that occur through the Spotlight channel specifically. We’ll even report which content is driving the most re-engagement with your app.