App Links: Link Anywhere on Mobile | Hacker News Reader

App Links: Link Anywhere on Mobile

applinks.org

146 points_pius43 comments

Hooray, now it can join URX[1] and DeepLink[2] in this "making links actually do things" space. Of course, being the free, open source option I do hope this prevails, but it amazes me the lengths we've had to go (URX even raised $12m) in trying to get the iPhone to do what Android has been able to do for years. Parsing URLs really shouldn't be this difficult.

[1] http://urx.com/

[2] http://www.deeplink.me/

Similar to the proposed methods of Google and Twitter, Applinks is Facebook's proposal for how developers expose their deeplinks to the web via meta tag markup.

In addition to their meta tags, Facebook also released an API that lets developers send Facebook a request with a URL to receive a response for the equivalent deeplink. This solution works best for deeper native integrations and those who want to go through Facebook to get this mapping. Fortunately, URX omnilinks already support Applink tags and don't require any code-level integration for developers to start linking to other apps.

Basically, the tags are open source (good), much like URX's working proposal [1], and the implementation of using the tags goes through Facebook. Facebook requires a native integration and does get around browser flashes, but is much more difficult to integrate than omnilinks, where you simply put urx.io/ in front of any weblink.

[1] http://urx.com/documentation

"implementation of using the tags goes through Facebook"

No, it doesn't. You can use the SDKs without any dependency on Facebook.

Omnilinks are cool. I hope we can all work together to make mobile better.

To be more specific, I was talking about "Facebook App Link index" which seems to be the way for a developer to find a deeplink based on a given weblink while going through Facebook.

Look forward to discussing further and seeing how we can work together here to connect the webs.

Well, there is nothing to prevent someone from creating a Facebook-free app index. And I'm sure that will exist soon.

I think omnilinks and applinks are both cool. Anything that can get us closer to a pseudo-standard for intra-app linking is a win.

Agreed, and do think that will exist in the near-term as well. It's so exciting to see all the movement in this space.. it's a huge win in the name of user experience and I think that things will continue to move quickly here.

"mobile" being iPhone? Because android apps can handle their own (http[s]) urls just fine.

I think Android definitely has a stronger story than iOS, but Android also allows any app to handle any url, so multiple apps can attempt to handle a domain (like facebook.com), whereas app links allows you to direct the link to a single app (or a suite of apps).

"mobile" also means more than just iOS and Android, although they're the two dominant platforms today.

Right. Like this supports Windows Phone. And the potential advantage would be one URL scheme rather than a pattern for each OS.

what happens if two iOS apps try to register the same scheme?

I believe that the behavior is undefined, but I haven't checked since iOS 7 came out. The docs used to say it was undefined, and I think people reported that it would pick the app that was most recently installed.

Really it's a step backwards from Android if you overspecify to the point of saying the exact target app (which Android does support, but shouldn't generally be used between applications).

The whole point is to allow different apps to be swapped without the others needing to change. All this does is tie everything too closely together, and more likely than not to Facebook.

All Applinks is doing on Android is using the package name you specify in the metadata.

There's really not a lot going on here. Webpage scheme that you can parse to build an intent from. This couldn't be more than 50 lines of code. It would be less if they decided to use a custom URI scheme like "applinks://example.com?packagename=example.com" instead of parsing every webpage you go to looking for the applinks headers.

> but Android also allows any app to handle any url, so multiple apps can attempt to handle a domain (like facebook.com), whereas app links allows you to direct the link to a single app (or a suite of apps).

So Applinks suddenly removes the ability of 3rd party apps to say "we can handle this content". I can see why big players like FB would want it - I think this is a bad thing for small players and hence the open ecosystem.

iOS apps can do this as well.

iOS apps cannot handle (or intercept) http/https urls, they can only register a custom scheme with the OS and handle those.

Ah, yes. This is true. Although the original statement was "android apps can handle their own urls" which I interpreted differently.

So does the iPhone, it's not really that hard to implement IMO.

Can anyone explain how this differs (if at all) from the deep linking support built into Android? http://developer.android.com/training/app-indexing/deep-link...

That's the first question that popped into my head. I've some reading to do about App Links before being able to answer it properly, though.

From what I understand, app indexing is currently Android only, whereas app links was designed to be cross platform from the start.

From a quick glance at the docs (http://applinks.org/documentation/) it appears that this standard depends on the web to define app links independently from the apps themselves. Basic flow would look something like:

- user submits content with a link to http://imgur.com/vxKOi to your social app of the month

- another user taps that link in the app

- the app would look at that url's header and pull out any applink information.

- using the downloaded links, the app would try to open the imgur app with the provided url

- the imgur would then open, showing the content for the url that was tapped.

Note that none of the above mentions being on an iPhone, thus the cross-platform nature of the solution.

It's cross-platform, so the URI list will work across apps on multiple platforms. So that's the biggest difference, I suppose. iOS, Android, Windows Phone.

Can someone explain how and why I would truly want to link out to another app on someone's phone? I get the whole android intents thing and having a "share" button and letting other services handle some of those things, but in what cases is it super beneficial to link to another app and leave your app?

The only thing I can think of are things like PDF viewers or maybe cross linking your own apps?

I have a photo collage app that produces a jpg. The user usually wants to share the collage on social media like Facebook or Instagram. Keeping up to date with the various APIs is a pain in the ass (and I use ShareKit, a library to aggregate these services), and the user still has to sign in to give credentials to import photos or post to social media.

Linking could simplify the exchange of data here, where I could just pass the photo to the relevant app to handle.

So one of the examples they use is really powerful: buying movie or concert tickets.

I'm in an app like IMDb or Facebook or whatever and I see a movie trailer. I'd love to be able to buy tickets immediately. Right now, unless the app developer specifically hard-linked to a ticketing app, I have to manually open that app, search for the ticket, then return to where I was before. With an app link, I can simply open that movie page inside MovieTicket.com or Fandango or whatever, and buy my tickets (using whatever logins are already associated with that app and account) and then pop back to where I was before.

Same thing if I have a special type of audio or video file in a text document. Rather than having a link to that file open in a web browser that then tries to open up inside an app, it can open up inside the native app, and then pop back to my document after it is done playing.

It's not that different from the "open in" option in iOS or intents in Android -- except you can also have that sort of stuff apply to web markup. So a link to a content type accessed on the mobile web will still execute in-app, rather than in a mobile web view, which might not be as full-featured as the content owner wants.

Sure. So let's say you run Skype. Currently the way skype works is to add somebody, they have to find out their Skype name, tell it to you, you receive it, they type it into a search box, pick from a list, then wait for the other person to confirm. That is, shall we say, terrible.

Deep app links would let you just send somebody skype://user/jim89 or better yet skype://invites/9384jr83 which provides a massively better on boarding experience.

Not only that, but I am working on an app where you don't even have a username, so there's nothing to type in a search box. A URL-based scheme like this one allows you to eliminate an entire field and the whole "create an account" step.

For the same reason that you would link to another website on the web.

The people who want it most (will pay the most and will pay immediately) are advertisers. Which means the apps that want it most are those that have loyal users, but have been unable to effectively monetize them to advertisers. There are plenty of applications for it outside of ads. To extend your question - why would you truly want to link out to another webpage in someone's browser? That's what AppLinks/OmniLinks/DeepLinks are designed to do - to make the relationship between app use resemble the relationship between web pages.

From one perspective this looks killer: It looks like it supports a long-time pain of being able to direct someone to download an app and then open a specific location within the app. You could now have a QR code that when scanned from a shop didn't just download the right app for the phone, but the applink would also describe what to open once the app is installed.

But from another perspective this looks like a nightmare: It entrenches apps as the universal interface, and not the browser, by keeping people within the world of apps.

I can see why advertising companies want this, the browser is a battleground for control of the presentation layer (adverts) and apps help protect that (by locking out adblock add-ons, etc).

"It looks like it supports a long-time pain of being able to direct someone to download an app and then open a specific location within the app. You could now have a QR code that when scanned from a shop didn't just download the right app for the phone, but the applink would also describe what to open once the app is installed."

Is that what it actually does? If I have an iTunes url to my app can I imbed an argument to send to the app once it runs after being downloaded? I would have thought a standard requires implementation by apple for that to be the case.

Ive read the fb post, saw the f8 section and watched their video and I still don't know what it does. Maybe Im dim.

These links don't preserve intent for users who don't already have the app, due to the App Store's and Google Play's problems with attributing app downloads.

My company, Tapstream, fixes this by pairing our attribution platform with a deep link redirector - users who have the app already are deep linked, and users who don't have the app are sent to the App Store.

Then, once the new user installs the app, the app receives a callback with the user's source and any query string parameters on the original link. Docs: https://tapstream.com/developer/deferred-deep-links/

This is good. I'm left wondering about a couple of thing.

- Would a parallel standard be useful that allows the rel="" and type="" attributes of <a> to signal the kind of app (for mobile and desktop) that could better handle the resource than the browser? I've been enamored with this idea of general cross-linking between browsers and native apps for quite a while, but it seems like a pipe dream.

- Is it even possible to have general data types that multiple apps can handle (and what would the selection UI look like for that)? Think lat/long for mapping apps, addresses (for a variety of apps), events (time/data/address), etc.

I should add that the referring app UI for iOS is clever, great job whoever thought of that.

Didn't 2 other companies just raise millions to do this?

http://www.urx.com/ would be one.

techcrunch.com/2014/04/28/mobile-deep-linking-startup-urx-raises-12-million-launches-universal-link-service-called-omnilinks/

Yes, but it failed to support Windows Phone.

@CmonDev We [URX] definitely have looked into support for Windows Phone deeplinking, but found it difficult to find any examples of websites using Windows Store meta markup properly, which would be a prerequisite for us to support such apps. Can you point us in the direction of any good examples?

How does this work in the case of namespace collision? Will we have squatters on the uri schemes?

The details are OS-specific, but the user is prompted to choose which app to open the link with on iOS.

Here's a link to Facebook's blog post: https://developers.facebook.com/blog/post/2014/04/30/app-lin...

I want to see the App Links for the apps in their service, the Pinterest and Spotify links would be nice to have access too. Pinterest is notorious for being closed off, only recently opening open an API. Will the list be open?

One problem I'd like to see solved across platforms is the case when you click an app deep-link for an app you don't have installed. Currently we're having to do some crazy hacks so that a single link goes to the relevant app store if the app is not installed, or opens the intended app if it is. Solutions for iOS and Android are also currently quite different, and it's a PITA. Do AppLinks solve this problem?

AppLinks is supposed to enable you to prompt the user to install the app if they don't already have it, which is the reason why the spec calls for developers to embed the al:ios:app_store_id, for instance.

From the docs (http://applinks.org/documentation/#uxguidelinesrecommendatio...):

"You may choose to take a user to the native app store when the app is not installed or display the name of the app based upon the App Link metadata for a given link."

Reply on news.ycombinator.com