Thank you, Albert. I have updated FB21797091 with the following information: App ID: 59S472WZMN.com.kyujinbox.app Team ID: 59S472WZMN App Store URL: https://apps.apple.com/jp/app/id1635254205 Reproduction steps using the published app Since our app is already on the App Store with all the necessary entitlements and AASA configurations in place, I believe this would be the most efficient way for your team to verify the issue without requiring a separate sample project. Could your team first try reproducing the issue using our published app? If a focused sample project is still required after that, please let me know your team's App ID (format: TEAMID.bundleid) and I will: Add it to our AASA file Create and attach a minimal sample project to FB21797091 Thank you for your continued support in resolving this issue.

Thank you, Albert. I'm glad the issue has been routed to the correct team. Before I prepare a sample project, I'd like to suggest a simpler approach: Our app is already available on the App Store: https://apps.apple.com/jp/app/id1635254205 Your engineers can download it directly and reproduce the issue with the following steps: Download and install the app from the App Store Open the Notes app Create a note with this URL: https://求人ボックス.com/password-mail Tap the link Expected: The app should open Actual: Safari opens instead This would be the fastest way to verify the issue without needing a separate sample project, since all the necessary entitlements and AASA configurations are already in place. If you still require a sample project or TestFlight build, please let me know: Should I add your team's App ID to our AASA so engineers can build and test with our domain? Or would you prefer a TestFlight build? (Please provide an email address for external tester access) How should I submit the materials — to FB21797091 or another method? Thank you.

Thank you, Albert. I have already filed this issue as FB21797091 at the beginning of this thread. I have now added additional diagnostic information to that existing report, including: Detailed swcutil_show.txt comparison between IDN and ASCII domains Entitlement configurations tested over 3 years Testing timeline across iOS 16, 17, and 18 Please reference FB21797091 for the complete bug report. Thank you for your assistance in escalating this issue.

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: URL-Encoded Decoded (Japanese) Meaning %E3%81%AE%E4%BB%95%E4%BA%8B の仕事 "jobs" %E9%9A%9C%E3%81%8C%E3%81%84%E8%80%85%E6%8E%A1%E7%94%A8 障がい者採用 "disability employment" 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: swcd stores the domain in Unicode form (求人ボックス.com) swcd never attempts to fetch the AASA (no Last Checked timestamp) 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: Entitlements Format Result Punycode only (xn--pckua2a7gp15o89zb.com) Universal Links not working Unicode + Punycode (both domains) Universal Links not working Unicode only (求人ボックス.com) Universal Links not working 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: The AASA is correctly hosted and synced to Apple's CDN ASCII domains work correctly on the same app/device 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.

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: The IDN domain shows Site/Fmwk Approval: unspecified while the ASCII domain shows approved. The IDN domain has no Last Checked timestamp, suggesting that swcd has never attempted to verify the AASA for this domain. The IDN domain has no Patterns registered, while the ASCII domain has patterns correctly populated. 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.