A Note On App Links And x-callback-url

I meant to post this shortly after my article on App Links last week but college finals distracted me, so here it is now.

I've seen some people suggesting that the adoption of App Links could lead to x-callback-url fading into obsolescence. This is a completely unfounded notion. Even though App Links and x-callback-url are both URL scheme-based methods of providing deeper and more powerful inter-app communication, they generally will not compete because x-callback-url provide's only a subset of App Links' functionality. It's true that the referer_app_link property of the App Links protocol provides a functionality practically identical to that provided by x-callback-url, but that functionality is bound by the rigidity of the rest of the protocol while x-callback-url is completely free from such constraints. In order for App Links to become some sort of standard for navigation, they have to strictly define the parameters possible for the first action that tapping an App Link will launch. This first action must draw data from an actual source on the web, and it must find a very specific set of instructions in that data. x-callback-url, on the other hand, has absolutely no restrictions on the first action which its x-success parameter is tied to. This distinction makes x-callback-url more versatile, but without the strict guidelines for finding information from the web to use in the first action, it could never do what App Links does on its own. App Links, on the other hand, could never be used for such a wide variety of actions for iOS automation like x-callback-url can be used for, because the referer_app_link property can only be used to return from navigating to some other place, and can only be defined once for each page of the navigating app. There is no way to use different referer_app_links depending on what link is tapped, so the secondary action is not limitless like x-callback-url actions are.

There are a few exceptions in which x-callback-url is being used in place of App Links, most notably in Google’s suite of apps. When you tap a YouTube link in Chrome, or vice versa, you will jump to the other app with a special back button to return you to the original one when you’re finished. Google can only do this, however, because they control all of the apps that the feature works with, and it is a fairly small list of apps. They basically built their own version of App Links, but it could never be used as an overarching protocol like App Links because Google’s developers had to manually build support for each app it works for into all the other apps. Greg Pierce, the creator of x-callback-url, has implemented similar inter-app communication between some of his apps, but again this can only be done because he built all the apps and has full control of all the code. App Links will work for any app without developers having to manually add support for each and every App Link-able app into their own code, that’s the entire point of the protocol.

These general distinctions are what have led x-callback-url to be used mainly to increase productivity by tying together powerful and usually user-customized actions. App Links, on the other hand, will remain geared simply towards improving navigation, and will never become nearly as great a productivity tool as x-callback-url. Thus, while in some cases they may get in each other's way, for the most part these two protocols will live in harmony, neither eliminating the other.