Maintaining app list?

[mladjan]

How you maintain list of the apps? How can I help you with this?

[nicholascross]

It doesn't seem like iHasApp maintains current scheme mapping. Surely this limits its utility somewhat. Have people moved onto something else?

[danielamitay]

I don't keep updating the iHasApp list of schemes because there is no simple and authoritative way to do so. The only sure-fire way to know what schemes an app implements is to download the app and analyze it's Info.plist. For free apps, this becomes a problem of time (there is no automatic app purchase method for obvious reasons), and for paid apps this becomes a problem of financial incentive. Don't forget, not every app even implements a scheme, and some apps implement the same scheme.

iHasApp has over 12,400 schemes (after some culling on my part). The closest alternative that I have seen is Zwapp's open directory, which claims to have around 11,800 schemes.

This is not a simple problem to solve.

[nicholascross]

I hope my comments didn't come across as whinging, I merely noticed that the scheme json file hasn't changed in 2 years which leaves a lot time for new apps to fall through the cracks.

What if you would like your new app to be discoverable by iHasApp? Without a public directory that is managed openly it is not possible.

I can see how being the bottle neck for curating schemes could be time consuming and I take your point about doing the actual scanning for schemes requiring purchase of particular apps. It seems this problem could be solved by distributing the task amongst the community.

Perhaps a separate repository with different scheme directories would be a good idea if the integrity of the primary file needs to be maintained. The onus is then on the community to use and maintain it at their own risk, whilst others can take the safer route of using only your curated scheme directory.

[danielamitay]

Don't worry, my comment looked a bit too defensive. So something like a curatedAppSchemes.json and communityAppSchemes.json, where devs can merge in additions to the communityAppSchemes.json?

Considering the issues with the current and best-case detection system, may I ask your use case for iHasApp? The main reason I have not been very actively maintaining iHasApp is that even in it's most up-to-date and ideal state, iHasApp can only detect so many apps, with an ever growing requirement of memory and CPU time.

[nicholascross]

That sounds good, it will allow developers to submit their own apps.

I was thinking it might be advantageous to separate it into multiple files perhaps by app category. This might allow you to only load schemes you are actually interested in. For example you might want only "educational" or "productivity" apps. This might help keep memory and cpu usage down, but how devs categorise things is subjective.

The proposed use case which we haven't started implementing yet involves, location based pinning of apps using iBeacons. When inside a region user will have access to particular apps pinned by other users of our system. If the user doesn't have the app or the app doesn't support any known scheme it will take them to the app store but if it supports a scheme we can detect it and launch it directly. We can also use the detection to pin other apps to beacons from with in our app. The obvious flaw here is duplicate schemes, but I imagine in general this will still be a useful feature for our users.

[mikegottlieb]

This project can help with this goal of building up a community dictionary. https://github.com/HBehrens/collectIPAMetaData

If had a long list of Apple IDs to examine for URL schemes and so I whipped up some AppleScript that could go over the list and download all of them to a machine through iTunes. Then I used the project mentioned above to extract the info.

For a while it looks like the owner was accepting PRs, but I think the project may be dead now.