4 ms·

Didn't think it was possible, but: http://www.ihasapp.com http://www.ihasapp.com Why is this possible?

cwalcott 12y ago
For apps that support deep linking, you could check if the device responds to a URL with a corresponding scheme (e.g. "twitter:///")
DAddYE 12y ago
As said by @cwalcott should works for apps that support deeplinking so apps that enable "tel://", "skype://" etc... However if you have an app like Tinder that as no scheme (AFAIK) shouldn't be detected. Indeed is still bad that they do that but seems they're basically using an "hack". iHasApp has a large list of URL schemes, mapped to the iOS App that they identify. The framework essentially runs through all of these schemes, and determines which URL schemes are handled by the current device, and create a list of application ids as a result of successful queries.
- ryanwhitney 12y ago
  Thanks for the explanation both. I was assuming there should be some sort of buffer Apple could have built in, but I guess being able to tell whether or not the user has left the app directly after hitting a deeplink seems difficult to deny… despite being hacky.
- deleted 12y ago
  [deleted]
- xxx_ 12y ago
  You are not correct. Each app that uses Facebook login MUST declare custom URL so that you can come back to it when you are transferred to FB app (it has a syntax "fb...", where "..." are replaced with FB app id). So you can assume that each and every application that uses FB login has custom URL. Now Tinder declares 3 custom URLs actually: "tinder", "fb464891386855067", "tinderdebug".
moj 12y ago
There is also sysctl(), which returns running process info. Not the full installed app list, but arguably more useful and bonus it doesn't rely on app urls. A (mostly old) discussion about it on stackoverflow: http://stackoverflow.com/questions/8275578/how-to-get-information-about-free-memory-and-running-processes-in-an-app-store-a http://stackoverflow.com/questions/8275578/how-to-get-inform...
- ryanwhitney 12y ago
  Strange. Seems like anything other than built-in apps should be anonymized in what's returned here. Is there a reason it isn't? Just something that's not allowed but slips through the review process?
  - moj 12y ago
    It's a lower-level c-api, so perhaps it's slightly harder to scan for in the submitted binaries? Its overdue blocking/nerfing, and you can start the countdown for that now. (As others have noted). Hopefully it will be anonymized but not completely nixed; it provides legitimate debugging info.
    - ryanwhitney 12y ago
      Didn't know this--thanks for the explanation.

For apps that support deep linking, you could check if the device responds to a URL with a corresponding scheme (e.g. "twitter:///")

DAddYE 12y ago

As said by @cwalcott should works for apps that support deeplinking so apps that enable "tel://", "skype://" etc... However if you have an app like Tinder that as no scheme (AFAIK) shouldn't be detected. Indeed is still bad that they do that but seems they're basically using an "hack". iHasApp has a large list of URL schemes, mapped to the iOS App that they identify. The framework essentially runs through all of these schemes, and determines which URL schemes are handled by the current device, and create a list of application ids as a result of successful queries.

ryanwhitney 12y ago
Thanks for the explanation both. I was assuming there should be some sort of buffer Apple could have built in, but I guess being able to tell whether or not the user has left the app directly after hitting a deeplink seems difficult to deny… despite being hacky.
deleted 12y ago
[deleted]
xxx_ 12y ago
You are not correct. Each app that uses Facebook login MUST declare custom URL so that you can come back to it when you are transferred to FB app (it has a syntax "fb...", where "..." are replaced with FB app id). So you can assume that each and every application that uses FB login has custom URL. Now Tinder declares 3 custom URLs actually: "tinder", "fb464891386855067", "tinderdebug".

moj 12y ago

There is also sysctl(), which returns running process info. Not the full installed app list, but arguably more useful and bonus it doesn't rely on app urls. A (mostly old) discussion about it on stackoverflow: http://stackoverflow.com/questions/8275578/how-to-get-information-about-free-memory-and-running-processes-in-an-app-store-a http://stackoverflow.com/questions/8275578/how-to-get-inform...

ryanwhitney 12y ago
Strange. Seems like anything other than built-in apps should be anonymized in what's returned here. Is there a reason it isn't? Just something that's not allowed but slips through the review process?
- moj 12y ago
  It's a lower-level c-api, so perhaps it's slightly harder to scan for in the submitted binaries? Its overdue blocking/nerfing, and you can start the countdown for that now. (As others have noted). Hopefully it will be anonymized but not completely nixed; it provides legitimate debugging info.
  - ryanwhitney 12y ago
    Didn't know this--thanks for the explanation.