3 ms·

In iOS9, apps can now register to arbitrary http URLs, but that in fact requires the app to be correctly associated with the domain, which in turns requires a l

In iOS9, apps can now register to arbitrary http URLs, but that in fact requires the app to be correctly associated with the domain, which in turns requires a lengthy process (the domain must expose via HTTPS a json naming the bundle id, signed with the TLS private key). So I think they made it right for generic URLs while the custom URLs has been a little unfortunate from day 1, but it's hardly something new. Btw can anybody explain how association to arbitrary http URLs works in Android? Is there a similar validation, or can any app intercept any URL if it wishes so?

dozy 11y ago
In Android it's all been rolled into the Intent/IPC system since day 1. Apps are composed of Activities, and Activities can defined Intent filters. Intent filters describe what the Activity can handle, including but not limited to URLs. Through this system, any app can register for any url (IIRC you can filter by scheme, host, and/or path). When a url is invoked, the system asks the user which app should handle it if there are several that can. You can also set a default app for the given url, etc - the whole system, though very flexible, has been widely criticized as having mediocre UX (though IMO it mostly works just fine). In Android M (unreleased), they've added a similar feature as in iOS 9 whereby you can ensure that URLs you define and own are always handled by your app. Essentially you host a json file at your domain, served over https, that specifies the SHA256 fingerprint of your app's signing cert. Your app defines the url filter similar to before and the system makes sure that you match the fingerprint. Android being Android, you can still tweak the default handling of intents even if apps do this, but it's pretty hidden.