iOS fails to fetch AASA file for IDNs

Question

Created 3w

Replies 5

Boosts 0

Participants 2

Subject: iOS Fails to Fetch AASA File for Internationalized Domain Names (IDN) in Unicode or Punycode Format Dear Apple Developer Relations Team And Community Members,

We are reporting a critical bug in the iOS Associated Domains feature that prevents Universal Links from working for apps using Internationalized Domain Names (IDN). Problem Description: The iOS operating system does not attempt to download the apple-app-site-association (AASA) file for domains containing non-ASCII characters (e.g., diacritics, Cyrillic). This failure occurs regardless of whether the domain is specified in the app's entitlements in its human-readable Unicode format (e.g., montréal.ca) or its encoded Punycode format (e.g., xn--montral-fya.ca, xn--e1afka0abm4b.xn--p1ai). Without fetching and validating this file, Universal Links are not activated, and the system fails to establish a connection between the website and our app. Steps to Reproduce: Create an app with the Associated Domains entitlement enabled. Add an IDN to the entitlement. We tested both formats: Format A (Unicode): applinks://montréal.ca Format B (Punycode): applinks://xn--montral-fya.ca Host a valid AASA file on our server at the correct, accessible well-known URLs for both domain representations: For montréal.ca: https://montréal.ca/.well-known/apple-app-site-association and https://xn--montral-fya.ca/.well-known/apple-app-site-association

Install the app on a device running the latest iOS version. Monitor network traffic using a tool like Charles Proxy. Observed Result: No HTTP GET request is made to any of the AASA URLs for the domains montréal.ca (in either Unicode or Punycode format) upon app installation. The system does not initiate the domain validation process. In contrast, for a standard ASCII domain (e.g., applinks://example.com), the AASA fetch is triggered immediately and is observed in the network log. Expected Result: iOS should correctly resolve the Internationalized Domain Name (whether specified in Unicode or Punycode format in the entitlement) and perform an HTTP GET request to fetch the AASA file from the /.well-known path, identical to its behavior for ASCII domains. Evidence & Configuration: Our server is configured correctly: SSL certificates are valid, the AASA file is served with the correct application/json MIME type, and is directly accessible via a browser or curl. The AASA file's syntax has been validated and is correct. The issue is reproducible on the latest versions of iOS. Impact: This bug blocks a core platform feature for millions of users in regions that use non-Latin scripts (e.g., France, Russia, China, Arab states). It makes it impossible to use Universal Links with our primary domains, severely degrading the user experience and forcing us to seek suboptimal workarounds like registering separate ASCII domains. Request: We kindly request that you investigate and log this issue as a bug in iOS and forward it to the appropriate engineering team for a fix in an upcoming update. We are prepared to provide any additional information, demo projects, or server access to assist in diagnostics. Thank you for your attention to this serious matter.

Boost

Answer 1

DTS Engineer OP

Apple

3w

Thank you for the post and providing a description of the issue encountered when downloading AASA files. Could you kindly provide some examples of these files via a link or multiple links?

Then go ahead and file the bug: Once you open the bug report, please post the FB number here for my reference.

If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why?

Albert Pascual   Worldwide Developer Relations.

0

Answer 2

v6developer OP

3w

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.

0

Answer 3

DTS Engineer OP

Apple

3w

Thanks for the follow up post and the bug number. Very interesting for sure.

Your domain returns a 301 error for redirect something that will cause a failure:

curl -v https://xn--montral-fya.ca/.well-known/apple-app-site-association

If the response contains a 301 or 302 HTTP status code, your is doing an HTTP redirect, which is not supported when hosting the AASA file as redirects are not supported.

TN3155: Debugging universal links | Apple Developer Documentation#Host-and-verify-your-AASA

You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label "Resolution." We're unable to share any updates on specific reports on the forums.

For more details on when you'll see updates to your report, please see What to expect after submission.

Albert Pascual   Worldwide Developer Relations.

0

Answer 4

v6developer OP

2w

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.

0

Answer 5

DTS Engineer OP

Apple

2w

Thanks for the update.

The HTTP 301 and 302 is not supported for requests to AASA files, I don’t know how was working previously.

TN3155: Debugging universal links | Apple Developer Documentation#Host-and-verify-your-AASA

Upon installation, you can access the file sw_utils located within the sysdiagnose directory. Please provide me with the error message that occurs when the application attempts to retrieve the AASA file. It is likely that the HTTP response redirect is the cause of the application’s inability to fetch the file again. You still can see the try on the file.

When you mentioned that the request is not being made at all, I am perplexed. The system will consistently make the request if you have configured the AASA file URL within the application to download. Naturally, it will cease attempting to download the file after encountering the redirect. Therefore, it is crucial to obtain the log file and troubleshooting steps from the Tech Note link that I provided.

Can you provide the log errors from the file that matches the bundle id for the app?

Albert Pascual   Worldwide Developer Relations.

0