At its f8 developer conference earlier this week, Facebook announced App Links, a new open source protocol to allow developers to deep-link to mobile apps from web browser environments. From the App Links website:

Right now, linking on mobile is a lot more frustrating and complicated than it is on the web. There isn’t an easy, consistent way to control what happens when someone clicks on your content in mobile, which makes it difficult to provide the best experience for your users. It’s also hard to find out when—and how—to send people out of your app and directly into another.

We built App Links to help with that. It’s an open, cross-platform solution for app-to-app linking that gives you the tools you need to expose deep links in your app or to link out to others.

The idea of deep-linking to apps arises from the fact that many native apps have significantly better experiences than their web versions when being viewed on the smaller screens of mobile devices. Take Dropbox for instance. The Dropbox mobile app provides an excellent experience for viewing Dropbox content on iPhones or iPads. Accessing your Dropbox files on the web through Safari or another web browser is possible, but it is nowhere near as polished of an experience. The issue here is that anytime you tap a Dropbox link on your device, it is not smart enough to do anything except launch the Dropbox website in the nearest web browser. Even though you have a perfectly good Dropbox mobile app ready to give you exactly what you want in an environment built for your specific device, you're forced to use the lesser experience of the web view.

App Links is an attempt to fix this problem. If you tap a Dropbox link in an app that supports App Links, it will figure out that you have the Dropbox app installed on your device and redesign the link as a Dropbox.app link instead of a Dropbox.com link. Then when it opens the link you will launch into the Dropbox app to view the content in question instead of seeing it in a web browser. This is known as "deep linking" because that content is "deep" inside of the Dropbox app. (Really it's all on the web, because that's where the Dropbox app gets its data, but the point is that this content is not accessible through the top level hierarchy of the Dropbox app. It's not easily found unless you search "deep" inside of the app, so linking to that content is "deep linking".)

This idea may seem foreign, but we actually deal with it every day on the web. Basically every URL is a "deep link" to some sort of content on the web. Every article that you follow a URL to get to was buried somewhere deep in that website's hierarchy, but that URL was able to link you directly to it. This is an extremely powerful concept which has been so mastered on the open web that we don't even refer to it as deep linking there, it's just linking. In the mobile app ecosystem, however, deep links are still struggling to find mainstream support from developers. We take it completely for granted that every single piece of content on the web is accessible from a link, but in most mobile apps, content is only accessible by navigating your way through the app's hierarchy until you get to the location of the content you're searching for. Imagine if every time you wanted to go to an article on a webpage you had to go to the website's home page, navigate to the section the article is in, then scroll through other articles until you found it. The notion of navigating websites in that manner, without direct, deep-link URLs, is ridiculous.

The problem with native apps, the main reason why deep links did not become as ubiquitous as they are on the web, is that unlike websites, apps are not always accessible. A native app link can only work if the app it corresponds to is installed on the device, and most developers cannot be very certain that their app will be installed on any given device. (▼)(▲)A notable exception to this rule is Facebook. If you take any given iOS device, the likelihood that the Facebook app is installed on it is probably higher than almost any other app besides Apple's own. App Links seeks to solve this by creating an open source protocol which developers can implement to identify whether an app is installed, then change web links so that they will launch into the corresponding apps instead of the standard web views. These won't just be basic app launching URLs, but true deep links to send you to the exact content you want to see, just in an app instead of a web view. Tap a Facebook link and see the result in the Facebook app. Tap a Spotify link and start listening to the song in the Spotify app. Facebook has launched app links with quite a few big name supporters already, including the aforementioned Dropbox and Spotify as well as Hulu, Pinterest, GoodReads, Redfin, and several others. Of these, however, the only ones which will actually be implementing App Links at this time are Facebook, Mailbox (which is owned by Dropbox), Quip, and Spotify. The rest will simply be publishing App Link metadata (More on what that means later). In other words, while links in the apps from the full list of supporters will have the capability of being changed from web links to app links, only when you click those links from one of the four apps that have implemented App Links will they actually send you to the app instead of the web.

App Links are a great idea, inspired by real problems with iOS (▼)(▲)App Links support other major platforms too, but I'm focusing on the App Links implementation in iOS for this article., but there are a lot of concerns with this type of protocol as well. In this article I'll try to explain some of the problems, as well as the advantages, that may soon be associated with App Links. First though, you need to understand exactly how App Links work, and the difference between publishing App Link metadata and actually implementing the protocol.

How App Links Work

As I've written about before, basically the only way for apps to communicate on iOS is through URL schemes. (▼)(▲)There is also the "Open in..." menu, but that's mainly just for transferring documents between apps. These work just like website URLs do, providing a simple "domain name" which, when called, will launch you out of your current app and into the app associated with that name. These URLs follow the basic syntax of yourapp://, where "yourapp" is whatever title a developer has registered his or her app to. Developers have the option to register their apps to a URL scheme, but unlike with website domain names, they don't have to. Similar to website URLs though, developers can build their schemes deeper so that adding more data after the :// can direct users to places further within the app, or even launch actions inside of it. These schemes are the foundation on which App Links are built. Apps which support App Links will likely have complex URL schemes to allow "deep linking", creating specific links for every piece of content accessible through the app so that a particular URL action can launch users directly to a specific item of content "deep" within the app.

Two things have to be true for you to click a link and have it open in an app instead of a web view. First, the app you are clicking the link from has to have built in support for App Links, and second, the publisher of the link you are clicking has to have included App Link specific metadata in the HTML of that link's webpage. This is the distinction between being an App Link "publisher" and having actually implemented the App Links navigation protocol. This is also the biggest disadvantage App Links is going to face in gaining any traction. App Links can only work if you are clicking on a link which has App Link metadata and the app in which you are clicking said link has implemented the App Link navigation protocol.

So how exactly do publishers include App Link metadata? That part is extremely simple. Within the HTML <head> tags of each webpage, publishers must simply include a few extra lines of code which hold the data App Links needs to function. Each line of code will look something like this:

<meta property="al:DEVICE-TYPE:PROPERTY-TYPE" content="DATA" />

For each item, "DEVICE-TYPE" will either be ios, iphone, or ipad. "PROPERTY-TYPE" will then either be url, app_store_id, or app_name. Finally, "DATA" will be the piece of data associated with the property type. Within each line of metadata, publishers can choose to add code for any or all device types, depending on how many manifestations of their app there are. If the app is universal, they only need to provide metadata for the device type ios. If their app is iPhone or iPad only, they can choose for themselves whether they want to use ios anyway, or use iphone or ipad depending on which platform their app is on. If there are separate versions of their app for iPad and for iPhone, then they can include metadata for both the iphone and the ipad device types. As for properties, the url property will include the URL action to launch to the specific piece of content within the corresponding app. The url property is also the only required property, everything else is optional. Next, the app_store_id property will include, not surprisingly, the app's specific App Store identification number. Finally, the app_name property will include the name of the app. The last property that most content publishers will want to include is the al:web:url property. This is that actual web URL for the page, and in fact probably the same URL as the one the user clicked to get to the App Link metadata. There is also the option to include an al:web:should_fallback metadata line which can be set to false if there is no web version of your content, or in other words if you have only an app but not a website. This is possible because Facebook itself, as well as a company known as Parse, are providing services to publish App Link metadata without actually having any web content. In that case, a publisher could post a link which directs to a Facebook or Parse webpage which simply holds the metadata and nothing else. To the user, they would tap the link and open straight to the app without ever seeing that there was no web version.

So that's how publishers can start adding App Link metadata to their webpages. If the explanation may have seemed complicated, the actual implementation is really just a few lines of simple and repetitive code, which to anyone who knows how to write HTML will be extremely easy.

Simply having publishers include App Link metadata in their webpages isn't all that App Links requires. It also necessitates that the app in which an App Link is being clicked haas implemented the App Links navigation protocol. This protocol describes a few extra steps between a user tapping a URL and that URL being opened. First, a request for any metadata beginning with al wil be sent to the target URL. If any metadata is retrieved, meaning that webpage has published data for App Links, then the navigating app will next search through the returned metadata looking for device types of the same type that the current device is (i.e., if you're tapping a link on an iPhone it will search for any metadata beginning with al:iphone, but if you're tapping on an iPad it will search for al:ipad). If it doesn't find metadata for the device, it will search again for metadata containing al:ios. If that's not found either, it will check whether al:web:should_fallback has been set to false. If it has been, the navigation will fail and nothing will happen. If al:web:should_fallback has not been set to false, the URL will be opened regularly in a web view. However, if it does find any metadata either associated with the proper device type or containing al:ios, it will proceed to construct a new URL to launch instead of the one being tapped. This is a process as well. First, the navigating app will check whether the URL defined by the url property of the App Link metadata can be opened on iOS. Assuming the publisher did not have a typo in their URL action, the only reason this would fail is if the app is not installed on the device. If the URL does not fail, meaning the app is installed, it will launch the URL and send the user into the native iOS app corresponding to the link, and to the proper place within the app. However, if the URL does fail, hopefully meaning the app is just not installed, not that the published URL has an error, then the app_store_id property can be used to open the iOS App Store to the page for the uninstalled app in question.

Since all of this goes on in the background, to the user there are only a few possible outcomes if they tap a link which has some sort of App Link metadata in its markup:

• If the app is installed on the user's device, open the content from the link inside of the app.

• If the app is not installed on the user's device, open the App Store to the app's download page.

• If there is no App Link metadata associated with the user's platform (e.g., the publisher included App Link metadata for only the Android operating system but not iOS), open the URL regularly.

• If there is no App Link metadata associated with the user's platform and there is no web version of the content (e.g., the App Link is for an Android only app which does not have an accompanying web component), do nothing.

There are two other properties defined in the App Links navigation protocol, but rather than metadata properties defined in the link that is being navigated to, these properties are defined by the app doing the actual navigating. That is, the app from which a user is opening an App Link. The first of these properties is the al_applink_data property. This is a property which is sent as part of the URL action to the app being launched by an App Link, and it simply contains context for the navigation. That is, this property contains the target URL that was initially being navigated to before the App Link took over, the app token of the navigating app, the version number of the App Link protocol being used, and the identifying string for the library that the navigating code is using to navigate. Presumably, an app being launched by an App Link can choose to make use of this contextual information or just ignore it. In the future it will become significantly more useful when more version of the App Links navigation protocol exist. In that case, if an older app which has not been updated is the sender of the App Link, the receiver app can identify the fact that the sender is using an old version of the protocol and adjust accordingly.

The second property which the navigating app can send in the URL action is called referer_app_link, and this one is much more interesting than al_applink_data. referer_app_link provides a URL to return to the navigator app after the user is finished with the content they navigated to in the reciever app. The developer of the reciever app can choose to look out for the referer_app_link property and then implement a back button into their interface. That way when the user wants to return to the app from which they tapped the App Link, they can just tap the back button to automatically jump back to the app they had navigated from.

Advantages of App Links

With App Links, Facebook imagines, and is hoping to begin to create, a world in which low quality web versions of apps no longer need to be dealt with. Imagine if every time you tapped on a link to a tweet (even outside of Twitter apps) your device could open that tweet in the official Twitter app instead of the terrible Twitter web app. Not only would you be viewing the tweet in a better environment, but you would already be logged in and free to reply, retweet, favorite or any other action, which is often a huge pain to try to do in Twitter for the web on an iOS device. Not only that, but when you finish with the tweet, a button will be waiting for you to tap to go straight back to whatever app you had been in before. This would work the same way with any app, saving you time and annoyance by never again forcing you to use the web version of Dropbox, Spotify, Facebook itself and more.

This could be the first step to the inter-app communication that many of us nerds have been dreaming of since we saw the capabilities of x-callback-url. Best of all, average users, those who have little knowledge or interest in what's happening under the hood of their devices, could make use of these new capabilities without ever needing to "install an action" or change their habits in any way. They would simply get a better overall experience on their devices.

Difficulty Getting Adoption

By far the biggest hurdle that App Links will face is getting wide adoption. Unfortunately, the likelihood of App Links ever becoming a complete standard is fairly low, because it's highly doubtful that Apple would ever implement App Links, a third party protocol, into Mobile Safari. In other words, App Links will very likely never work in the most popular web browser available on iOS. This leaves it to try to scrape up the leftovers: web browsers built into third party apps such as Twitter or email clients (Mailbox has already committed to supporting App Links), as well as full-on third party web browsers like Chrome or iCab Mobile.

Without finding its way into Mobile Safari, App Links has a steep uphill path to reaching mainstream support. The only way I could see Apple ever implementing the protocol is if it manages to become a true standard among third party web browsing experiences and Mobile Safari is falling behind without it. Yet still, it seems more Apple-like to just build their own protocol into iOS than to implement one built by Facebook, particularly when you think about some of the possible issues that could arise from people abusing the App Links protocol.

Concerns With App Links

The reason Apple has not implemented powerful inter-app communication up until now is because it is a danger to security. By keeping every app in its own sandboxed environment, it's very difficult for apps to do something in the background without the user's knowledge. URL schemes are the only method of inter-app communication that is not fully controlled by Apple. That lack of control does mean that running URL actions is a security risk. Once you launch an action, it's likely impossible to stop it from fulfilling its function unless it is a long chain that bounces between different apps. With the current state of iOS automation, this has provided very little danger because the users are completely in charge of which action they install and run. Furthermore, it's a field predominantly populated by people who are more advanced users of iOS, and likely to realize if an action they've installed has done something other than what its description had said it would do.

Security issues related to URL schemes are in no way going to be some sort of malware. iOS is still sandboxed, and running a URL action can't install any malicious apps from outside the App Store or anything like that. URL actions can become dangerous, however, when they send you somewhere unexpected. As far as I can see from the information on the App Links protocol that Facebook has published, the protocol does not include any sort of check to make sure the App Link it is navigating to is actually going to the content it should be. Of course, there's really no way for the protocol to do something like this because it can't read the content it sends the user to, it can only launch the action defined in the metadata of the webpage it scrapes. Without a system of checks, I can think of a few different, and all seemingly easy ways in which the system could be abused to take advantage of unsuspecting users. (▼)(▲)I only know as much as what was written in the documentation, so it's possible that App Links does have some sort of built in features under the hood which would try to prevent the following situations. If you're aware of something like that, please contact me about it so I can update this post.

First, App Links could provide a way for advertisers to get more users to download their apps by paying websites to use app_store_id properties for the advertiser's app instead of their own. This way, if the URL provided by the App Link failed to launch, meaning the user did not have the app of the link's publisher installed, the fallback could send the user to the App Store to download an app which is not the app associated with the link, but rather some random game or another app which an advertiser has paid the App Link publisher to link to. Sure, the publisher might get less downloads of their app, but I can't imagine that advertisers won't be able to find a price that will convince some publishers to forsake a few downloads of their apps. Particularly when you recall that Mobile Safari will not work with the link, so the majority of users navigating to it will not be sent to the wrong place.

Next, just as the app_store_id property is not, nor likely could be checked by the App Link protocol, neither is the url property, nor the web:url property. Either of these could be tweaked to send the user to a different website than the link they actually tapped would have taken them to. Users could tap a link and unsuspectingly be redirected to porn or other explicit material on the web. They could even be directed to phishing websites. It's all the same problems that everyone who uses the web constantly faces, but now the links can be hidden another layer down and you may never actually tap the link you end up being directed to. Just like with the App Store links, all of this nefarious redirecting will cause the actual website of the link to lose hits because the user never reaches it, but advertisers or other organizations would surely pay them for their troubles.

The final concern I have with App Links is less tied to malicious uses of the protocol. Rather, it's simply the annoyance that will inevitably come from tapping a link and being redirected to the App Store download page for the website's app instead of seeing the content you were looking for. This is even worse than the infuriating tendency of many websites to throw popups on top of their content informing you that they have an app in the store, because now they can actually throw you out of your app instead of just asking with a popup.

Conclusion

All things considered, App Links seem to be more trouble than they're worth. I like the idea of the future that Facebook is pushing for, but with rumors of better inter-app communication coming in iOS 8 or 8.1, I can only hope that Apple reveals a way to do this without the shortcomings of Facebook's implementation. Even if they don't, I might actually prefer having to use lower quality web versions of native apps sometimes as long as they promptly and predictably get me to the information I want. With App Links, each link could do one of three or four different things, and the inconsistency with that makes me shy away from fully supporting the idea. At least with standard links there are no surprises: you tap the link, it opens in a web browser.

That said, Facebook is definitely pushing in a direction that I want to see iOS go. If there were a more foolproof way for links to know to open apps instead of web views, I would support it completely. The idea of always being able to use the higher quality native app experiences of internet content is an amazing one. I just don't think we're ready for that yet, and when we are it may need to come as a first party API, not a third party protocol.