A Brief History of App Content Search — And A Glimpse Into the Future

I was talking with a fellow entrepreneur recently about her frustrations building a business in mobile. During our conversation, we came to the topic of growth.

She lamented that search, one of the most important channels for digital business growth, hasn’t evolved to meet the mobile era. More specifically, she noted that Google search largely hasn’t changed in the last 15 years, despite how much change has occurred in how we interact with digital businesses.

In order to benefit from search traffic, she was forced to invest in building a website and traditional SEO strategies that people have been working on pre-mobile despite her effort to build a more modern, app-first company. The problem she was struggling with was, of course, the fact that Google search doesn’t surface app content. It only surfaces websites ranked based on web signals.

Why App Search Is Important

Web search was an incredible innovation for the collective knowledge of mankind, allowing us to retrieve even the most obscure nuggets of information from the dark corners of the web.

Suddenly, the age of encyclopedia sales ended, as people had the entire knowledge base of mankind at their fingertips. Search indexed the gigantic archive of text that existed across billions of websites, solving the research use case better than anything that came before it.

Then, the emergence of the smartphone changed everything yet again. Mobile devices allowed people to access services and information on-the-go, and the search use case evolved to a more valuable niche. Users have a higher intent to accomplish a task, rather than simply retrieve information. In fact, a majority of mobile searches have “local” intent, (older references from Google and Bing) where the user is looking for a specific offering that’s physically close to their location — be it a doctor, a restaurant, or a store.

Another important trend in mobile is the rise of the native app as a core part of the user experience. It’s estimated by eMarketer that more than 90% of time spent on a smartphone is time spent inside of native apps now, which has risen meteorically over the last few years.

The key value of the native app versus web is the fact that the user’s identity is consistent, so repeat sessions are personalized more effectively than when the experience is based on fragmented web cookies. In short, the major value of the app is personalization, and it’s where users express their preferences for the brand, their own experience, and how they prefer to handle tasks.

If installed apps represent a personalizable, consistent experience, then a search engine that returns pages from those apps would deliver results unique to each user dependent on their app preferences. This personalized set of search results would link to the native app where the user identity is saved, making it much faster to resolve the user’s intent. If there is no app, the user can be routed to the web to solve that use case.

The distinct difference between the web and mobile is the unique personalization per user. A mobile search engine is much more geared towards resolving high intent queries, rather than retrieving general knowledge.

The History of the App Search Industry

At Branch, we know we can solve this problem with the vast coverage we have over the app ecosystem, but we’ve seen many, many companies attempt this over the years. I thought it worthwhile to catalog history before we change the future.

Of course, this history includes all of the usual suspects, like Google and Apple. But this story also includes numerous startups with a variety of approaches. As you would guess, there’s an alluring prize for whoever can solve this problem, as it allows that company to own the future of search — and potentially take the search throne as desktop usage continues to wane.

Improved App Store Search Era: 2009–2013

In the beginning of the mobile era (pre-2012), everyone realized that the App Store and Google Play store provided a terrible search interface for discovering relevant apps. While both companies invested substantial resources in the features page, the ability to find specific apps for specific needs was completely broken. Note: This is not related to the actual content inside of apps, but I believe it was the precursor to this industry, and therefore should be named.

While a number of companies built products to attempt to solve app discovery, Chomp was largely considered to be the most successful at this due to the limited amount raised and the high multiple exit. They were founded in late 2009, then sold to Apple in early 2012 to help resolve internal issues with App Store search. Soon after, Apple started rejecting apps that looked like or mimicked the App Store in functionality, which completely killed this industry on iOS.

When Chomp was snapped up by Apple in 2012, and had to forcefully shutter their Android equivalent product, it opened the door for other third-party, Android-focused app stores to rise in popularity. The one that garnered the most attention was Quixey, which was founded in 2009. In 2012, Quixey started to focus on Android search for the Asian markets. The company powered a popular Chinese app store, but ultimately failed to find a defensible position as Google Play app discovery improved, and Chinese app stores were consolidated and owned by native Chinese companies. In addition to focusing on Chinese Android app search, Quixey was developing deep app content search, but they were unable to get much adoption before they ran out of money in 2017, which leads to our next section.

Deep Linking and the Website Mapping Era: 2014–2015

The first introduction to app content search came with the development and focus of deep linking as an industry. The promise of deep linking would, in theory, allow a user to tap on a search result and be immediately teleported into the destination native app to see the content they clicked on. (To read more about the concept of deep linking, see Branch’s overview page here.)

The primary problem when it comes to building a native app search product is getting access to the index of pages inside of apps. The first set of companies to tackle this problem had the great idea to try to use the content on the web and map them to app pages, then create deep links for them.

The most successful in this camp was URX, which introduced app search API in early 2015, after working to index the top few hundred websites and figure out the deep links for each. One of the major challenges in this time was that the concept of deep linking was far too immature. There were many, many changes to the technology over the following years. For example, in late 2015, Apple completely broke all deep linking standards with the introduction of Universal Links.

These shifting standards made it incredibly difficult to offer a quality of service. Links broke without warning. Without a direct relationship with the company, often times the link may start erroring out, and an error that would remain unknown until a user report came in. In 2016, the URX team was successfully acquired by Pinterest to help build out the mobile search experience within their platform.

The App Indexing API Era: 2016–2017

URX and Quixey had one incredible impact on the industry: Raising awareness of the promise of deep linking and native app content search. This really caught the attention of Google and Apple, who began to invest heavily in their own native app search efforts.

Both companies realized that one could not build a true native app search without having all of the native apps contribute two crucial pieces of information:

1. The index of deep links to content
2. The engagement with each deep link to use as a ranking signal (since traditional, graph-based methods don’t work)

Google focused on their App Indexing effort with renewed effort, rebranded under the Firebase brand. With the launch of iOS 9 at the end of 2015, Apple introduced their own Spotlight APIs to allow app developers to actively list content in Spotlight search.

The theme of both of these efforts was clear: Developers need to use custom APIs to index their apps with both platforms in order to make them searchable. This strategy would require quite a bit of custom code to send the data, but in theory, if enough users adopted the APIs, a compelling app search could be built.

By the end of 2016, it became obvious that both companies were losing hope of achieving mass adoption. Google made an announcement that their new enhanced mobile web protocol would rank higher than app-indexed deep links. Even now, at the tailend of 2018, we see fewer than 3% of all apps on the Branch platform using either API.

From my perspective, there was a chicken and egg problem with both of these APIs. Google and Apple couldn’t build a compelling native app search unless people adopted, but there is still no clear benefit on the side of native apps to adopt the APIs until they get compelling traffic as a result. No independent company has time to work on no-value features when their roadmaps are insanely long.

The Android Accessibility API Era: 2017–2018

As time progressed, it became clearer that these platforms would not be able to solve this problem. New startups began looking for ways to crack the barrier of indexing enough deep links to build an app-first search engine.

On the Android platform, there was a brief moment where companies attempted to use the accessibility API as a way to “deep link” into apps.For those that are unfamiliar, the Accessibility API is an Android OS API that allows third-party software to programmatically control the entire Android UI. As a result, third-party software could trigger another app to open, then use the Accessibility API to interact with the UI widgets of that app, potentially navigating to the destination as if it were a user using it.

The largest and most public attempt at doing so was the Samsung Bixby 1.0, released on the S8 and more formally shipped on the S9 device. Bixby wanted to trigger actions in other apps by leveraging this API to trigger UI navigation on behalf of the user. Unfortunately, as many other companies discovered, this method was unreliable. If the native app updated the UI even slightly, it could break the entire flow without warning.

In late 2017, Google made their stance official in late 2017 that any app that attempted to do this would be kicked out of the Play Store.

The Platform Innovation Era: 2018+

And now we arrive at the present day.

In late 2018, it feels like there are very few companies left standing that are completely invested in solving this problem. Everyone is more focused on user experience innovation or alternative platforms.

There’s been dramatic investment in personalized assistants, with Google going so far as to completely outsource tasks like booking appointments on your behalf, or Alexa trying to make every single device in the home “smart.” Apple, too, is trying to solve the problem, but solely by recommending specific, heavily-used personalized “shortcuts” to apps on the new iOS 12.

These new interfaces are still nascent, and it will require a killer use case or two to drive consumer adoption at scale.

In the meantime, at Branch, we still believe there is a traditional search problem to be solved in mobile. In order to do it, the top priority is to solve the egg problem: Getting the deep link data to build truly mobile-optimized search.

Once the egg has been solved, distribution should be easy. Then the focus shifts to training users on how to use the incredibly improved experience that app search could offer.

Much more to come from us in this space. We’re excited for what the future has in store.