虽然Google的产品线繁杂，但其在移动端基本上是用Chrome和Google Play Store这两个平台搭载Google的产品向外延伸。Chrome跨越操作系统兼顾iOS和Android，Google也开始基于此平台构建应用；Google Play Store则在Android诞生之初就守住了Android的应用分发渠道。
但众所周知，无论是iOS、Android或是Windows Phone，移动应用内的信息都如孤岛一般存在，作为一家开发了Android的搜索公司，对Google来说，着手打破应用间的信息围墙是一件合情合理的事。
不久前，Google在2013年12月初宣布包括IMDB、维基百科在内的13款Android应用正式支持应用内的内容索引，这就意味着Google的应用内搜索正式到达了本地用户端。目前的应用内搜索功能仅在google.com下有效，而且必须用户登录Google的帐号。这也就意味着Google是基于自己的帐号系统来决定是否为用户呈现相关的内容索引。
按照Google的说法，用户在安装这13款支持应用内内容索引的Android应用后的1~2天，“Open in App”按钮才可能出现在相关的搜索结果中。为了做到精确索引，应用程序开发者需要分别在应用端和网页端为相关的页面做匹配，接着Google的网络爬虫抓取页面后才能让用户后通过“Open in App”打开与之相关的页面。比 如，当我搜索《One Day》时，既可以通过IMDB打开对应的电影介绍页面，又可以通过维基百科打开对应的词条。此外，Google并没有限制仅在Google Search应用或者Chrome浏览器中才可以使用应用内搜索功能，我通过Opera登录Google帐号后一样可以实现同样的效果。
总结来说，Google的应用内搜索并不是一个简单的跳转或本地程序调用，Google严重地依赖了自己打通的帐号体系和开发者的配合才得以为用户呈现这个功能。
虽然目前Google的应用内搜索功能仅支持13款应用，但也基本涵盖了美食、健康、百科、娱乐、旅行等多个方面，Google在产品发布之初也承诺未来几个月将会让更多应用支持该特性。不过，即使在Google的带领下，应用内搜索在未来的发展一样面临诸多困境：
首先，说服诸多开发者为他们的应用增加索引特性是个庞大的工程。这要比说服他们为Android平台开发应用困 难多了，毕竟虽然几乎每个人都需要一个移动端应用，但并不是所有的开发者都认为自己有必要花费力气匹配页面去支持应用内内容索引，或是愿意将数据开放给 Google。尤其是雅虎Apps、Facebook、Twitter这类产品，要么更希望用户在自己的站内完成搜索，要么正在与Google的竞争对手 合作。
其次，应用内索引仅对那些可以规则呈现内容的应用有效。如前文所说，应用内内容搜索要求应用开发者分别在应用端 和网页端为相关的页面做匹配，但对于一些工具类或是个性化信息类产品，这显然是难以实现的。比如，如果Google无法为Dropbox、 Evernote内用户生产的各种内容提供一个智能匹配的技术，那么Dropbox、Evernote也就不能支持应用内搜索。如此一来，这些应用中的内 容就只能还是孤岛一般的存在，可实际上，他们往往包含着巨大的有价值的数据和信息。
再次，在平台层面上，应用内搜索的可扩展性难比Google Web Search。虽然我们可以在iOS和 Windows Phone上使用Google搜索，但除了Android外，Google既没有对这两家死敌平台的应用控制权，也没有贯穿整个系统的账户体系。所以即便 iOS开发者和Windows Phone开发者希望用户能够通过Google搜索并使用到他们的应用，可微软和苹果未必会为Google的愿景买单。
当然，虽然有这么多困境，但并不意味着应用内搜索对Google是缺乏价值的。通过索引应用内内容，让那些优质的信息、数据和应用更便于分享和传 播，使得Google在移动端有机会延续在传统互联网上信息聚集者的优势。Google可以继续依靠索引这些内容来分发流量和应用，保持着自己作为网络入 口的地位。由于Android已占据了较大的市场份额并在持续增长，所以即使在其他平台遭遇竞争对手的阻难，应用内搜索也能帮助Google Search快速填补大面积的空白。而如果一个搜索引擎无法获取应用内的数据对其进行索引，那么这个搜索引擎的边界将会被大幅收窄。
Google迈出的第一步，是关系到整个“搜索”模式在未来形态和地位的尝试。
