We have the same issue with Xcode 12.2 and iOS 14.2 and applied more details on the Apple Developer forum.
Can this be related? The documentation of the Associated Domain File shows a new section at the bottom about macOS 11 and iOS 14:
Starting with macOS 11 and iOS 14, apps no longer send requests for apple-app-site-association files directly to your web server. Instead, they send these requests to an Apple-managed content delivery network (CDN) dedicated to associated domains.
Update - December 3:
We checked many things:
Code signing
Our target is set to "Automatically managing signing".
In App Store connect we looked up the the entitlement:
- Select app
- Select "Activity"
- Select a Build
- Scroll down to "Store Information", the right column shows the Entitlements.
The com.apple.developer.team-identifier
matches the prefix in the application-identifier
. The latter matches exactly with the value in the apps
array in the apple-app-site-association file on our website.
However, when performing Build & Run with Xcode on device, the debug app is signed with a different Signing Identity:
Apple Development: (other ID than com.apple.developer.team-identifier
)
An estimated guess is that this would create a mismatch with the apple-app-site-association file. Hence we added this new id to the existing apple-app-site-association file and uploaded on our server:
{
"webcredentials": {
"apps": ["ABCDEF1234.com.domain.appName", // Release ID from App Store
"1234ABCDEF.com.domain.appName"] // Debug ID from Xcode
}
}
Tried again, still the same error.
Also performed the usual stuff like:
- Uninstall app from iPhone and reboot iPhone
- Clean Build Folder in Xcode
- Delete Xcode folder DerivedData from /Users/xxx/Library/Developer/Xcode and rebooted MacBook
Availability of apple-app-site-association file
While updating this file on our server, we found a docu update. In June 2019 (when we launched this particular app) it mentions to place the file in 2 folders:
https://<fully qualified domain>/apple-app-site-association
https://<fully qualified domain>/.well-known/apple-app-site-association
Note: Currently only the later .well-known
directory is mentioned.
It appeared that our file was only in the first folder. So we duplicated it and checked again, but still the error is shown.
To rule out that it takes time for iOS 14 to update changes of the apple-app-site-association file based on the new Apple-managed content delivery network (CDN), we even used the mode
option in the entitlements file:
While you’re developing your app, if your web server is unreachable from the public internet, you can use the alternate mode feature to bypass the CDN and connect directly to your private domain.
You enable an alternate mode by adding a query string to your associated domain’s entitlement as follows:
webcredentials:doamin.com?mode=developer
Again, no luck.
TestFlight version
To avoid using Xcode debugger and it's debug signing, archived the Xcode 12.2 build and submitted it to App Store. Verified the entitlements from the build in App Store Connect as described above. They match the apple-app-site-association file.
Released for internal TestFlight testing and tested on device. Tapping the first password text field does not show the password suggestion.
Conclusion
Although we seem out of options, hopefully any of these exercises can inspire others to identify a solution. Or it's just a massive Apple bug and we need to wait for a fix from them.