Iterations: Google Challenges Apple At The iOS Application Layer
![](data:image/svg+xml;charset=utf-8,<svg height="640" width="360" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
Editor’s Note: Semil Shah is an EIR with Javelin Venture Partners and has been a contributor to TechCrunch since January 2011. You can follow him on Twitter at @semil.
Back in September 2011, a full year before the iPhone 5, I wrote a post here speculating, mostly for fun, how Facebook could approach the iOS platform by using a federated strategy to separate their core offerings into single-use apps across Apple’s App Store. Of course, this didn’t happen, though Facebook has a separate app for private messages (Messenger, through the acquisition of Beluga) and Camera, which was timed curiously around the time the company made one of its most savvy moves: buying Instagram. Since then, Facebook impressively rehauled their entire iOS app away from HTML5 to native and provide a great unified experience in one app, a marvel considering the complexity and scale of their system.
Google, on the other hand, has quietly built and executed on a strong federated suite of mobile and web services that now makes the Mountain View giant a force on Apple’s mobile platform. Alongside this post is a screenshot of all the Google apps for iOS I’ve downloaded to my iPhone (I realize there are even more), and just these almost take up an entire page. And, while Google’s dexterity here is quite impressive as it can provide services for VOIP, chat, local, news, and so much more, Google’s real opportunity relies around the different modes in which people will search for information via their mobile devices, mainly through a mobile browser, for videos, documents, maps, through voice controls.
Right now, Apple has a hammerlock on mobile handset and tablet profit margins, whereas Google has to partner with other OEM to make their offerings a reality. Over time, the margins OEMs can extract from mobile devices will likely face downward pressure. Right now, folks are buying phones almost every year, and the battle to innovate is intense. As competition increases, both for software and hardware components, those device margins will likely go down, and the next frontier for profits in mobile will be in providing robust search interfaces that will generate new revenue or expanding existing revenue streams. The main mobile search interfaces are:
- Native Browser: Apple’s mobile Safari is given special access to UIWebView, so although Google’s Chrome for iOS is extremely well-designed and conceived, its functionality is limited given these controls. Still, Chrome for iOS is nearly a Top 50 “free” app will likely only become more and more popular from hereon out.
- Videos: Until recently, iPhone users could search their preinstalled “YouTube” app controlled by Apple. Of course, Apple stopped that, forcing Google to create YouTube for iOS, which is a smashing success (no surprise here) and is by far the best app to mirror to Apple TV at home. The act of searching for video content directly via YouTube is a huge search and Google owns this.
- Maps: Most people think of mobile apps as core utilities, and they are — but many folks initiate searches directly into mobile maps, transforming maps into another type of search engine. This is one major reason why Apple had to cobble together their own solution so quickly, simply because this search interface will be important to how they monetize mobile in the future. On a roll, Google just released Google Maps for iOS, and of course, it’s now the #1 free app on Apple — and they’ve announced they’ll open their iOS Maps SDK to others to build on top of. [As an aside, the dynamics around search within mobile maps is one big reason why Foursquare is such a valuable property, despite what the naysayers may say.]
- Documents: Apple’s iCloud service smartly syncs files across its entire suite of devices, and finally does so quite well — for a yearly fee, of course, above 5GB. Google Documents, at tremendous scale, are used worldwide and their recent app, Drive for iOS, is quite well-done and serves the need of most users who work out of Google Docs (like me).
- Voice Control: Some people like Siri (works great for me), and others hate it. Whatever. In Google’s own branded iOS app, their voice function is extremely good for crawling the web within that app, but of course, they will never have OS-level access to Apple’s platform, so it’s limited to their own services, which are currently separated across apps. [As an aside, I wonder if Google will unify these in order to expand the reach of their voice control technology.]
What we have there, then, is an extremely powerful and resource-rich technology company with hundreds of millions of users across many web product lines that has somehow begged, borrowed, and stole its way to providing one of the most robust suites of iOS software without the benefits conferred to those who enjoy native iOS access, preinstalls, or default settings. Naturally, Apple knows this and will seek to limit to which of Google’s apps can control the phone or tablet, but over time, as Android is slowly reigned in, Apple will not be able to undertake a similar strategy at the Android application layer. Therefore, Google’s position to (1) lock-in Android users into its integrated services and utilities remains strong and will get stronger and (2) if they can continue to build superior iOS apps, it will bolster their position for services — the next frontier for profits on mobile, after hardware — and all this, on the platform of one of their most formidable rivals.
iPhone Background Credit in Photo: Redlands, Mars by Timothy J. Reynolds (download background here)
Photo Credit: Semil’s iPhone
![](data:image/svg+xml;charset=utf-8,<svg height="125" width="187" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
![](data:image/svg+xml;charset=utf-8,<svg height="105" width="187" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
![](data:image/svg+xml;charset=utf-8,<svg height="133" width="187" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
