Some more information:
I've monitored the swcd service in my device logs to confirm that the associated domain is registered upon installation and that the AASA file is properly accepted.
Both those things appear to be working. Here are two relevant excerpts from the device log (please advice if you can direct me how to export filtered text logs from the console app.)
Started request for domain 'placetime.spatialfirst.com', URL 'https://placetime.spatialfirst.com/apple-app-site-association' Completing request for 'https://placetime.spatialfirst.com/apple-app-site-association', status 0/0x0 noErr
However, when I click on my universal link (from within the app I am testing), the browser is opened (instead of redirecting to my app), and the swcd service reports:
Get info for service 'applinks', app ID 'NULL', domain 'pl...'
Yes, the message is truncated in the log (not by me).
But why is the app ID 'NULL'?
In the device log, you can see the AASA file has been accepted when you see something like this:
Updated app ID 'com.my.great.app', domain 'mydomain.com', flags 0x0 < > -> 0x2 < SiteApproved > on check
The 0x2 flag indicates approval. 0x4 means not approved, which can happen for various reasons having to do with website configuration, or a bundle ID that does not match.
This is how I test universal links functionality:
- Make sure the app has been deleted from your test device.
- Deploy the app from Xcode.
- Send yourself an email with the Universal Link you want to test. (Or create a note containing the link in the Notes app.)
- Receive the email on your test device, and tap on the link. (Or tap on the link in the Notes app.)
- Observe if your app opens and shows the expected content.
If the app opens, then universal links has been properly implemented.
You also mentioned the App Search API Validation Tool. This will only successfully validate universal links for apps already on the App Store. If you see that the tool is not validating an app that's been on the store for a couple of weeks, please file a bug report.
I hope this helps.
Thanks for the reply, Musashi.
I appreciate the information, but a different experiment has provided some additional context. Here's what happened: I updated my device to iOS 13 (in beta) and updated my xCode to 11 beta 5. Sure enough, the same project files builds and deploys via xCode and now the Universal links work when I click on them in a Slack window. No other changes were made to the xCode project.
I have admitted confounded the situation by attempting this on a different version of xCode. However, this does appear to confirm that my AASA is staged correctly.
I also went back and confirmed that the previous build did not work (by restoring it via TestFlight.) Unfortunately, neither the xCode 11 beta 5 or the TestFlight installation vector do not appear to induce any of the swcd messages discussed in our previous messages. You can see an afternoon of testing here, filtered by the swcd process: https://pastebin.com/9uFTUrLE
Either the format of the domain authorization messages has completely changed, I am not filtering the log messages properly, or something else has gone wrong. (Bear in mind that I was able to get my test URL to trigger successfully from Slack and launch my app.)
At present, things "work" with the following caveats:
1. The app I'm testing has a feature for opening links, but when I open my own Universal links from within my app, Safari is opened instead of hitting my callback (in the same app). Why is that? Am I doing something wrong here? How can I get Universal links to be... universal?
2. The Universal links work on iPad, but not iPhone. I am going to continue trying to get this working on both device types.
Again, thanks for your reply. If you or anyone can comment on the two issues outlined above, I would appreciate it.
Im having the same problem with Xcode11 and iOS 13.1
Were you able to resolve it?
There is a bug with ios 13 and universal links which is causing all apps to have this problem. Including Apples own apps and mainstream apps like instagram