There's a specific SwiftUI type ContentTransition link which seems designed for this use case. However: The current library doesn't seem to have a way to ensure that the transition used will depend on how a property changes. The currently library doesn't seem to provide for any custom creation of a ContentTransition (although the stock ones are really cool). There's also a SwiftUI type PlaceholderContentView link which looks like it might be used to implement SwiftUI features such as transitions, so it could perhaps be used to implement the replacingWithTransitionOnChanges function I suggested above – however, it doesn't seem to be publicly accessible as far as I can tell. A possible approach – I think it could be possible to nest several views inside each other with each of the views having a specific transition. Playing with id would then let a given view be replaced, which should trigger only its transition (because transitions only happen on the outermost view that is added or removed – as far as I know). This might work, but it isn't very extensible, at all reusable, or clear at the point of use what's going on.

Hello, Did you ever receive a response to this? It seems to still be the situation (Monterey 12.4). I've tried a few approaches but I've not found anything satisfactory. This approach using DisclosureGroup doesn't seem to function correctly for even modestly deep lists and sometimes doesn't properly open or close.

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.

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.

Hi @gaste We don't currently have an MDM vendor, and our devices aren't under MDM control. Do you know what this involves and if it can be done minimally, rather than bringing in a vendor? I've noticed that it is relatively simple to create a .mobileconfig file using Apple's Configurator (sorry – the forum prevents me providing a link). These files can be simply distributed by email and installed. I've created such a config and tried to set it up to enable mode=managed, but this hasn't worked (and I can't find any failure messages in sysdiagnose). I don't know if I've just got this wrong, or if it needs signing, or if it needs to be associated with the App somehow? Our app itself is enterprise signed. We distribute it using AppCentre. We distribute both to internal test devices owned by the company, and also to colleague's personal devices. Thanks.

In the Mac's Console App it is necessary to turn on: "Action -> Include Info Messages" "Action -> Include Debug Messages". When these are checked, swcd messages will be included in the console.

You should enable this option in developer menu. Hi @_tayphoon, Could you give a bit more detail, please? Do you mean "Settings App -> Developer -> Logging -> Networking" on the device under test? I've tried switching this to On, but there is still no logging in the Mac OS Console for the swcd process of the iPhone when I follow a universal link. Thanks.

The final post here - https://developer.apple.com/forums/thread/96570 mentions: For my case, I think I have come to the point where I can conclude that the certificate for the server must be signed with a root CA that is provided with iOS. If you have a certificate signed with a user-installed (or mdm-installed) root CA, then the SecTrustResult is "proceed" instead of "unspecified", which is OK for Safari and other URLSession uses but not for the apple-app-site-association validation... Which seems like something perhaps related? Or am I clutching at straws?

I've been looking in to this recently as we have the same situation. My understanding so far… As of iOS 14, devices will go to an Apple hosted CDN to obtain your AASA file. This is discussed here: https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_associated-domains As also mentioned in the note, it is possible to bypass the CDN is two ways by using an "alternative-mode". The options are developer and managed. These are activated by appending to your associated domain in your entitlements file. For the developer mode you need to allow the bypassing in the Settings App -> Developer. You also need to sign the app with a developer distribution profile. The managed mode is suitable for enterprise signed apps. To use this you must instal a managed device profile (an MDM .mobileconfig file) to authorise use of the CDN bypass. This needs you to create the profile. Apple have some MDM background - https://support.apple.com/en-in/guide/mdm/mdmbf9e668/1/web/1.0 documentation. You can create a skeleton profile with Apple's Configurator II tool - https://apps.apple.com/gb/app/apple-configurator-2/id1037126344?mt=12. This tool only supports a small number of widely used MDM payload-types though, and that doesn't include the com.apple.associated-domains payload that we need to specify. Every payload uses a standard set of generic properties described here - https://developer.apple.com/documentation/devicemanagement/configuring_multiple_devices_using_profiles under "Define a Profile".  The specific com.apple.associated-domains payload we need to use is introduced in device management of Associated Domains - https://developer.apple.com/documentation/devicemanagement/associateddomains, which defined that we need to use a PayloadType of com.apple.associated-domains. It's then necessary to add specific properties to the payload shown here - https://developer.apple.com/documentation/devicemanagement/associateddomains/configurationitem: <key>ApplicationIdentifier</key> – string with the full app id, such as <string>your-app-id</string> – the App id is the same as in your AASA file. <key>EnableDirectDownloads</key> – boolean </true> <key>AssociatedDomains</key> – an <array>…</array> having a list of the <string>…</string>, one for each domain that we want to bypass Apple's CDN. To find these I simply took the domains from the "*_Debug.entitlements" file. My assumption is all the domains the app wants to be "entitled" to for universal linking must be included in the AASA CDN bypass list. Actually installing a profile is easy. You can email it to yourself at the device and start the instal from Mail App. However, I've installed a profile, put my device on the VPN, installed a build of the App with the modified entitlements, and a test link in to the App still fails. So it still doesn't work. I'm now investigating why it might not be working… Leads on this are: Get a sysdiagnose - https://download.developer.apple.com/iOS/iOS_Logs/sysdiagnose_Logging_Instructions.pdf, note that it seems to be necessary to hold the buttons less than the advertised 1.0 to 1.5 seconds. About half a second seemed correct, and after longer the device shows the turn off / emergency call screen. Look in "swcutilshow.txt" in the sysdiagnose file. More details <link blocked my apple's site, sorry>. This is all very interesting, but it doesn't seem_ to show errors with obtaining the AASA file. Look in the console when the device is attached. Search for swcd. One thought is: perhaps the MDM needs to be signed by the domain? Perhaps it needs lots of other things in it? Is there any way to debug or validate it? Any help with this from Apple would be super appreciated as I feel fairly lost! Are you there Quinn? Thank you, Benjohn

Hi Nakim, Did you get any further with this? Thank you, Benjohn