Hacker News Reader

Comment by jerluc | Hacker News Reader

[Full disclosure, I'm a current employee at URX] We had actually briefly discussed potentially using DNS to help resolve the linkage between a given host/domain and its corresponding mobile apps. However, the problem lies in that we need to discover the linkage from HTTP URL => deeplink URI, which means we need page-level mappings, something that can't exactly be done with TXT records at the domain-level alone.

Android has IMO done a good job of supporting deeplinks to some apps "just work" by allowing apps to handle HTTP URLs with specific host + path patterns (though it is noteworthy that this can lead to security problems!), but iOS does not support this same functionality.

I do, however, agree with the author in that a more seamless integration pattern that can use existing infrastructure would be ideal, but it seems that for now, the pattern of using metadata, HEAD requests, or Link headers in responses is as good as it gets.

View on HN

> Android has IMO done a good job ..., but iOS does not support this same functionality.

So basically the "problem" outlined here is not a problem in itself, but merely a limitation in iOS and iOS is what needs to be fixed, not the web.

Gotcha.

Lets stop bending over backwards for the fruity company, eh? If you want modern and advanced features, stop buying phones with software supplied by a company hellbent on removing choice.

I'm not sure if any of this is sarcastic, so sorry if I've completely missed the mark. But I think despite the opinion that one should have more choice (of which, don't get me wrong, I'm personally an advocate) the problem here goes well beyond the age-old Android vs. iOS debate. Sure, I wish iOS could have implemented features that align with Android and vice versa. But IMO the problem here actually comes from how the "web of apps" evolved separately from the WWW.

On a more concrete note, there are scenarios where neither DNS nor special HTML metadata work. A great example of this is Uber or Lyft. Both of these apps support mobile deeplinking, however there is no real concept of a "page" in these apps. These kinds of apps are more like utilities or services (ride sharing, making phone calls, starting a run, etc), rather than content to consume (reading the news, playing music, watching a video, etc).

That doesn't sound like it'd be difficult to map to the DNS. Something like a record per mapping with each record containing a pattern and a template ought to work -- where does it get difficult?

Without pointing fingers at a specific app, there are several in particular that we have worked with who have "pretty URLs" for their website (e.g. "http://example.com/the-name-of-the-page") but their deeplinks are "ugly" (e.g. "example://page?id=123456"). There is no unified way here to derive the deeplink from the web URL or vice versa. As such, we cannot treat deeplinks and web URLs as always templatized; these are simply URIs whose identities should be considered arbitrary.

On another slightly relevant note, from the perspective of linked data and the semantic web, the <link> tag or "Link" header (both which are suggested by Google and URX) is meant precisely for this kind of reason: being able to link separate resources with a given relation (e.g. "alternate") who may have varying display/device/media qualities (e.g. media queries). Because semantic linkage is between two nodes of the web graph rather than DNS (which I guess would be a subgraph of the web?), one is able to use semantic metadata such as http://schema.org/docs/actions.html to describe not only how to access/consume a resource, but also alternate ways to do so (e.g. from an Android device instead of a desktop client).

Again the above isn't completely impossible to do with DNS, I'll give you that, but it simply is less tenable to assume template-like qualities of all URIs or to ignore the semantic implications of redefining how linked data has worked for the last decades.

Reply on news.ycombinator.com