Hacker News Reader

Comment by DAddYE | Hacker News Reader

I'm not sure how could be that possible without a "free pass" by apple, I mean there are rumors that says that for "big corporations" there is no need to pass through the tricky apple review system. If is not that the case I really doubt they can collect as exposed in the article so freely this kind of data, the maximum they can do is use the AI and then match it across different apps (mostly like cookies).

EDIT: AI -> Advertising Identifier (basically old UUID)

View on HN

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

Why is this possible?

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

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?

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.

Didn't know this--thanks for the explanation.

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.

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.

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

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

Certainly the review process for 'big corporations' is as strenuous if not more than for apps that affect 30 users. Sure, the BD teams and developer relations pay more attention to larger companies, but typically apps (those with tens of millions of users) submit new binaries the same way you and I do it, from Xcode, iTunes Connect (or the command line/applet tool)

Thanks glad to hear that, I don't remember where but I read that they yes submit the app with xcode but the review process is basically 0 days, which could make sense to me if they have millions of user affected from a bug.

Maybe the process has change but when I worked to one of these "big corps" afew year ago (2013), our app (game) had to wait like everyone else.

Reply on news.ycombinator.com