Universal Links

RSS for tag

Allow your users to intelligently follow links to content in your app or to your website using universal links.

Posts under Universal Links tag

200 Posts

Post

Replies

Boosts

Views

Activity

Default App Clip URL (appclip.apple.com) shows website preview instead of triggering App Clip card
We have a published, approved App Clip that works correctly via QR code and the Safari Smart App Banner, but URL-based invocation does not trigger the App Clip card in any context. Most notably, Apple's own default App Clip URL does not work either: https://appclip.apple.com/id?p=hazel-torus.Clip **Tapping this link in Messages or Notes does nothing. ** Long-pressing it shows a generic website link preview rather than the App Clip card, even though appclip.apple.com is Apple's domain and requires no configuration on our end. Setup details: App Clip bundle ID: hazel-torus.Clip Team ID: 2UNR2APH47 App Clip experience URL: https://passportreader.app/open AASA includes a correctly formatted appclips key with 2UNR2APH47.hazel-torus.Clip (confirmed via https://app-site-association.cdn-apple.com/a/v1/passportreader.app that AASA is correctly cached) Associated Domains entitlements (appclips:passportreader.app) are present on the App Clip target App and App Clip experience are both Approved / Ready for Sale Tested on two physical devices, neither with the full app installed Since QR and Safari banner invocation work, the App Clip itself and its entitlements appear correctly configured. The fact that even Apple's own appclip.apple.com URL fails, and is treated as an arbitrary website link, suggests this may be a backend indexing issue specific to this App Clip rather than a client-side configuration problem. Has anyone else encountered this, or know what could cause appclip.apple.com to not be recognized as an App Clip URL?
23
0
1.5k
3d
AASA CDN intermittently times out / requests wrong path (/apple-app-site-association vs /.well-known/...)
Hi Everyone, We are tinkering on an App using associated domains with the working name "uff2.de". We have configured our Webserver (Caddy) to restrict all URIs except for /.well-known/apple-app-site-association using Www-Authenticate. Recently our associated domains started becoming flaky, which we believe has to do with requests from Apple’s CDN failing: The following example uses a query string to trigger a fresh request by Apple’s CDN. curl -sD - "https://app-site-association.cdn-apple.com/a/v1/uff2.de?foobar" -o /dev/null HTTP/1.1 404 Not Found Server: AppleHttpServer/7b3d349ae60c243cdd677edbde3e93e460f75820 Date: Sat, 05 Sep 2026 12:01:16 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection timed out"} Apple-Failure-Reason: SWCERR00301 Timeout Apple-From: https://uff2.de/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: 457b6172513a930f Strict-Transport-Security: max-age=31536000 Age: 32 Via: https/1.1 defra2-vp-vst-018.ts.apple.com (acdn/331.16659), https/1.1 defra2-vp-vfe-016.ts.apple.com (acdn/331.16659), https/1.1 gbslo5-xdc-mx-020.ts.apple.com (acdn/331.16659), https/1.1 uklon5-edge-fx-024.ts.apple.com (acdn/331.16659) X-Cache: miss, miss, miss, miss CDNUUID: df5ac203-4188-4722-8bbc-68e9d9fd0b33-1118024500 Connection: keep-alive To investigate this further we enabled access logging and are seeing the following request that is blocked by us: 2026/09/05 12:01:16.824 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.82.202", "remote_port": "48366", "client_ip": "57.103.82.202", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000083782, "size": 0, "status": 401, "resp_headers": {"Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Www-Authenticate": ["Basic realm=\"restricted\""]}} But this seems to be the wrong URI (/apple-app-site-association instead of /.well-known/apple-app-site-association). When swapping ?foobar for other query strings like ?foobar2 or ?foobar3, some requests randomly work and some don’t. We’re also seeing flakiness for the same path (both with and without a query string) across time, but this is harder to test due to caching. For reference this is a correct request: 2026/09/05 17:54:26.075 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.81.17", "remote_port": "8692", "client_ip": "57.103.81.17", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/.well-known/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000088472, "size": 469, "status": 200, "resp_headers": {"Accept-Ranges": ["bytes"], "Content-Length": ["469"], "Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Vary": ["Accept-Encoding"], "Etag": ["\"dgrdbiykgv3ad1\""], "Content-Type": [], "Last-Modified": ["Sun, 01 Mar 2026 10:19:41 GMT"]}} Did we misread the documentation and should also serve /apple-app-site-association? Why would requests sometimes be made to /.well-known/apple-app-site-association and sometimes to /apple-app-site-association? Thank you!
10
1
236
6d
App Clip card appears when full app is installed + duplicate card on open
Hi team, We're experiencing two issues with our App Clip invocation via appclip.apple.com links. Setup: App Clip URL: https://appclip.apple.com/id?p=com.x.AppClip The App Clip card and experience work correctly when the full app is NOT installed ✅ Issue 1: App Clip card shown even when the full app is installed When the full app is already installed on the device, tapping the App Clip link shows the App Clip card instead of directly opening the full app. After tapping "Open" on the card, the full app launches — but then the App Clip card appears again on top of the app, requiring the user to dismiss it a second time. Expected behavior: If the full app is installed, tapping the App Clip link should bypass the App Clip card entirely and open the full app directly, routing to the correct screen using the URL parameters. Actual behavior: User taps App Clip link → App Clip card appears (should not appear if app is installed) User taps "Open" on the card → Full app launches App Clip card appears again on top of the full app → User has to dismiss it manually This results in unnecessary friction — two extra taps just to get into the app. Issue 2: Full app does not route to the correct screen When the full app eventually opens (after dismissing the cards), it opens to the default home screen rather than routing to the screen specified by the parameter in the URL. Expected behavior: The full app should handle the URL parameters and navigate to the appropriate screen. Actual behavior: The full app opens to its default/home screen, ignoring the url parameter. Questions: Is this expected behavior that appclip.apple.com links always show the App Clip card even when the full app is installed? If so, is there a recommended approach to bypass the card and open the app directly? What is causing the duplicate App Clip card after tapping "Open"? Is this a known issue, or is there something in our configuration that could be triggering it? For the full-app-installed case, what is the recommended way to handle deep linking from an appclip.apple.com URL into a specific screen in the full app? Should we be handling this via NSUserActivity, UIApplicationDelegate, or a Universal Link handler? Environment: iOS 26.x Xcode 26.x App Clip configured with appclips associated domain Full app and App Clip share the same App ID prefix Any guidance would be greatly appreciated. Thanks!
1
0
530
1w
Universal Links not working even though all debug steps succeed
I am trying to get universal links to work in our app Firefox iOS The Problem: I am not able to get universal links to work for our release app or beta app scheme locally or with a TestFlight build. I am able to get it working on our development scheme with a locally hosted app site association file. I also was able to get it working using our development scheme but setting the bundle id to the release app bundle id. I also built a demo app with the release app id and the release app development certificate. It succeeded there as well. Implementation Steps: Added associated domains entitlement to the production and beta schemes for our main app target (No associated domains entitlements or capabilities added for any extensions) Confirmed that the bundle ids associated with these schemes have the associated domains capability Added applinks:blog.mozilla.org to associated domains list Confirmed in code that user activities are being handled via SceneDelegate.swift Steps to Debug: I have gone through and validated every step in the provided Universal Link Debugging. All were successful: Associated Domains Development -> Diagnostics: Opens Installed App Validate AASA host and applinks match curl -v https://blog.mozilla.org/.well-known/apple-app-site-association returns the expected json file swcutil dl correctly downloads the AASA blob swcutil verify succeeds I have inspected the IPA of our beta build and confirmed the App ID and the associated domains is an entitlement. I have looked at the console logs filtering by swcd. I am not seeing any errors and I see the download for the AASA file kick off: Beginning data task AASA-4BABF039-3C69-4E36-AA4E-ECCDF3D14878 { domain: bl….mo….org, bytes: 0, route: cdn } There is only one error that appears in the console but our app is not enterprise-managed so I assume this is normal. Error getting enterprise-managed associated domains data. If this device is not enterprise-managed, this is normal: Error Domain=SWCErrorDomain Code=1701 "Failed to get associated domain data from ManagedConfiguration framework." UserInfo={NSDebugDescription=Failed to get associated domain data from ManagedConfiguration framework., Line=298, Function=<private>} I have run Sysdiagnos and identified for our App ID: Site/Fmwk Approval: approved I am at a loss as to what is preventing universal links from working even though all validation steps pass.
4
0
1.5k
2w
Bug: Correct ASSA File not fetched
How does iOS handle Associated Domains and AASA files when switching between environments? I have an iOS application that supports multiple environments (test and production). Each environment has its own domain and its own AASA file. We have an SDK that requires a domain during initialization. Based on the selected environment, we initialize the SDK with either the test domain or the production domain. We have configured the Associated Domains capability in Xcode with the required domains. However, i'm unclear about how iOS manages the AASA association in this scenario. For example: test.example.com Has its own AASA file. Used when the SDK is initialized with the test domain. example.com Has its own AASA file. Used when the SDK is initialized with the production domain. The SDK receives the domain during initialization, and we dynamically select the domain based on the environment configuration. The question is: If multiple domains are configured in Associated Domains, does iOS fetch and cache the AASA file for all configured domains when the app is installed, or only for the domain currently being used by the application? If the application switches the SDK configuration from the test domain to the production domain (or vice versa) after installation, how does iOS know that it needs to fetch the AASA file for the new domain? Is there any supported way to force iOS to re-fetch the AASA file for a newly selected associated domain? Trying to understand the correct approach for supporting multiple environments when the SDK domain is selected dynamically at runtime. If both test and production domains are configured in Associated Domains, how does iOS determine which AASA file should be used when the SDK is initialized with a specific domain (for example, test)? Does iOS fetch and validate both AASA files upfront and then check only the matching domain at runtime, or does it dynamically fetch/check only the domain provided to the SDK?
1
0
360
Aug ’26
Bug: AASA file not fetched on app install
~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.
13
3
3.7k
Aug ’26
Apple CDN returning 404 Not found for our universal Link domain.
Hi Team, Our universal links were working fine but since last week we are facing issues and when tapping the links outside app it takes to browser and not the app. Apple CDN is returning 404 for our domain and not the contents of AASA file. https://app-site-association.cdn-apple.com/a/v1/app.ooredoo.om sudo swcutil dl -d app.ooredoo.om returns The operation couldn’t be completed. (SWCErrorDomain error 7.) Can we get the exact issue apple is facing to cache the AASA file in CDN. Any server config which we need to do for AASA bot to access the file. Thanks in advance.
28
0
2.4k
Aug ’26
Associated Domains webcredentials works with ?mode=developer but fails without it - AASA correctly configured
Hi everyone, We're migrating our iOS app from Auth0 custom scheme callbacks to HTTPS Universal URLs using ASWebAuthenticationSession. We've configured everything correctly, but webcredentials only works when using ?mode=developer suffix in our entitlements, which is not allowed for App Store submissions. The Issue Without ?mode=developer: Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 "Application with identifier com.example.myapp is not associated with domain auth.example.com. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for auth.example.com." With ?mode=developer: webcredentials:auth.example.com?mode=developer Works perfectly! Questions Why does it work with ?mode=developer but not without it, even though Apple's CDN has the correct AASA? Is there a way to force iOS to re-verify associated domains without requiring users to delete and reinstall? How will this affect existing users who update the app? Will they need to reinstall? Is there a known propagation delay beyond the CDN showing correct data? Any guidance would be greatly appreciated. We cannot ship to the App Store with ?mode=developer, but without it, the authentication fails. Thank you!
3
0
1k
Jul ’26
Universal Links failing for some users but working for others
Hi, We are facing an issue where Universal Links are working for most users but failing for some of our clients. For affected users: Links open in Safari instead of the app, or Universal link routing does not work as expected For other users: The same links open the app correctly What we verified Associated Domains capability is configured correctly AASA file is valid and accessible App configuration and bundle ID mapping are correct AASA: https://www.gartner.com/apple-app-site-association Issue Since the problem is only affecting a subset of users, we are unable to: Reproduce the issue consistently Identify when or why the association breaks Ask Has anyone experienced: Universal Links failing only for certain users/devices? What are the possible causes and how can we debug or proactively identify the root cause in such cases? Any guidance would be helpful. Thanks!
9
0
740
Jul ’26
Apple's CDN always returns “not found”
We are testing Apple Universal Links for ios.aierchina.com. The domain is ICP-registered and hosted in mainland China. The problem: Apple's CDN always returns “not found” for our AASA file: https://app-site-association.cdn-apple.com/a/v1/ios.aierchina.com What we have verified: The AASA file is correctly served at both /.well-known/apple-app-site-association and /apple-app-site-association Returns HTTP 200, valid JSON, correct Content-Type, no redirects, valid SSL Server response time is under 500ms What works: Adding ?mode=developer to the applinks entry works perfectly Universal Link Diagnostics on device (ios.aierchina.com/uat) correctly resolves to our app bundle What does not work: Production mode fails because the Apple CDN never caches our AASA file Reinstalling the app does not help Server logs show occasional requests from com.apple.swcd, but CDN still returns 404 Questions: Are there known issues with Apple CDN caching AASA files for China-hosted domains? Is there any way to force Apple's CDN to re-crawl our domain? Could the GFW or regional network policies be interfering? What was the fix?
3
0
1.1k
Jul ’26
https://app-site-association.cdn-apple.com/a/v1/* 404 Not Found
% curl -v https://app-site-association.cdn-apple.com/a/v1/zfcs.bankts.cn Host app-site-association.cdn-apple.com:443 was resolved. IPv6: (none) IPv4: 218.92.226.151, 119.101.148.193, 218.92.226.6, 115.152.217.3 Trying 218.92.226.151:443... Connected to app-site-association.cdn-apple.com (218.92.226.151) 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-AES256-GCM-SHA384 / [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: Sep 25 13:58:08 2025 GMT expire date: Mar 31 17:44:25 2026 GMT subjectAltName: host "app-site-association.cdn-apple.com" matched cert's "app-site-association.cdn-apple.com" issuer: CN=Apple Public Server RSA CA 11 - G1; O=Apple Inc.; ST=California; C=US SSL certificate verify ok. using HTTP/1.x GET /a/v1/zfcs.bankts.cn 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 < Content-Type: text/plain; charset=utf-8 < Content-Length: 10 < Connection: keep-alive < Server: nginx < Date: Wed, 04 Feb 2026 02:26:00 GMT < Expires: Wed, 04 Feb 2026 02:26:10 GMT < Age: 24 < Apple-Failure-Details: {"cause":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"} < Apple-Failure-Reason: SWCERR00301 Timeout < Apple-From: https://zfcs.bankts.cn/.well-known/apple-app-site-association < Apple-Try-Direct: true < Vary: Accept-Encoding < Via: https/1.1 jptyo12-3p-pst-003.ts.apple.com (acdn/3.16363), http/1.1 jptyo12-3p-pac-043.ts.apple.com (acdn/3.16363), https/1.1 jptyo12-3p-pfe-002.ts.apple.com (acdn/3.16363) < X-Cache: MISS KS-CLOUD < CDNUUID: 736dc646-57fb-43c9-aa0d-eedad3a534f8-1154605242 < x-link-via: yancmp83:443;xmmp02:443;fzct321:443; < x-b2f-cs-cache: no-cache < X-Cache-Status: MISS from KS-CLOUD-FZ-CT-321-35 < X-Cache-Status: MISS from KS-CLOUD-XM-MP-02-16 < X-Cache-Status: MISS from KS-CLOUD-YANC-MP-83-15 < X-KSC-Request-ID: c4a640c815640ee93c263a357ee919d6 < CDN-Server: KSFTF < X-Cdn-Request-ID: c4a640c815640ee93c263a357ee919d6 < Not Found Connection #0 to host app-site-association.cdn-apple.com left intact
2
0
637
Jul ’26
QR code scan deeplink not work in XCode test run?
Hi, I'm trying to figure out what is true here - if I am not in the correct forum please direct me :-) A. It is not possible to test a QR code scan that contains a deeplink into my iOS app from an XCoode build test run. In other words, The build must be published to Test Flight for the iOS's QR code scan sub-system to be able to process the deeplink into my app? If I am wrong about this, it sure would help with testing to be able to test directly from the local XCode build test. If so, can someone point me in the direction of what I would need to do for that? Thanks for your input either way!
1
0
783
Jul ’26
app-site-association.cdn-apple.com | Cache not updating
We're handling our universal links (deep links) via our custom router written in express.js. We recently update our .well-known format as per: https://developer.apple.com/documentation/xcode/supporting-associated-domains Our own domain link shows them correctly if we apply cache bust to it: Normal link: https://links.sastaticket.pk/.well-known/apple-app-site-association Cache bust: https://links.sastaticket.pk/.well-known/apple-app-site-association?1 Now, since app-site cache is not updating at: https://app-site-association.cdn-apple.com/a/v1/links.sastaticket.pk Our main domain link is not getting updated response either. Its been more than 72 hours now. Any help, how to push the app-site cache to update? I can provide more context if needed, Thanks
2
0
1.3k
Jul ’26
Using wildcard for applinks in iOS stopped working
Hi everyone, I've been working on an application that provides different subdomains for different customers, so we need to support app linking with all of them. However, using wildcard notation like applinks:*.domain.com doesn't work, while hardcoding applinks:subdomain.domain.com works fine. The association file is being served from both the main domain and subdomains. It used to work fine about a month ago, and I can't find any recent breaking changes on Apple's side . Any ideas why this could happen. ?
4
0
1.4k
Jul ’26
Applinks for any subdomain not opening the app
My Entitlements file contains the following (removed some non related entries): <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.associated-domains</key> <array> <string>webcredentials:app.mydomain.org</string> <string>applinks:*.mydomain.org</string> </array> </dict> </plist> Now when I tap on a link such as abc.mydomain.org, the app is not opened. If I change the generic applinks key from *.mydomain.org to a specific domain, this works correctly and it opens the app as expected. (This makes me think the website part of the AASA file is correct). Since I need to support a lot of subdomains (think about hundreds in the near future), I really need the wildcard to work. Do you have any tips on how to make this work?
1
0
658
Jul ’26
AASA file on CDN not found more than one week
Last week our Universal Links stopped working. We made some changes and uploaded a new AASA file, but https://app-site-association.cdn-apple.com/a/v1/(domain) still returns 404 Not Found for all our domains. When I query directly from our server like domain/.well-known/apple-app-site-association, it returns 200 and the file is accessible. Could you help us resolve this issue? Our app relies on working Universal Links (deep links). Thank you!
1
0
489
Jul ’26
iOS Universal Link opens app and then opens browser (Flutter + Universal Links) — only when using paths/params
Hi everyone, I’ve been stuck on an issue with iOS Universal Links for about a week and could really use some help. The problem When tapping a Universal Link on iOS, my Flutter app opens correctly (desired behavior) — but immediately afterward, Safari opens the same link in the browser. So both the app and the browser open. This only happens on iOS. On Android everything works as expected. What works If the link is simply the domain, like: https://mydomain.com …then the app opens without triggering the browser afterward. This is the correct behavior. What doesn’t work If the link includes a path or parameters, like: https://mydomain.com/path https://mydomain.com/path?param=value …then the app opens, and then the browser opens immediately after. What I’ve tried Verified my AASA file using Branch’s validator: https://branch.io/resources/aasa-validator/ → The AASA file is valid. Universal Links do open the correct screen inside the app — the issue is the unwanted second step (Safari opening). Behavior is consistent across different iOS devices. Extra details Using Flutter. Universal Links set up with the standard configuration (associatedDomains, AASA hosted at /.well-known/apple-app-site-association, etc.). Question Has anyone encountered this issue where Universal Links with paths/params open the app and then open Safari? What could cause iOS to trigger the browser fallback even when the AASA file is valid and the app handles the link correctly? Any insights, debugging tips, or known edge cases would be incredibly appreciated!
5
2
1.2k
Jun ’26
Potential iOS26 regression on AASA file not download on app install
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
18
1
2.4k
Jun ’26
Does the Messages link bubble support per-URL Advanced App Clip Experience cards, or only the default experience?
We have six Advanced App Clip Experiences configured for our production app, each mapped to a different path under a single domain, each with its own title and image. When a user without the full app installed receives one of these links in Messages, iOS always presents the default App Clip card -- never the matching advanced experience card. The same URLs resolve the correct advanced card in Safari. What we've already verified (so this isn't a basic setup problem): Opening the exact same URL in Safari shows the correct advanced card, including the expected per-path title. A Local Experience (Settings → Developer → App Clips Testing) for the same path + bundle ID validates and launches the correct flow. Associated Domains validation is green in Settings. The AASA at app-site-association.cdn-apple.com contains the appclips component with our App Clip bundle ID, and the applinks components include all six paths. In App Store Connect, all six Advanced App Clip Experiences show "Received" with successful domain validation, and the app + App Clip are live in the App Store. Reproduced on multiple devices on iOS [version], none with the full app installed. Messages does show a card — it's just always the default card. Our questions: Is per-path Advanced App Clip Experience card selection supported in the Messages link bubble at all -- or is Messages documented to always present the default experience metadata regardless of which advanced-experience URL is shared? Apple's App Store Connect help states the default metadata is used "in the app clip link bubble in Messages," which suggests this may be by design -- can someone confirm? If advanced cards in Messages are supported, what conditions cause Messages (but not Safari) to fall back to the default card for the same URL? Does "Received" status indicate an advanced experience is fully live, or is there a later state that confirms Messages rollout? If Messages is expected to always show the default card, we'll plan around that -- we just want a definitive answer rather than continuing to chase a configuration cause. Thanks!
1
0
477
Jun ’26
Default App Clip URL (appclip.apple.com) shows website preview instead of triggering App Clip card
We have a published, approved App Clip that works correctly via QR code and the Safari Smart App Banner, but URL-based invocation does not trigger the App Clip card in any context. Most notably, Apple's own default App Clip URL does not work either: https://appclip.apple.com/id?p=hazel-torus.Clip **Tapping this link in Messages or Notes does nothing. ** Long-pressing it shows a generic website link preview rather than the App Clip card, even though appclip.apple.com is Apple's domain and requires no configuration on our end. Setup details: App Clip bundle ID: hazel-torus.Clip Team ID: 2UNR2APH47 App Clip experience URL: https://passportreader.app/open AASA includes a correctly formatted appclips key with 2UNR2APH47.hazel-torus.Clip (confirmed via https://app-site-association.cdn-apple.com/a/v1/passportreader.app that AASA is correctly cached) Associated Domains entitlements (appclips:passportreader.app) are present on the App Clip target App and App Clip experience are both Approved / Ready for Sale Tested on two physical devices, neither with the full app installed Since QR and Safari banner invocation work, the App Clip itself and its entitlements appear correctly configured. The fact that even Apple's own appclip.apple.com URL fails, and is treated as an arbitrary website link, suggests this may be a backend indexing issue specific to this App Clip rather than a client-side configuration problem. Has anyone else encountered this, or know what could cause appclip.apple.com to not be recognized as an App Clip URL?
Replies
23
Boosts
0
Views
1.5k
Activity
3d
AASA CDN intermittently times out / requests wrong path (/apple-app-site-association vs /.well-known/...)
Hi Everyone, We are tinkering on an App using associated domains with the working name "uff2.de". We have configured our Webserver (Caddy) to restrict all URIs except for /.well-known/apple-app-site-association using Www-Authenticate. Recently our associated domains started becoming flaky, which we believe has to do with requests from Apple’s CDN failing: The following example uses a query string to trigger a fresh request by Apple’s CDN. curl -sD - "https://app-site-association.cdn-apple.com/a/v1/uff2.de?foobar" -o /dev/null HTTP/1.1 404 Not Found Server: AppleHttpServer/7b3d349ae60c243cdd677edbde3e93e460f75820 Date: Sat, 05 Sep 2026 12:01:16 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection timed out"} Apple-Failure-Reason: SWCERR00301 Timeout Apple-From: https://uff2.de/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: 457b6172513a930f Strict-Transport-Security: max-age=31536000 Age: 32 Via: https/1.1 defra2-vp-vst-018.ts.apple.com (acdn/331.16659), https/1.1 defra2-vp-vfe-016.ts.apple.com (acdn/331.16659), https/1.1 gbslo5-xdc-mx-020.ts.apple.com (acdn/331.16659), https/1.1 uklon5-edge-fx-024.ts.apple.com (acdn/331.16659) X-Cache: miss, miss, miss, miss CDNUUID: df5ac203-4188-4722-8bbc-68e9d9fd0b33-1118024500 Connection: keep-alive To investigate this further we enabled access logging and are seeing the following request that is blocked by us: 2026/09/05 12:01:16.824 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.82.202", "remote_port": "48366", "client_ip": "57.103.82.202", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000083782, "size": 0, "status": 401, "resp_headers": {"Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Www-Authenticate": ["Basic realm=\"restricted\""]}} But this seems to be the wrong URI (/apple-app-site-association instead of /.well-known/apple-app-site-association). When swapping ?foobar for other query strings like ?foobar2 or ?foobar3, some requests randomly work and some don’t. We’re also seeing flakiness for the same path (both with and without a query string) across time, but this is harder to test due to caching. For reference this is a correct request: 2026/09/05 17:54:26.075 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.81.17", "remote_port": "8692", "client_ip": "57.103.81.17", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/.well-known/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000088472, "size": 469, "status": 200, "resp_headers": {"Accept-Ranges": ["bytes"], "Content-Length": ["469"], "Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Vary": ["Accept-Encoding"], "Etag": ["\"dgrdbiykgv3ad1\""], "Content-Type": [], "Last-Modified": ["Sun, 01 Mar 2026 10:19:41 GMT"]}} Did we misread the documentation and should also serve /apple-app-site-association? Why would requests sometimes be made to /.well-known/apple-app-site-association and sometimes to /apple-app-site-association? Thank you!
Replies
10
Boosts
1
Views
236
Activity
6d
App Clip card appears when full app is installed + duplicate card on open
Hi team, We're experiencing two issues with our App Clip invocation via appclip.apple.com links. Setup: App Clip URL: https://appclip.apple.com/id?p=com.x.AppClip The App Clip card and experience work correctly when the full app is NOT installed ✅ Issue 1: App Clip card shown even when the full app is installed When the full app is already installed on the device, tapping the App Clip link shows the App Clip card instead of directly opening the full app. After tapping "Open" on the card, the full app launches — but then the App Clip card appears again on top of the app, requiring the user to dismiss it a second time. Expected behavior: If the full app is installed, tapping the App Clip link should bypass the App Clip card entirely and open the full app directly, routing to the correct screen using the URL parameters. Actual behavior: User taps App Clip link → App Clip card appears (should not appear if app is installed) User taps "Open" on the card → Full app launches App Clip card appears again on top of the full app → User has to dismiss it manually This results in unnecessary friction — two extra taps just to get into the app. Issue 2: Full app does not route to the correct screen When the full app eventually opens (after dismissing the cards), it opens to the default home screen rather than routing to the screen specified by the parameter in the URL. Expected behavior: The full app should handle the URL parameters and navigate to the appropriate screen. Actual behavior: The full app opens to its default/home screen, ignoring the url parameter. Questions: Is this expected behavior that appclip.apple.com links always show the App Clip card even when the full app is installed? If so, is there a recommended approach to bypass the card and open the app directly? What is causing the duplicate App Clip card after tapping "Open"? Is this a known issue, or is there something in our configuration that could be triggering it? For the full-app-installed case, what is the recommended way to handle deep linking from an appclip.apple.com URL into a specific screen in the full app? Should we be handling this via NSUserActivity, UIApplicationDelegate, or a Universal Link handler? Environment: iOS 26.x Xcode 26.x App Clip configured with appclips associated domain Full app and App Clip share the same App ID prefix Any guidance would be greatly appreciated. Thanks!
Replies
1
Boosts
0
Views
530
Activity
1w
Universal Links not working even though all debug steps succeed
I am trying to get universal links to work in our app Firefox iOS The Problem: I am not able to get universal links to work for our release app or beta app scheme locally or with a TestFlight build. I am able to get it working on our development scheme with a locally hosted app site association file. I also was able to get it working using our development scheme but setting the bundle id to the release app bundle id. I also built a demo app with the release app id and the release app development certificate. It succeeded there as well. Implementation Steps: Added associated domains entitlement to the production and beta schemes for our main app target (No associated domains entitlements or capabilities added for any extensions) Confirmed that the bundle ids associated with these schemes have the associated domains capability Added applinks:blog.mozilla.org to associated domains list Confirmed in code that user activities are being handled via SceneDelegate.swift Steps to Debug: I have gone through and validated every step in the provided Universal Link Debugging. All were successful: Associated Domains Development -> Diagnostics: Opens Installed App Validate AASA host and applinks match curl -v https://blog.mozilla.org/.well-known/apple-app-site-association returns the expected json file swcutil dl correctly downloads the AASA blob swcutil verify succeeds I have inspected the IPA of our beta build and confirmed the App ID and the associated domains is an entitlement. I have looked at the console logs filtering by swcd. I am not seeing any errors and I see the download for the AASA file kick off: Beginning data task AASA-4BABF039-3C69-4E36-AA4E-ECCDF3D14878 { domain: bl….mo….org, bytes: 0, route: cdn } There is only one error that appears in the console but our app is not enterprise-managed so I assume this is normal. Error getting enterprise-managed associated domains data. If this device is not enterprise-managed, this is normal: Error Domain=SWCErrorDomain Code=1701 "Failed to get associated domain data from ManagedConfiguration framework." UserInfo={NSDebugDescription=Failed to get associated domain data from ManagedConfiguration framework., Line=298, Function=<private>} I have run Sysdiagnos and identified for our App ID: Site/Fmwk Approval: approved I am at a loss as to what is preventing universal links from working even though all validation steps pass.
Replies
4
Boosts
0
Views
1.5k
Activity
2w
Are deeplinks to Apple apps acceptable?
I see online theres list of urls app can use to deeplink to Apple apps: https://github.com/bhagyas/app-urls#references-and-additional-resources are these acceptable by Apple? Apps just want to redirect the user so they can take some appropriate action.
Replies
1
Boosts
0
Views
603
Activity
4w
Bug: Correct ASSA File not fetched
How does iOS handle Associated Domains and AASA files when switching between environments? I have an iOS application that supports multiple environments (test and production). Each environment has its own domain and its own AASA file. We have an SDK that requires a domain during initialization. Based on the selected environment, we initialize the SDK with either the test domain or the production domain. We have configured the Associated Domains capability in Xcode with the required domains. However, i'm unclear about how iOS manages the AASA association in this scenario. For example: test.example.com Has its own AASA file. Used when the SDK is initialized with the test domain. example.com Has its own AASA file. Used when the SDK is initialized with the production domain. The SDK receives the domain during initialization, and we dynamically select the domain based on the environment configuration. The question is: If multiple domains are configured in Associated Domains, does iOS fetch and cache the AASA file for all configured domains when the app is installed, or only for the domain currently being used by the application? If the application switches the SDK configuration from the test domain to the production domain (or vice versa) after installation, how does iOS know that it needs to fetch the AASA file for the new domain? Is there any supported way to force iOS to re-fetch the AASA file for a newly selected associated domain? Trying to understand the correct approach for supporting multiple environments when the SDK domain is selected dynamically at runtime. If both test and production domains are configured in Associated Domains, how does iOS determine which AASA file should be used when the SDK is initialized with a specific domain (for example, test)? Does iOS fetch and validate both AASA files upfront and then check only the matching domain at runtime, or does it dynamically fetch/check only the domain provided to the SDK?
Replies
1
Boosts
0
Views
360
Activity
Aug ’26
Bug: AASA file not fetched on app install
~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.
Replies
13
Boosts
3
Views
3.7k
Activity
Aug ’26
Apple CDN returning 404 Not found for our universal Link domain.
Hi Team, Our universal links were working fine but since last week we are facing issues and when tapping the links outside app it takes to browser and not the app. Apple CDN is returning 404 for our domain and not the contents of AASA file. https://app-site-association.cdn-apple.com/a/v1/app.ooredoo.om sudo swcutil dl -d app.ooredoo.om returns The operation couldn’t be completed. (SWCErrorDomain error 7.) Can we get the exact issue apple is facing to cache the AASA file in CDN. Any server config which we need to do for AASA bot to access the file. Thanks in advance.
Replies
28
Boosts
0
Views
2.4k
Activity
Aug ’26
Associated Domains webcredentials works with ?mode=developer but fails without it - AASA correctly configured
Hi everyone, We're migrating our iOS app from Auth0 custom scheme callbacks to HTTPS Universal URLs using ASWebAuthenticationSession. We've configured everything correctly, but webcredentials only works when using ?mode=developer suffix in our entitlements, which is not allowed for App Store submissions. The Issue Without ?mode=developer: Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 "Application with identifier com.example.myapp is not associated with domain auth.example.com. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for auth.example.com." With ?mode=developer: webcredentials:auth.example.com?mode=developer Works perfectly! Questions Why does it work with ?mode=developer but not without it, even though Apple's CDN has the correct AASA? Is there a way to force iOS to re-verify associated domains without requiring users to delete and reinstall? How will this affect existing users who update the app? Will they need to reinstall? Is there a known propagation delay beyond the CDN showing correct data? Any guidance would be greatly appreciated. We cannot ship to the App Store with ?mode=developer, but without it, the authentication fails. Thank you!
Replies
3
Boosts
0
Views
1k
Activity
Jul ’26
Universal Links failing for some users but working for others
Hi, We are facing an issue where Universal Links are working for most users but failing for some of our clients. For affected users: Links open in Safari instead of the app, or Universal link routing does not work as expected For other users: The same links open the app correctly What we verified Associated Domains capability is configured correctly AASA file is valid and accessible App configuration and bundle ID mapping are correct AASA: https://www.gartner.com/apple-app-site-association Issue Since the problem is only affecting a subset of users, we are unable to: Reproduce the issue consistently Identify when or why the association breaks Ask Has anyone experienced: Universal Links failing only for certain users/devices? What are the possible causes and how can we debug or proactively identify the root cause in such cases? Any guidance would be helpful. Thanks!
Replies
9
Boosts
0
Views
740
Activity
Jul ’26
Apple's CDN always returns “not found”
We are testing Apple Universal Links for ios.aierchina.com. The domain is ICP-registered and hosted in mainland China. The problem: Apple's CDN always returns “not found” for our AASA file: https://app-site-association.cdn-apple.com/a/v1/ios.aierchina.com What we have verified: The AASA file is correctly served at both /.well-known/apple-app-site-association and /apple-app-site-association Returns HTTP 200, valid JSON, correct Content-Type, no redirects, valid SSL Server response time is under 500ms What works: Adding ?mode=developer to the applinks entry works perfectly Universal Link Diagnostics on device (ios.aierchina.com/uat) correctly resolves to our app bundle What does not work: Production mode fails because the Apple CDN never caches our AASA file Reinstalling the app does not help Server logs show occasional requests from com.apple.swcd, but CDN still returns 404 Questions: Are there known issues with Apple CDN caching AASA files for China-hosted domains? Is there any way to force Apple's CDN to re-crawl our domain? Could the GFW or regional network policies be interfering? What was the fix?
Replies
3
Boosts
0
Views
1.1k
Activity
Jul ’26
https://app-site-association.cdn-apple.com/a/v1/* 404 Not Found
% curl -v https://app-site-association.cdn-apple.com/a/v1/zfcs.bankts.cn Host app-site-association.cdn-apple.com:443 was resolved. IPv6: (none) IPv4: 218.92.226.151, 119.101.148.193, 218.92.226.6, 115.152.217.3 Trying 218.92.226.151:443... Connected to app-site-association.cdn-apple.com (218.92.226.151) 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-AES256-GCM-SHA384 / [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: Sep 25 13:58:08 2025 GMT expire date: Mar 31 17:44:25 2026 GMT subjectAltName: host "app-site-association.cdn-apple.com" matched cert's "app-site-association.cdn-apple.com" issuer: CN=Apple Public Server RSA CA 11 - G1; O=Apple Inc.; ST=California; C=US SSL certificate verify ok. using HTTP/1.x GET /a/v1/zfcs.bankts.cn 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 < Content-Type: text/plain; charset=utf-8 < Content-Length: 10 < Connection: keep-alive < Server: nginx < Date: Wed, 04 Feb 2026 02:26:00 GMT < Expires: Wed, 04 Feb 2026 02:26:10 GMT < Age: 24 < Apple-Failure-Details: {"cause":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"} < Apple-Failure-Reason: SWCERR00301 Timeout < Apple-From: https://zfcs.bankts.cn/.well-known/apple-app-site-association < Apple-Try-Direct: true < Vary: Accept-Encoding < Via: https/1.1 jptyo12-3p-pst-003.ts.apple.com (acdn/3.16363), http/1.1 jptyo12-3p-pac-043.ts.apple.com (acdn/3.16363), https/1.1 jptyo12-3p-pfe-002.ts.apple.com (acdn/3.16363) < X-Cache: MISS KS-CLOUD < CDNUUID: 736dc646-57fb-43c9-aa0d-eedad3a534f8-1154605242 < x-link-via: yancmp83:443;xmmp02:443;fzct321:443; < x-b2f-cs-cache: no-cache < X-Cache-Status: MISS from KS-CLOUD-FZ-CT-321-35 < X-Cache-Status: MISS from KS-CLOUD-XM-MP-02-16 < X-Cache-Status: MISS from KS-CLOUD-YANC-MP-83-15 < X-KSC-Request-ID: c4a640c815640ee93c263a357ee919d6 < CDN-Server: KSFTF < X-Cdn-Request-ID: c4a640c815640ee93c263a357ee919d6 < Not Found Connection #0 to host app-site-association.cdn-apple.com left intact
Replies
2
Boosts
0
Views
637
Activity
Jul ’26
QR code scan deeplink not work in XCode test run?
Hi, I'm trying to figure out what is true here - if I am not in the correct forum please direct me :-) A. It is not possible to test a QR code scan that contains a deeplink into my iOS app from an XCoode build test run. In other words, The build must be published to Test Flight for the iOS's QR code scan sub-system to be able to process the deeplink into my app? If I am wrong about this, it sure would help with testing to be able to test directly from the local XCode build test. If so, can someone point me in the direction of what I would need to do for that? Thanks for your input either way!
Replies
1
Boosts
0
Views
783
Activity
Jul ’26
app-site-association.cdn-apple.com | Cache not updating
We're handling our universal links (deep links) via our custom router written in express.js. We recently update our .well-known format as per: https://developer.apple.com/documentation/xcode/supporting-associated-domains Our own domain link shows them correctly if we apply cache bust to it: Normal link: https://links.sastaticket.pk/.well-known/apple-app-site-association Cache bust: https://links.sastaticket.pk/.well-known/apple-app-site-association?1 Now, since app-site cache is not updating at: https://app-site-association.cdn-apple.com/a/v1/links.sastaticket.pk Our main domain link is not getting updated response either. Its been more than 72 hours now. Any help, how to push the app-site cache to update? I can provide more context if needed, Thanks
Replies
2
Boosts
0
Views
1.3k
Activity
Jul ’26
Using wildcard for applinks in iOS stopped working
Hi everyone, I've been working on an application that provides different subdomains for different customers, so we need to support app linking with all of them. However, using wildcard notation like applinks:*.domain.com doesn't work, while hardcoding applinks:subdomain.domain.com works fine. The association file is being served from both the main domain and subdomains. It used to work fine about a month ago, and I can't find any recent breaking changes on Apple's side . Any ideas why this could happen. ?
Replies
4
Boosts
0
Views
1.4k
Activity
Jul ’26
Applinks for any subdomain not opening the app
My Entitlements file contains the following (removed some non related entries): <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.associated-domains</key> <array> <string>webcredentials:app.mydomain.org</string> <string>applinks:*.mydomain.org</string> </array> </dict> </plist> Now when I tap on a link such as abc.mydomain.org, the app is not opened. If I change the generic applinks key from *.mydomain.org to a specific domain, this works correctly and it opens the app as expected. (This makes me think the website part of the AASA file is correct). Since I need to support a lot of subdomains (think about hundreds in the near future), I really need the wildcard to work. Do you have any tips on how to make this work?
Replies
1
Boosts
0
Views
658
Activity
Jul ’26
AASA file on CDN not found more than one week
Last week our Universal Links stopped working. We made some changes and uploaded a new AASA file, but https://app-site-association.cdn-apple.com/a/v1/(domain) still returns 404 Not Found for all our domains. When I query directly from our server like domain/.well-known/apple-app-site-association, it returns 200 and the file is accessible. Could you help us resolve this issue? Our app relies on working Universal Links (deep links). Thank you!
Replies
1
Boosts
0
Views
489
Activity
Jul ’26
iOS Universal Link opens app and then opens browser (Flutter + Universal Links) — only when using paths/params
Hi everyone, I’ve been stuck on an issue with iOS Universal Links for about a week and could really use some help. The problem When tapping a Universal Link on iOS, my Flutter app opens correctly (desired behavior) — but immediately afterward, Safari opens the same link in the browser. So both the app and the browser open. This only happens on iOS. On Android everything works as expected. What works If the link is simply the domain, like: https://mydomain.com …then the app opens without triggering the browser afterward. This is the correct behavior. What doesn’t work If the link includes a path or parameters, like: https://mydomain.com/path https://mydomain.com/path?param=value …then the app opens, and then the browser opens immediately after. What I’ve tried Verified my AASA file using Branch’s validator: https://branch.io/resources/aasa-validator/ → The AASA file is valid. Universal Links do open the correct screen inside the app — the issue is the unwanted second step (Safari opening). Behavior is consistent across different iOS devices. Extra details Using Flutter. Universal Links set up with the standard configuration (associatedDomains, AASA hosted at /.well-known/apple-app-site-association, etc.). Question Has anyone encountered this issue where Universal Links with paths/params open the app and then open Safari? What could cause iOS to trigger the browser fallback even when the AASA file is valid and the app handles the link correctly? Any insights, debugging tips, or known edge cases would be incredibly appreciated!
Replies
5
Boosts
2
Views
1.2k
Activity
Jun ’26
Potential iOS26 regression on AASA file not download on app install
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
Replies
18
Boosts
1
Views
2.4k
Activity
Jun ’26
Does the Messages link bubble support per-URL Advanced App Clip Experience cards, or only the default experience?
We have six Advanced App Clip Experiences configured for our production app, each mapped to a different path under a single domain, each with its own title and image. When a user without the full app installed receives one of these links in Messages, iOS always presents the default App Clip card -- never the matching advanced experience card. The same URLs resolve the correct advanced card in Safari. What we've already verified (so this isn't a basic setup problem): Opening the exact same URL in Safari shows the correct advanced card, including the expected per-path title. A Local Experience (Settings → Developer → App Clips Testing) for the same path + bundle ID validates and launches the correct flow. Associated Domains validation is green in Settings. The AASA at app-site-association.cdn-apple.com contains the appclips component with our App Clip bundle ID, and the applinks components include all six paths. In App Store Connect, all six Advanced App Clip Experiences show "Received" with successful domain validation, and the app + App Clip are live in the App Store. Reproduced on multiple devices on iOS [version], none with the full app installed. Messages does show a card — it's just always the default card. Our questions: Is per-path Advanced App Clip Experience card selection supported in the Messages link bubble at all -- or is Messages documented to always present the default experience metadata regardless of which advanced-experience URL is shared? Apple's App Store Connect help states the default metadata is used "in the app clip link bubble in Messages," which suggests this may be by design -- can someone confirm? If advanced cards in Messages are supported, what conditions cause Messages (but not Safari) to fall back to the default card for the same URL? Does "Received" status indicate an advanced experience is fully live, or is there a later state that confirms Messages rollout? If Messages is expected to always show the default card, we'll plan around that -- we just want a definitive answer rather than continuing to chase a configuration cause. Thanks!
Replies
1
Boosts
0
Views
477
Activity
Jun ’26