Support for associated domains that are not publicly accessible

how are they going to provide consent in order to support "managed" associated domains that can only be accessed under a VPN?

They're not.

If you want the advantages of MDM, you want MDM.

I don't want the advantages of MDM, I just want associated domains that are behind a VPN to work on ANY device (that includes devices that are not under a MDM profile), but it seems that in order to do that we are forced now to use MDM.

I just wanted to confirm that with the changes in iOS 14 the only option for distributed apps is to use "managed" associated domains and therefore, this scenario, will never work for an AppStore build publicly distributed.

I'm facing the same problem.

We have an internal network that has intranet sites accessible and I need the app signed by Enterprise Universal Distribution to query our server directly instead of Apple's CDN. The device does not even have public internet access.

MDM doesn't cut it because our test devices are not managed.

What about builds distributed via TestFlight, which are connected to internal Test environment which is accessible via VPN or on internal network?

Developer mode is sufficient for immediate development, but cannot be used in TF beta testing.

Is there any solution for this common case?

Has anyone had any progress at all with this?

If it's necessary to use MDM, what does this actually entail?

• Are there "light touch" approaches that are suitable for colleague testing using personal devices, as as well as QE testing on enterprise owned test devices?

• Does it require app installs to be also managed by MDM, or can we continue enterprise signing and distributing / installing with AppCenter / dragging on an IPA with finder?

• Does anyone know of any resources beyond Apple's documentation on MDM and on associated domains?

Thanks.

We've made a small degree of progress with this.

The underlying issue is that our internal private domains (eg, internal.my-company.com) are only available using the VPN, and Apple's new CDN isn't on the VPN, so it can't reach the private domain and access the AASA hosted there. We want to continue to use a private domain internally for security reasons.

However, there's no requirement that the domain used for universal linking (where the AASA file is hosted) must be the same domain at which services or endpoints or other parts of our environment are hosted.

So, the simplest and most robust solution seems to be to create a new domain to use just for universal links in to the app. We'll use something like links.my-company.com for this. This domain don't be private, so Apple's CDN can access it. There's only the .well-known/apple-app-site-association living there, which we consider minimal risk. The App can continue to reach the private domain with it's endpoints and services, and this continues to only be accessible using the VPN.

We might look at setting up the MDM at a later time, but given the scant information on this available so far, it seems like a lot of trouble and more parts that can go wrong!

Hopefully this approach might work for others as well.