Hi, Thank you again for your continued guidance on this. Since Universal Links are part of our sign-in/login/authorization workflow, they are required for all of our testing workflows. Our cloud testing platform has indicated that if we distribute the app to them via the Apple Developer Enterprise Program, they would not need to re-sign it, which would preserve the Associated Domains entitlement and allow the sign-in flow to work correctly on their device farm. Since our app also needs to be published to the App Store, we would continue using our standard Apple Developer Program for that purpose. Is this a valid scenario? We want to stay within Apple's supported provisioning model. If maintaining both an Enterprise Program and a Developer Program membership is the right path forward, we are prepared to do that.

Hi, Thank you for the follow-up and for confirming the AASA multi-App ID support, that is a useful detail. Just to make sure we fully understand the recommendation: are you suggesting we add the testing platform's Team ID + Bundle ID to our AASA file so that their re-signed build is also a trusted app for our domain? If so, we want to understand the security implications of listing a third-party signing identity in our AASA file before going down that path. Regarding TestFlight, we are already using it for manual pre-release testing and it works well for that purpose. Our challenge is specifically with automated UI testing in a cloud device farm, where TestFlight distribution is not part of the workflow. We also wanted to ask about a hybrid distribution approach we are considering, and whether it is permitted under Apple's terms: Use the Apple Developer Enterprise Program to distribute the app internally to our cloud-based testing infrastructure, allowing their re-signing process to work under an Enterprise provisioning profile that preserves the Associated Domains entitlement. Continue using our standard Apple Developer Program membership exclusively for App Store distribution. We want to confirm that using Enterprise distribution solely for internal pre-production testing, while keeping App Store publishing under the standard program, does not conflict with Apple's Developer Program License Agreement or the intended use of the Enterprise Program. We will continue testing Universal Links on physical devices as recommended to validate the AASA file prior to App Store submission. Thank you again for your time and guidance throughout this thread.

Thank you for the quick response and for the clarification on how iOS enforces AASA validation, that context is very helpful. To answer your question: our cloud-based device testing environment is a third-party device farm that runs automated UI tests against real iOS devices hosted in their infrastructure, BrowserStack. In order to install our app on their devices, their platform re-signs the app using their own provisioning profile, which is where the Associated Domains entitlement is lost. We fully understand that this is a security boundary by design, we are not looking to bypass AASA validation in production. Our concern is specifically scoped to pre-production testing: we need a way to validate our authentication flow end-to-end (including the Universal Link redirect back into the app) in an automated, cloud-hosted environment before shipping to production. Given your confirmation that there is no native provisioning flag to accommodate this, we have a follow-up question: Short of the Enterprise Developer account approach, is there any Apple-supported testing pattern for end-to-end validation of Universal Link–based authentication flows in automated environments? We want to stay within Apple's supported provisioning model, we just need to find a path that doesn't require an Enterprise account or manual testing on physical devices for every authentication flow validation. Thank you again for your time and guidance.