Universal Links and Cloud-testing platforms

Thanks so much with the post. Can I ask you what’s your “cloud-based device testing environment”?

Because Universal Links rely on cryptographic trust between the app and the web server, the re-signing process inherently could breaks this trust? The platform signs the app with their own provisioning profile, which does not contain your com.apple.developer.associated-domains entitlement?

Apple's security model intentionally prevents unauthorized third parties from claiming your domain. Therefore, there is no native Apple provisioning flag that tells iOS to "ignore" AASA validation for re-signed builds.

Can you provide more details? However, please understand that Universal Links will only work on physical devices with the entitlement.

Albert Pascual
  Worldwide Developer Relations.

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:

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

Thanks so much for the reply and the detailed information. Yes, looks like the resigning will cause the issue you have described. I still recommend you to test against your devices to make sure the AASA file get downloaded and works well before sending the build to the App Store.

You are correct that we do not offer a native provisioning flag to bypass AASA validation. Apple’s AASA file specification fully supports listing multiple App IDs (Team ID + Bundle ID) for a single domain.

You can also use TestFlight to distribute your app to test devices.

Wish you luck. Looking forward to your app.

Albert Pascual
  Worldwide Developer Relations.

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.

Thanks for the email. No, to be clear, I do not recommend a re-signed of any form. I recommend to test on your device and deploy with Xcode to make sure the provisioning profile is the same.

I'm not encouraging nor endorsing any other test.

Hope this help

Albert Pascual
  Worldwide Developer Relations.

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.

@michelbechelani-aya

Yes, if you distribute the app using the Apple Developer Enterprise Program or TestFlight there is no need to resign the app, therefore everything will work on the app.

Now the most robust way to handle OAuth/Sign-in flows in automated cloud testing does not need Universal Links entirely for your test builds.

Create a specific build configuration for your cloud tests. In this build, configure your app to use a Custom URL scheme for its callback. Configure your staging/testing Auth Server to accept and redirect to this Custom URL scheme instead of the Universal Link (https://...). When the test runner triggers the login, the browser will redirect to myapp-test://, which the OS will route back to your app, regardless of who signed it.

Not trying to side track you. Follow your architecture, but I want to make sure to show there are other options.

Albert Pascual
  Worldwide Developer Relations.