Hello, I’m encountering an issue with Universal Links in my iOS app. After some investigation, I found that the root cause seems to be that Apple’s request through there CDN server to access the .well-known/apple-app-site-association file is blocked by our firewall, which enforces geographic access restrictions as part of our security policy. Because of this restriction, Apple’s validation or link verification requests are being denied, and the Universal Links are not working as expected. I’d like to get some guidance from the community or Apple engineers on the following: 1. Does Apple provide an official list of IP ranges or domains that need to be allowed through the firewall for Universal Link validation? 2. Are there alternative methods to handle Universal Link verification in environments with geographic restrictions? 3. Would whitelisting specific Apple services or endpoints be a recommended or safe solution? Any input or recommendations would be greatly appreciated. Environment Details: • iOS app using Universal Links • Server protected by a firewall with regional restrictions • AASA file hosted correctly and accessible via browser Thanks in advance for your help and insights.

My app has been published by 2 months now I still I cant get Universal Links to work. I checked a lot of docs as well as videos about setting up universal links. Everyone with clear steps: Add the well-known json file to the server. Already validated by AASA web validator. Add the Associated domain on project capabilities, with the Web page root only. Eg: applinks:example:com. Install the app and trying clicking a link from notepad. Or instead make a long press to deploy contextual menu to see if my app is on the selectable options to open the link. My app is not been open in any of my attempts and the console always trying to use safari. I had a couple of screenshots of my testing. I really need help with this.

Original discussion pre iOS 26 Our app uses Auth0 with HTTPS callback, we've found the issue where AASA file is not ready immediately when app is initially launched, which is the exact issue from the above link. The issue seems mostly fixed on later versions on iOS 18, however, we are seeing some indications of a regression on iOS 26. Here's some measurement over the last week. | Platform | iOS 18 | iOS 26 | |---------------|----------|--------| | Adoption rate | 55% | 45% | | Issue seen | 1 | 5 | | Recover? | Yes | No | This only 1 iOS 18 instance was able to recover after 1 second after the first try, however, all iOS 26 instances were not able to recover in couple tens of seconds and less than 1 minute, the user eventually gave up. Is there a way to force app to update AASA file? Are there some iOS setting (like using a VPN) that could potentially downgrade the AASA fetch? Related Auth0 discussion: https://community.auth0.com/t/ios-application-not- recognizing-auth0-associated-domain/134847/27

Hi Everyone, When we first hosted our apple-app-site-association file, our hosting provider was unintentionally blocking Apple’s crawler. As a result, Apple’s CDN seems to have cached a timeout / missing file response. We’ve since corrected the issue — the AASA file is now valid and accessible at: https://our-domain.com/.well-known/apple-app-site-association sidenote: I am using "our-domain" as an alias. It is not our actual domain. We have verified that we return a valid JSON, HTTPS 200, correct MIME type. We used apple recommended tools to check this as well as other tools we found on the internet. However, when fetching through the Apple CDN: https://app-site-association.cdn-apple.com/a/v1/our-domain.com we still receive: Apple-Failure-Reason: SWCERR00301 Timeout Apple-Failure-Details: {"cause":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"} This has persisted for several days. Tools like getuniversal.link and yURL show that the CDN works fine in U.S. regions, but in Europe it continues serving the old timeout response. I’ve already opened a support ticket (Case ID: 102734912696), but the current support channel seems to be general developer account assistance rather than technical. They claim they can only assist us with account related issues (even though I used the code-support form...) Can someone please advise or help us escalate this to the appropriate internal team to refresh the Apple CDN cache for our domain? Thank you so much for your time and help.

~5% of our users when downloading the iOS application from the Apple Store for the first time are unable to enrol a Passkey and experience an error saying the application is not associated with [DOMAIN]. The error message thrown by the iOS credentials API is "The operation couldn't be completed. Application with identifier [APPID] is not associated with domain [DOMAIN]" We have raised this via the developer support portal with case id: 102315543678 Question: Why does the AASA file fail to fetch on app install and is there anything that can be done to force the app to fetch the file? Can this bug be looked at urgently as it is impacting security critical functionality? Other Debugging Observations We have confirmed that our AASA file is correctly formatted and hosted on the Apple CDN. Under normal circumstances the association is created on install and Passkey enrolment works as intended. We have observed that when customers uninstall/reinstall the app this often, but not always, resolves the issue. We also know this issue can resolve itself overtime without any intervention. We have ruled out network (e.g VPN) issues and have reproduced the issue across a number of different network configurations. We have ruled out the Keychain provider and have reproduced it across a variety of different providers and combinations of. We observed this across multiple versions of the iOS operating system and iPhone hardware including the latest hardware and iOS version.

Hello, When using ASWebAuthenticationSession with an HTTPS callback URL (Universal Link), I receive the following error: Authorization error: The operation couldn't be completed. Application with identifier jp.xxxx.yyyy.dev is not associated with domain xxxx-example.go.link. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for xxxx-example.go.link. I checked Apple’s official documentation but couldn’t find any clear statement that webcredentials is required when using HTTPS callbacks in ASWebAuthenticationSession. What I’d like to confirm: Is webcredentials officially required when using HTTPS as a callback URL with ASWebAuthenticationSession? If so, is there any official documentation or technical note that states this requirement? Environment iOS 18.6.2 Xcode 16.4 Any clarification or official references would be greatly appreciated. Thank you.

Hello, we are experiencing an issue that is not systematic regarding universal links on our application. In some cases, after the application is installed, the universal links do not open the application but instead open in Safari. We have conducted tests on several devices and with the same link. In some cases, the links open the application after installation, and in other cases, they open in Safari. I should mention that in all test cases, we did not force the opening via the menu accessible through a long press on the link. We performed sysdiagnose in the different cases and we observed the same configuration for the universal links in the swcutil_show.txt file: User Approval: unspecified Site/Fmwk Approval: approved At this stage, I do not think the problem comes from our application or the configuration of the apple-app-site-association file. Is this a known issue? Is there anything we can do on our side to work around it ?

Foreword: I filed a feedback a week ago and so far no one replied or at least acknowledged my feedback. That's why I'm writing here now to get some more attention (hopefully, thanks). I recorded a video to show you what exactly is happening. I am not sure where the issue belongs to exactly but it is related to associated domains, the camera (QR codes), the NFC module, App Intents and Control Center controls. https://youtu.be/sT2bZLs_6rA FB20418059 (I added some tags that are somehow related to the associated domain issue)

I have published the app on the App Store along with its corresponding app clip, my app clip is configured with some advanced experiences for each one of my clients, but whenever some users try to scan an NFC or QR Code they see the card rendering correctly with their configured banner image, but with the message "App Clip Unavailable". The weird thing is that both iMessage and the website to which the associated domain is set and the apple-app-site-association is stored, renders the banner or card correctly, and when the users tap the banner or card they open the advanced app clip experience correctly without any issue. I have attempted to troubleshoot the issue by checking the following: if the app clip is below 15MB if we are using a second level domain in my associated domain both for my app clip and app (excluding the www subdomain). checking if the AASA is correctly stored inside .well-known directory checking the configuration for the advanced experience I opened a case: 102233443873, and added a bunch of videos and screenshot showcasing the issue, but I have not yet received a reply

Dear Apple Support, We are encountering an issue with deep linking on iOS 26 when using Safari and App Store redirection. Below are the detailed steps to reproduce the problem: The app is not installed on the device. User clicks on a Branch link: For example:- https://qewed.app.link/99u88ef9f?uuid=88dbwh5ubd4b Safari opens and displays the fallback page. User taps on “Get the App”, which navigates to the App Store. User installs and opens the app. Expected Behavior:
The app should receive the Branch link parameters (in this case, uuid=88dbwh5ubd4b) upon first open. Actual Behavior:
The app opens successfully, but the uuid parameter is not passed to the app. This issue seems specific to the Safari → App Store → App flow on iOS 26, as other flows behave correctly. Could you please advise whether this is a known issue or if there are recommended adjustments on our side to ensure parameters are consistently delivered after App Store redirection? Note: We are using Branch SDK version 3.11.0 (Cocoapods dependency) Thank you for your assistance.

Hello Having trouble getting associated domain to work in our project. It was working when we used Branch, but our company wants to host the domain ourselves. This is a multi-scheme project, using .xcconfig files to define the correct entitlement per Build. The relevant entitlement file has: com.apple.developer.associated-domains applinks:bm.ddcas.ai in the ....{other irrelevant test associated domains....} The project Team and App ID are taken from the Identifiers screen where the Identifier capabilities has 'associated domains' ticked on. I've also checked elsewhere on AppleDeveloper/Connect to be sure. When we used Branch with domain key app links: bmstores.app.link this worked fine. With https://bm.ddcas.ai (our own host) which is publicly available and has an aasa file in both the main directory and /.well-known, typing this in safari or anything just doesn't attempt to link to the App. The iPhone is in developer mode, and using the developer menu associated domains diagnostic tool, typing https://bm.ddcas.ai results in the diagnostic saying 'The url is a Universal Link for the app with identifier **********.***etc (the app is installed on real iPhone 12, iOS 18.6.2 and my Xcode is 16.4) However, it just doesn't work if we type in https://bm.ddcas.ai and results in a Safari message of '400 not found' and the 'nginx' shows. We have read innumerable Apple Dev posts and StackOverflow posts, as well as several step by step 'how to's' online but this just isn't working. The aasa file is at https://bm.ddcas.ai/apple-app-site-association and is setup as follows: { "applinks": { "apps": [], "details": [ { "appID": "{my Team ID}.{my App ID}", "paths": [ "*" ], "components": [ { "/": "/verification", "?": { "verification_code": "[A-Za-z0-9]{6}" }, "comment": "Matches verification code path" } ] } ] } } Our Server guys say the website (bm.ddcas.ai) is public and hosted, it just doesn't have a /verification path as they say it should redirect before reaching that. Also, our Android redirect works using this site, so this appears to be something specific Apple code is looking for. What, please, are we likely to be missing as it does not seem obvious from the Apple documentation or any of the resources I have checked online. Normally we can figure anything out, but getting nowhere here so the help is appreciated.

Hi all, Pretty new here, so please remember when you were trying hard. I am creating an IOS app that will generate a link where you have a room-id and a unique id. This will be sent (normal sms. email, copy/paste values etc) to another user. If the person receiving the link does not have the app installed, I would like it to go to the app store for download, however the app is currently not finished and therefore I can't provide a proper link. How do you deal with that? Thanks in advance

Hello, I'm developing a feature for my app, that allows users to challenge their friends. The friend request functionality is built using Universal Links, but I've run into a significant issue. The Universal Links are correctly deep-linking into the app. However, once the app opens, nothing happens—the friend request acceptance or rejection flow does not occur. This prevents users from completing friend requests and building their friend list. Here are examples of the Universal Links I'm generating: https://www.strike-force.app/invite?type=invite&userID=... https://www.strike-force.app/invite?type=invite&friendRequestID=... https://www.strike-force.app/profile?userID=... I've recently updated my cloudflare-worker.js to serve a paths array of ["*"] in the AASA file, so I believe the links themselves should be valid. Technical Details & Error Logs In the console, I am consistently seeing the following error message: Cannot issue sandbox extension for URL:https://www.strike-force.app/invite?token=7EF1E439-090B-4DF2-BE64-9904F50A3F8B Received port for identifier response: <(null)> with error:Error Domain=RBSServiceErrorDomain Code=1 "Client not entitled" UserInfo={RBSEntitlement=com.apple.runningboard.process-state, NSLocalizedFailureReason=Client not entitled, RBSPermanent=false} elapsedCPUTimeForFrontBoard couldn't generate a task port This error appears to be related to entitlements and process state, but I am not sure if it's the root cause of the Universal Link issue or a separate problem. The 'Client not entitled' error on line 3 has had me chasing down entitlements issues. But, I've added the Associated Domains entitlement with the proper applink URLs and verified this in my Developer Portal. I've regenerated my provisioning profile, manually installed it, and selected/de-selected Automatically Manage Signing. As well I've verified my AASA file and it's correctly being served via HTTPS and returning a 200. curl -i https://strike-force.app/.well-known/apple-app-site-association curl -i https://www.strike-force.app/.well-known/apple-app-site-association I am looking for guidance on why the friend request flow is not being triggered after a successful deep-link and how I can fix the related error. Any insights or suggestions would be greatly appreciated.

From some moment of time, Universal Links stopped working for our app. As per my understanding, application reinstall or update caused system to fetch AASA file from CDN, which started to reply with 404 for our domain (https://app-site-association.cdn-apple.com/a/v1/app.link.digidentity.eu). In the meantime, nothing has changed inside our app or on our BE (https://app.link.digidentity.eu/.well-known/apple-app-site-association). Executing "curl -v https://app-site-association.cdn-apple.com/a/v1/app.link.digidentity.eu" returns following result * IPv6: (none) * IPv4: 17.253.15.197, 17.253.29.202, 17.253.37.203, 17.253.37.208, 17.253.57.197, 17.253.57.208, 17.253.29.196 * Trying 17.253.15.197:443... * Connected to app-site-association.cdn-apple.com (17.253.15.197) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF * ALPN: server accepted http/1.1 * Server certificate: * subject: C=US; ST=California; O=Apple Inc.; CN=app-site-association.cdn-apple.com * start date: Jul 7 00:05:26 2025 GMT * expire date: Sep 30 19:08:48 2025 GMT * subjectAltName: host "app-site-association.cdn-apple.com" matched cert's "app-site-association.cdn-apple.com" * issuer: CN=Apple Public Server ECC CA 11 - G1; O=Apple Inc.; ST=California; C=US * SSL certificate verify ok. * using HTTP/1.x > GET /a/v1/app.link.digidentity.eu HTTP/1.1 > Host: app-site-association.cdn-apple.com > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off < HTTP/1.1 404 Not Found < Apple-Failure-Details: {"cause":"dial tcp: lookup app.link.digidentity.eu on 10.100.53.53:53: dial tcp 10.100.53.53:53: connect: connection refused"} < Apple-Failure-Reason: SWCERR00302 Network error (temporary) < Apple-From: https://app.link.digidentity.eu/.well-known/apple-app-site-association < Apple-Try-Direct: true < Cache-Control: max-age=3600,public < Content-Length: 10 < Content-Type: text/plain; charset=utf-8 < Date: Thu, 21 Aug 2025 10:36:47 GMT < Vary: Accept-Encoding < Expires: Thu, 21 Aug 2025 10:36:57 GMT < Age: 2952 < Via: http/1.1 uklon5-vp-vst-011.ts.apple.com (acdn/1.16221), https/1.1 uklon5-vp-vfe-007.ts.apple.com (acdn/4.16219), http/1.1 defra1-edge-lx-005.ts.apple.com (acdn/260.16276), http/1.1 defra1-edge-bx-006.ts.apple.com (acdn/260.16276) < X-Cache: hit-fresh, hit-stale, hit-fresh, hit-fresh < CDNUUID: e06b4b03-f97d-48f8-97bb-774359a39fa2-4464142837 < Connection: keep-alive < Not Found * Connection #0 to host app-site-association.cdn-apple.com left intact On our end, we did not find any reason why it can be not available for Apple to fetch. Is SWCERR00302 an indication of problem on our end? Any help is appreciated

I have a public and accessible .well-known/apple-app-site-association file for both my domain.com and subdomain.domain.com with "paths": ["*"] . Both example.com and blog.example.com are added in Associated domains and any link that contains domain.com and domain.com/path normally deep links into my app. I used to have an *.example.com that successfully deep linked all my subdomains into my app but now I had to remove it as some subdomains will need to link to other apps, but some should still link to the same app. I removed * but left blog.example.com as that specific subdomain still needs to deep link into my app. But now blog.example.com is not even being recognized by my app and any link starting with blog.example.com just opens in safari. What am I missing? Why is this happening ?

Hi Apple Devs, For our app, we utilize passkeys for account creation (not MFA). This is mainly for user privacy, as there is 0 PII associated with passkey account creation, but it additionally also satisfies the 4.8: Login Services requirement for the App Store. However, we're getting blocked in Apple Review. Because the AASA does not get fetched immediately upon app install, the reviewers are not able to create an account immediately via passkeys, and then they reject the build. I'm optimistic I can mitigate the above. But even if we pass Apple Review, this is a pretty catastrophic issue for user security and experience. There are reports that 5% of users cannot create passkeys immediately (https://developer.apple.com/forums/thread/756740). That is a nontrivial amount of users, and this large of an amount distorts how app developers design onboarding and authentication flows towards less secure experiences: App developers are incentivized to not require MFA setup on account creation because requiring it causes significant churn, which is bad for user security. If they continue with it anyways, for mitigation, developers are essentially forced to add in copy into their app saying something along the lines of "We have no ability to force Apple to fetch the config required to continue sign up, so try again in a few minutes, you'll just have to wait." You can't even implement a fallback method. There's no way to check if the AASA is available before launching the ASAuthorizationController so you can't mitigate a portion of users encountering an error!! Any app that wants to use the PRF extension to encrypt core functionality (again, good for user privacy) simply cannot exist because the app simply does not work for an unspecified amount of time for a nontrivial portion of users. It feels like a. Apple should provide a syscall API that we can call to force SWCD to verify the AASA or b. implement a config based on package name for the app store such that the installation will immediately include a verified AASA from Apple's CDN. Flicking the config on would require talking with Apple. If this existed, this entire class of error would go away. It feels pretty shocking that there isn't a mitigation in place for this already given that it incentivizes app developers to pursue strictly less secure and less private authentication practices.

I have been using Universal Links since January of this year. As of January, it was working fine, but when I checked its operation in August, it was no longer working properly. After investigating, I believe that the reason it is not working is because our firewall is blocking communication from AppleCDN to check for AASA files. Our firewall blocks communication from outside Japan, and Apple's IP address (17.0.0.0/8) is whitelisted. Does anyone know the hostname or IP address that is used to check AASA files? If you know, please let me know.

Problem Description: In our App, When we launch the web login part using ASWebAuthentication + Universal Links with callback scheme as "https", we are not receiving callback. Note: We are using "SwiftUIWebAuthentication" Swift Package Manager to display page in ASWebAuth. But when we use custom url scheme instead of Universal link, app able to receive call back every time. We use ".onOpenURL" to receive universal link callback scheme.

Hi all, I'm trying to set up universal links for my app but it's not working. What I want: cogover.com → Safari (website) - NOT my app *.cogover.com (any subdomain like abc.cogover.com) → My app What I did: Added applinks:*.cogover.com in Xcode Put AASA files on all subdomains They work fine (checked with curl) Problem: All links still open in Safari, not my app. I do not put AASA on my root domain cogover.com because I don't want open my app with root domain. I have checked TN3155: Debugging universal links | Apple Developer Documentation but it only say about universal link works with both root domain and subdomains. Weird thing I found: I checked how Salesforce does it - their *.force.com subdomains work perfectly. But when I tried to check their setup, (https://force.com/.well-known/apple-app-site-association) doesn't seem to exist either! So how does theirs work? Even stranger - Apple's CDN has their file cached at (https://app-site-association.cdn-apple.com/a/v1/force.com) but the actual domain doesn't serve it. Can Apple's CDN have a file cached even if it's not on the website anymore? Thanks for any help!

(1) Context: Our project has a login feature via WEBVIEW (using SFSafariViewController) and integrates PassKey on the Web side. The app listens for a successful login by capturing the redirect URL via the delegate of SFSafariViewController. (2) Issue: On iOS &lt; 18.4: The redirect URL is captured with full parameters returned. https://xyz.com/home?session_state=...&amp;code=... On iOS ≥ 18.4: The redirect URL is captured successfully but missing parameters. https://xyz.com/home We currently suspect that the issue originates from the SFSafariViewController framework after the release of iOS 18.4. Has anyone experienced a similar issue? We would also appreciate support from the Apple team.