[FB21797091] Regression: Universal Links/AASA Fetching Fails for IDN on iOS 16+

Thank you for the detailed description and the technical context. Based on what you’ve shared, this should be considered as an improvement instead of a regression or in this case a limitation on redirects based on the documentation on the tech note. TN3155: Debugging universal links | Apple Developer Documentation

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

Can you provide me a link to your AASA file? The AASA for the IDN domain should be served at https://xn--[punycode].com/apple-app-site-association (no .json extension, correct mime type, no redirects). The AASA JSON must be valid and contain the corresponding paths (e.g., paths: ["*"] or whatever you’re using) for applinks, and the webcredentials section must mirror your domain. There must be no HTTP->HTTPS redirects or unusual chain that would cause the OS to fetch a different domain during verification. The punycode domain must resolve correctly with valid TLS for the domain (certificate matches the host, no mismatched CN/SANs, chain is trusted).

Also can you provide. The sysdiagnose swcd status for the IDN domain shows “unspecified” on iOS 16+ (as you reported). If you can, also capture swcd trace logs around the moment the link is opened to see if there is any domain-match attempt or certificate issue reported by swcd. In the swcutil_show.txt you submitted shows that was approved for that device.

Domain:               xxxxxxxxonelink.me
Site/Fmwk Approval:   approved

Looking forward to the link to your AASA file!

Albert Pascual
  Worldwide Developer Relations.

Thank you for your response, Albert.

I have collected the sysdiagnose and analyzed the swcutil_show.txt. Here are my findings:

IDN Domain (求人ボックス.com) Status:

Service:              applinks
App ID:               59S472WZMN.com.kyujinbox.app
Domain:               求人ボックス.com
User Approval:        unspecified
Site/Fmwk Approval:   unspecified
Flags:                
(No Last Checked, No Next Check, No Patterns)
--------------------------------------------------------------------------------
Service:              webcredentials
App ID:               59S472WZMN.com.kyujinbox.app
App Version:          979.0
App PI:               <LSPersistentIdentifier 0xa5e1684c0> { v = 0, t = 0x8, u = 0xc48, db = 0033C5BB-DA64-445A-990F-46FB487C364F, {length = 8, bytes = 0x480c000000000000} }
Domain:               求人ボックス.com
User Approval:        unspecified
Site/Fmwk Approval:   unspecified
Flags:

ASCII Domain (kyujinbox.onelink.me) Status:

Service:              applinks
App ID:               59S472WZMN.com.kyujinbox.app
Domain:               kyujinbox.onelink.me
Patterns:             {"/":"/H8dE/*"}
User Approval:        unspecified
Site/Fmwk Approval:   approved
Last Checked:         2025-09-04 07:20:14 +0000
Next Check:           2025-09-09 07:04:29 +0000

Key Observations:

1. The IDN domain shows Site/Fmwk Approval: unspecified while the ASCII domain shows approved.
2. The IDN domain has no Last Checked timestamp, suggesting that swcd has never attempted to verify the AASA for this domain.
3. The IDN domain has no Patterns registered, while the ASCII domain has patterns correctly populated.
4. Interestingly, the domain is stored in Unicode form (求人ボックス.com) rather than Punycode (xn--pckua2a7gp15o89zb.com).

AASA Verification via curl:

I have verified that the AASA is correctly served at https://xn--pckua2a7gp15o89zb.com/.well-known/apple-app-site-association:

• HTTP 200 OK (no redirects)
• Content-Type: application/json; charset=utf-8
• Valid SSL certificate with matching subjectAltName
• Valid JSON structure with applinks and webcredentials

This evidence strongly suggests that swcd is not properly initiating AASA verification for IDN domains. The AASA file is correctly configured and accessible, but iOS appears to skip the verification process entirely for the IDN domain.

Is there any additional diagnostic information I can provide, or is this a known limitation that requires a fix on the iOS side?

Thank you for your assistance.

Thanks so much for providing this, this is really good troubleshooting and you went over the steps.

I like to verify the file when gets synced to Apple servers. I see some characters that should be in plain text instead of this:

curl -v https://app-site-association.cdn-apple.com/a/v1/xn--pckua2a7gp15o89zb.com

The content:

 {
                        "/": "/*%E3%81%AE%E4%BB%95%E4%BA%8B",
                        "?": {
                            "cid": "?*"
                        }
                                            },
                    {
                        "/": "/*%E3%81%AE%E4%BB%95%E4%BA%8B-*",
                        "?": {
                            "cid": "?*"
                        }
                                            },
                    {
                        "/": "/%E9%9A%9C%E3%81%8C%E3%81%84%E8%80%85%E6%8E%A1%E7%94%A8/*",
                        "?": {
                            "cid": "?*"
                        }
                                            }

That could be causing an issue. Another way is to test on the device using the App Notes with a link.

For the 求人ボックス.com I do not have the AASA file. But could be an issue with the URL?

Albert Pascual
  Worldwide Developer Relations.

Thank you for verifying the AASA on Apple's CDN, Albert.

Let me clarify the points you raised:

1. URL-Encoded Paths in AASA

The URL-encoded characters in the paths are intentional and correct. These represent Japanese text in URL paths:

Per RFC 3986, non-ASCII characters in URL paths must be percent-encoded. This is the standard approach for internationalized URLs and should not cause issues with AASA parsing.

2. Relationship Between 求人ボックス.com and xn--pckua2a7gp15o89zb.com

These are the same domain:

• 求人ボックス.com — Unicode/display form (IDN)
• xn--pckua2a7gp15o89zb.com — Punycode/wire form

The AASA is correctly hosted at the Punycode domain (https://xn--pckua2a7gp15o89zb.com/.well-known/apple-app-site-association), and as you confirmed, it is successfully synced to Apple's CDN.

3. The Core Issue

Based on swcutil_show.txt, the problem appears to be:

1. swcd stores the domain in Unicode form (求人ボックス.com)
2. swcd never attempts to fetch the AASA (no Last Checked timestamp)
3. The status remains unspecified because verification was never initiated

In contrast, ASCII domains like kyujinbox.onelink.me show Last Checked, Patterns, and approved status — indicating that swcd successfully fetched and verified those AASAs.

This suggests that swcd may not be converting the Unicode domain to Punycode before attempting AASA verification, or it may be skipping IDN domains entirely.

4. Entitlement Configurations Already Tested

We have already tested multiple entitlement configurations over the past three years:

We tested on both simulators and physical devices within 1-2 months of each major iOS release:

• iOS 16: September 2022
• iOS 17: September 2023
• iOS 18: September 2024

In all cases, the behavior was consistent:

• Tapping a Universal Link opens Safari instead of the app
• The Smart App Banner does not appear on Universal Link-enabled pages (e.g., /password-mail)

Conclusion

Given that:

1. The AASA is correctly hosted and synced to Apple's CDN
2. ASCII domains work correctly on the same app/device
3. No entitlement configuration (Punycode, Unicode, or both) has resolved the issue over 3 years

Is this a known limitation of swcd for IDN domains? If so, is there a planned fix, or is there an official workaround that we may have missed?

Thank you for your continued support.