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?

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.

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!

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!

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?

% 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

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!

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

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. ?

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?

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!

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!

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

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!

Hi everyone, Just recently we started having issues in our integration environment with publicly available well known files not being fetched properly by the Apple CDN. The CDN keeps returning an SWCERR00301 Timeout fault. I noticed a very similar thread around the same time it went wrong with us as well: https://developer.apple.com/forums/thread/821908 However, the fault is ever so slightly different. Note that for security reasons, the actual domain has been redacted and replaced by the generic "domain.com" When calling the command curl -i https://app-site-association.cdn-apple.com/a/v1/domain.com The following is returned HTTP/1.1 404 Not Found Server: AppleHttpServer/2caa77a6bc2e755fca0e0f63e4d67e53390f9184 Date: Thu, 21 May 2026 10:44:08 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://domain.com/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: eb38e1901a83ad9b Strict-Transport-Security: max-age=31536000 Expires: Thu, 21 May 2026 10:44:18 GMT Age: 712 Via: http/1.1 defra2-vp-vst-004.ts.apple.com (acdn/302.16436), https/1.1 defra2-vp-vfe-007.ts.apple.com (acdn/302.16436), https/1.1 nlams2-edge-lx-007.ts.apple.com (acdn/302.16436), https/1.1 nlams2-edge-bx-021.ts.apple.com (acdn/302.16436) X-Cache: hit-fresh, hit-stale, hit-stale, hit-stale CDNUUID: 859e620c-7e2c-438c-a43d-68b6344e890c-1593129103 Connection: keep-alive Not Found Where other issues on the forum specifically target "waiting on headers", it does not in our case. We checked our internal infrastructure, we clearly see incoming requests from the ASAA-bot requesting the well known file. These requests hit our backends as they should and return a 200 OK. All within a couple of milliseconds. Again - nothing changed here. After this validation, I read the Tech notes: TN3155: Debugging universal links | Apple Developer Documentation but it does not provide anything we did not already check. Besides on our side, hosting wise and content-wise, nothing changed. This is not new material. I ultimately enabled developer mode on my test device, pushed the Integration app version causing the issues. When keeping the entitlements asis, the apple CDN is called from the iOS device (verified through ProxyMan) but the redirects do not work (as the CDN contains 404 Not Found) When changing the entitlements, and adding "?mode=developer", the CDN is of course skipped and our backend is called directly (as verified through ProxyMan). Now the redirects work as intended, the universal links were fetched properly. (the embedded universal link tester on the iOS device in settings - Developer still did not validate the universal link correctly though. But this seems an issue in the tool. The working production universal link also does not validate while it definitely works) To make sure our backend is not too 'slow' (internal logging shows requests are handled within 100 ms), I checked against UAT. Same processing times, there no issues with CDN. We conducted a very thorough investigation on our side and I do not see any reason as to why the CDN should be throwing timeout exceptions. As we cannot flush the CDN cache and do not see issues on our side, there is no way for us to validate why this is going wrong. Does anyone have any clues on what else I can do? Thanks

Hello, We are planning to transfer an app to a different Apple Developer account and had several questions regarding Apple App Site Association (AASA) and Universal Links behavior after the transfer. We are specifically interested in the period immediately after the app transfer, but before the app has been updated under the recipient account. We currently support Universal Links through our Apple App Site Association (AASA) configuration. Could you clarify the following: After the app transfer, will existing Universal Links continue functioning for users who already have the app installed? Will we need to update our AASA file to include the recipient account’s new Team ID in order for Universal Links to continue functioning properly? If so, is there a recommended transition strategy for supporting both existing installed app instances and newly installed versions during the migration period? Any clarification on the expected Universal Links and AASA transition behavior during and after an app transfer would be greatly appreciated. Thank you.

We have an issue where Safari on iOS is not handing off to our app after an Auth0 authentication redirect. Issue After a user completes sign-in via an Auth0-hosted login page in Safari, the callback redirect is followed as a plain HTTP navigation rather than being intercepted and handed off to the app. Callback URL format https://identity.example.com/ios/com.example.app/callback Steps to reproduce Open an Auth0 /authorize URL in Safari on iOS with a redirect_uri pointing to a Universal Link callback, log in, and observe that Safari navigates to the callback URL as a plain HTTP request rather than launching the app. What works ASWebAuthenticationSession inside the app handles the same callback correctly. Navigating directly to a Universal Link launches the app, confirming AASA and Universal Links are correctly configured on the affected devices. The issue is specific to Safari intercepting the callback URL when it arrives as the result of an Auth0 redirect. Affected devices Reproducible across multiple devices and iOS versions from iOS 18.x through iOS 26.x. Does Safari have a restriction on intercepting Universal Links that result from a cross-domain redirect? Any guidance appreciated 🙏

Dear Team, We are trying to implement universal linking app to app redirection for our banking application. We have configured the associated domains in our application as can be seen below in the info plist of our IPA <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>application-identifier</key><string>2TK5X82C47.com.bankalbilad.NewRMB</string><key>aps-environment</key><string>production</string><key>beta-reports-active</key><true/><key>com.apple.developer.associated-domains</key><array><string>applinks:rob-auth.bankalbilad.com</string></array><key>com.apple.developer.icloud-container-identifiers</key><array></array><key>com.apple.developer.pass-type-identifiers</key><array><string>2TK5X82C47.*</string></array><key>com.apple.developer.payment-pass-provisioning</key><true/><key>com.apple.developer.team-identifier</key><string>2TK5X82C47</string><key>com.apple.developer.ubiquity-kvstore-identifier</key><string>2TK5X82C47.com.bankalbilad.NewRMB</string><key>com.apple.security.application-groups</key><array><string>group.com.NewRMB</string></array><key>get-task-allow</key><false/><key>keychain-access-groups</key><array><string>2TK5X82C47.com.bankalbilad.NewRMB.keychain</string></array></dict></plist> We are unable to see the call made from IOS reaching the endpoint which is https://rob-auth.bankalbilad.com/.well-known/apple-app-site-association We performed curl of our domain and get the below error. curl -i https://app-site-association.cdn-apple.com/a/v1/rob-auth.bankalbilad.com HTTP/1.1 404 Not Found Server: AppleHttpServer/2caa77a6bc2e755fca0e0f63e4d67e53390f9184 Date: Thu, 14 May 2026 11:42:16 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection failed"} Apple-Failure-Reason: SWCERR00305 Network error Apple-From: https://rob-auth.bankalbilad.com/.well-known/apple-app-site-association Apple-Try-Direct: false Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: bfafe8fa87a6828f Strict-Transport-Security: max-age=31536000 Age: 21 Via: https/1.1 defra2-vp-vst-017.ts.apple.com (acdn/302.16436), https/1.1 defra2-vp-vfe-006.ts.apple.com (acdn/302.16436), http/1.1 defra2-xdc-mx-023.ts.apple.com (acdn/302.16436), http/1.1 defra1-edge-fx-060.ts.apple.com (acdn/302.16436) X-Cache: hit-stale, hit-stale, hit-fresh, hit-fresh CDNUUID: 6fb88181-f58a-4059-a770-26a43e1f32d0-16071773867 Expires: Thu, 14 May 2026 11:42:26 GMT Connection: keep-alive Not Found curl -v https://app-site-association.cdn-apple.com/a/v1/rob-auth.bankalbilad.com * Host app-site-association.cdn-apple.com:443 was resolved. * IPv6: (none) * IPv4: 17.253.15.159, 17.253.63.204, 17.253.63.201, 17.253.29.140, 17.253.29.162, 17.253.39.133, 17.253.39.145, 17.253.15.162 * Trying 17.253.15.159:443... * schannel: disabled automatic use of client certificate * ALPN: curl offers http/1.1 * ALPN: server accepted http/1.1 * Connected to app-site-association.cdn-apple.com (17.253.15.159) port 443 * using HTTP/1.x > GET /a/v1/rob-auth.bankalbilad.com HTTP/1.1 > Host: app-site-association.cdn-apple.com > User-Agent: curl/8.13.0 > Accept: */* > < HTTP/1.1 404 Not Found < Server: AppleHttpServer/2caa77a6bc2e755fca0e0f63e4d67e53390f9184 < Date: Thu, 14 May 2026 11:42:16 GMT < Content-Type: text/plain; charset=utf-8 < Content-Length: 10 < Apple-Failure-Details: {"cause":"Connection failed"} < Apple-Failure-Reason: SWCERR00305 Network error < Apple-From: https://rob-auth.bankalbilad.com/.well-known/apple-app-site-association < Apple-Try-Direct: false < Cache-Control: max-age=3600,public < Vary: Accept-Encoding < X-B3-TraceId: bfafe8fa87a6828f < Strict-Transport-Security: max-age=31536000 < Age: 33 < Via: https/1.1 defra2-vp-vst-017.ts.apple.com (acdn/302.16436), https/1.1 defra2-vp-vfe-006.ts.apple.com (acdn/302.16436), http/1.1 defra2-xdc-mx-023.ts.apple.com (acdn/302.16436), http/1.1 defra1-edge-fx-058.ts.apple.com (acdn/302.16436) < X-Cache: hit-stale, hit-stale, hit-fresh, hit-fresh < CDNUUID: 77d7de5e-f827-44b1-bbf5-ae2d8e36e104-16053052830 < Expires: Thu, 14 May 2026 11:42:26 GMT < Connection: keep-alive We also don't see any blocks in our firewall or in WAF or any network level Load balancers. Can you please help in troubleshooting the same.

I'm following up from an old existing post per the recommendation by DTS Engineer I'm referencing that comment specifically because i'm only able to reproduce this issue when using a device through browserstack. (a service that allows remote access to physical ios devices for testing, etc) I haven't been able to reproduce the issue on my physical device. When attempting to launch an ASWebAuthenticationSession using callback: .https(host: path:), The session immediately fails (before even presenting the web modal) with the error: Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 NSLocalizedFailureReason=Application with identifier com.builderTREND.btMobileAppAdHoc is not associated with domain test.buildertrend.net. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for test.buildertrend.net. Which doesn't make sense, since our AASA file does specify that url and has the app ID listed in webcredentials Our app's entitlements file also contains webcredentials:*.buildertrend.net So it seems like everything is set up properly, but this issue is persistent.

How does Associated Domains Development work on watchOS? In comparison, on iOS we have Diagnostics menu that allows to input a link and test the setup. How to achieve the same on a watch? watchOS: iOS: