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.

Hello, I would like to clarify how link association and app-opening preferences work in iOS, specifically when a user opens a URL in a browser that can be handled by an installed application. I have noticed the following behavior: When a user taps a URL that can be opened by an app, iOS sometimes asks whether to open the link in the app or continue in the browser. After choosing an option once (for example, "Open in App" or "Stay in Browser"), it seems that this preference becomes persistent. Even after deleting the application and reinstalling it, the browser (Safari or third-party browsers) sometimes continues to open the link directly in the browser without asking the user again. In some cases, it appears impossible to reset or clear this association, and the user is not prompted again to choose how the link should be opened. My questions are: How exactly does iOS store link-handling preferences between apps and browsers? Are these preferences saved on the system level, inside Safari, or associated with the app installation itself? Is there a way for a user to manually reset or clear these link-opening associations? Should deleting and reinstalling the app reset these preferences, or is the behavior expected to persist? Is this behavior different for Universal Links, App Clips, or for regular URL scheme associations? This situation is important for us because it affects user experience, and at the moment it is difficult to understand or reproduce the internal logic behind these link associations. Thank you in advance for your clarification.

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.

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.

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.

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)

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.

I recently started a new app that supports universal links. I noticed an error in the apple-app-site-association (AASA) file and updated it. I used mode=developer in the applinks configuration, and it works well on Simulator, but for the life of me I can't get my device to load the new file, and the CDN hasn't updated in days. Any suggestions for how to get it to update, or get iOS to load the file directly? mode=developer is supposed to do this, but it simply won't on device. I've tried touching the file, and I can see its reported HTTP last modification date and eTag have changed. I've tried deleting and reinstalling the app; I've tried restarting the phone; I've tried clean builds; I've tried changing the applinks: to something else and reinstalling; I've tried installing via TestFlight.

Issue with Universal Links and App Extension (ShieldAction Handler) I'm currently working on a POC app using the FamilyControls framework and facing an issue when trying to open a Universal Link from an app extension, specifically from a ShieldAction handler. When I try to open a Universal Link, I encounter the following error: Failed to open URL https://sixteen-server-c008110f8759.herokuapp.com/.well-known/apple-app-site-association: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open 'com.apple.mobilesafari' failed." UserInfo={BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x14f2d90b0 {Error Domain=FBSOpenApplicationErrorDomain Code=3 "Application com.sixteen.life is neither visible nor entitled, so may not perform un-trusted user actions." UserInfo={BSErrorCodeDescription=Security, NSLocalizedFailureReason=Application com.sixteen.life is neither visible nor entitled, so may not perform un-trusted user actions.}} Context: I’m using a ShieldAction handler as part of an App Extension to trigger the action (e.g., "Break in Shield") in my app. The app extension (ShieldAction handler) is responsible for trying to open the Universal Link. I’m encountering the error because the app is not visible or entitled to perform this action, which seems to be related to security restrictions when using App Extensions. Questions: App Extension and Universal Link Interaction: Is it possible for an App Extension (like ShieldAction handler) to open a Universal Link or trigger an external app, such as Safari, even though it is not the foreground app? Entitlements for App Extensions: Are there any specific entitlements or permissions required to allow an app extension (ShieldAction handler) to open Universal Links or perform actions like opening Safari from the background? App Visibility and State: How can I ensure that my app is in the right state (visible/active) and has the necessary entitlements to trigger these actions when running in the context of an app extension? Workaround: If this behavior is restricted due to app extension limitations, what would be the recommended workaround to handle launching external apps (like Safari) or Universal Links from within an app extension?