App Links: Link Anywhere on Mobile

http://applinks.org/

by _pius • 12 years ago

146 43 12 years ago

applinks.org

yawz2• 12 years ago

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

tehwebguy• 12 years ago

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

ryandawidjan• 12 years ago

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/

CmonDev• 12 years ago

Yes, but it failed to support Windows Phone.

buro9• 12 years ago

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).

onmydesk• 12 years ago

"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.

benjaminfox• 12 years ago

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/

dstaley• 12 years ago

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...

yawz2• 12 years ago

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.

mingfli3• 12 years ago

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

featherless• 12 years ago

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.

filmgirlcw4• 12 years ago

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.

jefftchan• 12 years ago

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

xmlblog2• 12 years ago

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

yincrash2• 12 years ago

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

mingfli3• 12 years ago

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.

filmgirlcw4• 12 years ago

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

yincrash2• 12 years ago

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

fidotron• 12 years ago

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.

jayd16• 12 years ago

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.

jarofgreen• 12 years ago

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.

michaelmior2• 12 years ago

iOS apps can do this as well.

mingfli3• 12 years ago

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

jaegerpicker• 12 years ago

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

ary• 12 years ago

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.

sosuke• 12 years ago

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?

untog• 12 years ago

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/

jmilinovich3• 12 years ago

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

csmajorfive• 12 years ago

"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.

programminggeek• 12 years ago

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?

coralreef• 12 years ago

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.

filmgirlcw4• 12 years ago

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.

drewcrawford• 12 years ago

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.

orijing• 12 years ago

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

the_watcher• 12 years ago

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.

JonoW• 12 years ago

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?

xmlblog2• 12 years ago

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."

App Links: Link Anywhere on Mobile

Related Stories