Want to master the CMO role? Join us for GrowthBeat Summit on June 1-2 in Boston
, where we'll discuss how to merge creativity with technology to drive growth. Space is limited and we're limiting attendance to CMOs and top marketing execs. Request your personal invitation here
Now that mobile deep linking — the process of linking into specific sections of apps — has started to become widespread, it’s increasingly clear that apps should never have been isolated from one another in the first place.
We can now see that, just like HTML sites have always been richly interconnected (that’s where the web gets its name, after all), mobile apps should have been richly interconnected too.
But why did it take so long for this to happen, and who’s to blame?
There from the start
The current era of mobile apps began six years ago on July 10, 2008, when Apple launched the App Store. At the time, mobile deep linking was a completely foreign concept, and we were all too distracted by the advent of truly “smart” smartphones to start thinking about it. But even though the fact attracts little attention, the iOS platform supported deep linking into apps since day one with its “Custom URL Schemes.”
We’ll be discussing how deep linking can grow your mobile business at MobileBeat in San Francisco on July 8-9.
Grab your tickets now!
Apps have always had the ability to act like a web, ever since they could even act like apps. So why is Deep Linking only catching on now? It may all be Apple’s fault. The way the company implemented deep linking in iOS was a bad design choice that delayed the advent of useful mobile links for six years. That’s how long we had to wait for a series of prominent industry players to converge on a workaround for the deep-linking limitations of iOS.
Apple created a separate web
The problem with Apple’s design for Custom URL Schemes is that, while it lets a set of installed apps act like a web and interact with one another, it doesn’t encourage them to be part of the web and interact with everything else. That makes it too hard for apps to actually link to one another in a way that makes sense to users, provide access to the right functionality, and remain open to apps or content outside a certain ecosystem.
To see what I mean, just open your mobile browser and visit yahoo.com. You’re not browsing the same Yahoo! website as the one on your laptop; you’re browsing Yahoo’s mobile website. But it’s obvious that you’re still browsing the same web — the same ecosystem of connected information. The one that nobody owns and everybody’s part of.
No one thinks that mobile websites form their own web, separate from the web of desktop websites. Did you notice that we never needed “deep linking standards” for mobile sites? Deep links on mobile sites worked perfectly from day one, precisely because mobile websites were always designed to be part of the web, rather than a separate web. They didn’t follow their own rules, they followed web development standards.
When Apple released its App Store, the company also created a necessary technological separation between websites and apps: websites run HTML code; apps run native code. The problem is that Apple created an unnecessary separation of URL schemes at the same time, choosing URLs beginning with the standard http:// for websites, and assigning Custom Scheme URLs with custom names like yahoo:// for apps. This design choice sealed apps’ fate, allowing them to form a separate web among themselves but excluding them from the larger web (and therefore greater utility for everyone) at the same time.
Strangely, in the first few years of mobile apps, we saw almost zero deep linking into this separate web. You’d never receive a text message from a friend saying “Check out this cool news article I’m reading in the Yahoo app,” followed by a link that starts with “yahoo://.” Any issues with the quality of Yahoo news articles aside, the reason for the lack of linking is that Custom Scheme URLs have a number of design problems that make them impractical to use for deep linking, such as lacking a unique allocation mechanism and showing an ugly browser error if you open them before installing the corresponding app.
Apps are the web
Here’s what Apple didn’t realize when it was designing the iOS platform. Just like the web was never supposed to be limited to your desktop, it was also never supposed to be limited to running HTML code. Browsing to yahoo.com should just mean getting the best Yahoo experience, whether it’s through Yahoo’s mobile website or Yahoo’s mobile app.
The web is the phenomenon of physical hyperconnectivity that defines our modern era and annihilates time and space. The web was never supposed to be about a choice of programming language. Associating it only with HTML is comically myopic and limiting in terms of what we can do, as has become clear as more powerful web development tools become available.
If two people halfway around the world can have a face-to-face chat over the web, and 3D printers can teleport objects over the web, then it doesn’t take a huge stretch of imagination to see that web pages and apps should be able to link to one another over the web as well.
So mobile deep linking is six years late and it’s all — or at least largely — Apple’s fault.
To be fair, Android and Windows Phone didn’t help the situation. All three mobile operating systems, thanks in part to Apple’s lead, use versions of Custom URL Schemes for deep linking to apps (although Android’s deep linking support is a cut above the others). But Apple set the stage for an approach we didn’t need to take – one that cut off apps from the rest of the web.
Fortunately, new deep linking standards like App Links, App Indexing, App Cards and AppURL are helping the industry reach a unified consensus to backtrack on Apple’s original design decision with Custom Scheme URLs and making apps part of the web instead of their own separate, dysfunctional web. The recent progress with mobile deep linking isn’t just a victory for the app ecosystem, it’s a victory for the whole software ecosystem.
It means the web itself is back on track to put users, not URL schemes, first. And that’s good news for everyone.
Liron Shapira is the co-founder and Chief Science Officer of Quixey, the search engine for apps. Liron created Quixey’s all-platform natural language app search technology (Functional Search). He is an advisor to the Machine Intelligence Research Institute (MIRI). Liron co-founded Quixey after working at Slide, where he was the second developer on the successful SuperPoke Pets product. Reach him @Liron.
Apple designs and markets consumer electronics, computer software, and personal computers. The company's best-known hardware products include the Macintosh line of computers, the iPod, the iPhone and the iPad. Apple software includes t... read more »
Quixey was founded in 2009 to solve a problem - millions of apps were being created, but there was no simple way to find them. App discovery was limited to categories, top ten lists, directories and basic keyword search. Quixey was cre... read more »
Powered by VBProfiles
VentureBeat’s VB Insight team is studying email marketing tools.
Chime in here, and we’ll share the results