The redirect is used to work around the problem described above. Actually, the presence of the file at /.well-known/apple-app-site-association is irrelevant. The core issue described in the previous message is that the system does not even attempt to fetch the AASA from Apple's server, even though it exists here: https://app-site-association.cdn-apple.com/a/v1/xn--montral-fya.ca. But this is also irrelevant because the system blocks AASA requests for domains in Punycode. What I want to say is that the expected behavior is this: I specify Associated Domains. When the app is installed, a request for the AASA is made to Apple's CDN. This request might result in an error or return a valid file. For us, this is unimportant because the request is not being made at all. Another small clarification: when I specify non-existent domains like "xnmontral-fya.ca", I can see via proxying that the system does try to fetch the AASA. However, if I specify any string containing the "xn--" prefix (denoting a Punycode sequence) anywhere in the domain, the system stops attempting to request the AASA from Apple altogether.

Good afternoon. Example links: https://app-site-association.cdn-apple.com/a/v1/xn--montral-fya.ca https://xn--montral-fya.ca/.well-known/apple-app-site-association Reference number: FB21076762 Additionally, during testing we observed the following: When adding any domain containing "xn--" anywhere in the string to the Associated Domains entitlements, the system does not attempt to fetch the AASA file.