My app uses both a custom URL Scheme and Universal Links. I deployed the custom url scheme a while ago and it works. I just now installed Universal links. But I found some interesting behavior between android and ios and the two methods.
1. Custom URL Scheme (cordova-plugin-customurlscheme) will open myapp:// links and pass in the full url myapp://this/path?var1=value1&var2=value2 to the window.handleOpenURL function.
On iOS , each type of link (custom scheme or standard url) will trigger their corresponding event opener.
However, on Android, I have found that any external link, whether a custom scheme (myapp://) or a standard URL will trigger both the custom url opener (handleOpenURL) and the universal link subscriber. So for the Universal Links handlers, I am only loading universal links event handlers for iOS and just using the custom url scheme handleOpenURL function to manage both incoming custom url schemes and standard URLs. Inside the function I am just testing for the URL scheme to determine how to process the url parameters for each.
I have also found that Safari will treat a custom scheme as a clickable link while Chrome does not. I test safari and chrome on both and iPhone and an Android phone and the behavior is the same. Thus its def not the phone determining if the custom url scheme is clickable or not, its the browsers themselves.
3. iOS App Search API Validation Tool - is a piece of garbage. I have deployed the apple-app-site-association file to the root of my website AND to the /.well-known/ directory. The validation tool hits my site, grabs the file (both of them actually) and then gives me an Error no apps associated with url As well, according to Apple Universal Links troubleshooting guides, when the app is installed and launched the app is supposed to retrieve the server file too - however my server logs never show the app requesting the file.
YET....Universal Links does work on my iPhone (...and Android too).
My app uses both a custom URL Scheme and Universal Links. I deployed the custom url scheme a while ago and it works. I just now installed Universal links. But I found some interesting behavior between android and ios and the two methods.
1. Custom URL Scheme (cordova-plugin-customurlscheme) will open
myapp://links and pass in the full urlmyapp://this/path?var1=value1&var2=value2to thewindow.handleOpenURLfunction.2. Universal links will open 'https://myapp.com
links and pass in the full urlhttps://myapp.com/this/path?var1=value1&var2=value2to theuniversalLinks.subscribe('externalLink', 'app.onExternalLink')`On iOS , each type of link (custom scheme or standard url) will trigger their corresponding event opener.
However, on Android, I have found that any external link, whether a custom scheme (
myapp://) or a standard URL will trigger both the custom url opener (handleOpenURL) and the universal link subscriber. So for the Universal Links handlers, I am only loading universal links event handlers for iOS and just using the custom url schemehandleOpenURLfunction to manage both incoming custom url schemes and standard URLs. Inside the function I am just testing for the URL scheme to determine how to process the url parameters for each.I have also found that Safari will treat a custom scheme as a clickable link while Chrome does not. I test safari and chrome on both and iPhone and an Android phone and the behavior is the same. Thus its def not the phone determining if the custom url scheme is clickable or not, its the browsers themselves.
3. iOS App Search API Validation Tool - is a piece of garbage. I have deployed the
apple-app-site-associationfile to the root of my website AND to the /.well-known/ directory. The validation tool hits my site, grabs the file (both of them actually) and then gives me anError no apps associated with urlAs well, according to Apple Universal Links troubleshooting guides, when the app is installed and launched the app is supposed to retrieve the server file too - however my server logs never show the app requesting the file.YET....Universal Links does work on my iPhone (...and Android too).