4 ms·

iHasApp: detect installed apps on a user's device

28 points by gilles_bertaux 12y ago

galonk 12y ago
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.
- e28eta 12y ago
  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..."
  - Khao 12y ago
    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 http://www.facebook.com/?sharestuff URI as a second parameter in case the app-specific URI is not handled by the device.
  - stephenr 12y ago
    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.
    - 21echoes 12y ago
      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.
      - stephenr 12y ago
        iOS8 only came out 2 1/2 months ago. Give it time.
cmyr 12y ago
This is a two-year old project. Is there any reason we're discussing it now?
- jamesbrownuhh 12y ago
  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.
  - guyzero 12y ago
    More specifically, Twitter is apparently doing ad targeting based on this information.
  - cmyr 12y ago
    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.
scoot 12y ago
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)?
- speedyapoc 12y ago
  Could be shared keychain data between those apps.

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.

e28eta 12y ago
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..."
- Khao 12y ago
  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 http://www.facebook.com/?sharestuff URI as a second parameter in case the app-specific URI is not handled by the device.
- stephenr 12y ago
  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.
  - 21echoes 12y ago
    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.
    - stephenr 12y ago
      iOS8 only came out 2 1/2 months ago. Give it time.

cmyr 12y ago

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

jamesbrownuhh 12y ago
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.
- guyzero 12y ago
  More specifically, Twitter is apparently doing ad targeting based on this information.
- cmyr 12y ago
  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.

scoot 12y ago

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

speedyapoc 12y ago
Could be shared keychain data between those apps.