iHasApp: detect installed apps on a user's device | Hacker News Reader

iHasApp: detect installed apps on a user's device

github.com

Is it really necessary for an app to be able to query whether a URL scheme is handled? It would be nice if Apple could make that API non-functional to put a stop to this.

If you want to build a real, cross-vender multi-app workflow, it's really handy: the initiating app can show different UI based on whether it's available. Ex: only show "Open in Google Maps" button if it's installed.

I find it distasteful that it's being heavily used for analytics instead of building great workflows. Look at all the apps that integrate with Facebook's tracking: "fb..."

I think the best way to have that API would have been to provide an app-specific link with an optional (or maybe even required) second parameter to a fallback link to the website for the same action.

Let's say your app has a "share to FB" button, you'd poke the iOS Api by calling a method and passing both the facebook://shareSomething URI and the http://www.facebook.com/?sharestuff URI as a second parameter in case the app-specific URI is not handled by the device.

That strategy specifically relies on the app author to support specific apps then.

A better solution would be using the share sheet, so any app that supports the type of data you're sharing, can make use of it.

This system of open intent handling (for purposes other than sharing to social-media-network-du-jour) is decent on Android devices, but is all but non-existent on iOS devices. In other words: no, that solution is not currently the better option on iOS given the environment.

iOS8 only came out 2 1/2 months ago. Give it time.

Related-ish - can anyone explain how Chrome on iOS can apparently detect my logged-in username in the GMail app (and suggests I log into Chrome with it)?

Could be shared keychain data between those apps.

This is a two-year old project. Is there any reason we're discussing it now?

The technique and principle is specifically "in the news" at the moment given that Twitter apparently intend to harvest and use this information in their own app. So I'd guess that's probably why.

More specifically, Twitter is apparently doing ad targeting based on this information.

Ah okay, thanks. It doesn't seem like a behaviour that's very in line with the general vibe of the iOS platform, but it's also hard to imagine a way of removing this functionality without degrading the user experience. I wonder if we might see the app store guidelines updated to specifically forbid this sort of wide-net URL surveying.

Reply on news.ycombinator.com