I've also raised a Feeback Assistant ticket for this FB24136873

Thanks for the reply! Sounds like it's not just me ... Sorry, to clarify my original post, the initial MDM management profile does install but then I get no activity over APNS at all... and for Jamf at least (I'm less experienced with other MDMs), the APNS push after enrol is how the jamf management daemon, Self Service app etc get installed and none of that happens. So to me it does seem like an APNS issue, I just don't know if it's my fault somehow.

Thanks Quinn. I do have Developer ID Application distribution signing of this working already, it's the Apple Development certificate + registered test device bit I'm struggling with. I'll read through the post linked and see if it helps, and if not I'll create a new thread as requested

Hi guys @DTS Engineer @DTS Engineer , Thanks for the help so far. I've got this working now thanks to your prior help, I can now successfully do this for Endpoint Security System Extension, but I've hit another snag. We have another component we're developing in to our product suite, that being a network filter system extension implementing NETransparentProxyProvider. The extension for production (Developer ID Application signed + notarized) builds with: com.apple.developer.networking.networkextension = [ app-proxy-provider-systemextension ] But I can't get a macOS App Development profile that includes the entitlements required, for either of the App IDs involved (system extension itself, eg com.example.filter-app.network-extension, or the app which sysext is bundled in ie com.example.filter-app) Development profiles generated via the web interface at developer.apple.com/account for both App IDs carry only the app-extension flavours of the NE providers, so the -systemextension values our binaries are signed with aren't in the profiles' allowlists, signature validation fails, and the extension won't activate on a SIP-enabled but correctly registered Mac. I've inspected both profile types side by side (security cms -D -i app-dev.provisionprofile). The Development profile contains: app-proxy-provider content-filter-provider packet-tunnel-provider dns-proxy dns-settings relay url-filter-provider hotspot-provider The Developer ID Application profile for the same App ID contains: packet-tunnel-provider-systemextension app-proxy-provider-systemextension content-filter-provider-systemextension dns-proxy-systemextension dns-settings relay url-filter-provider hotspot-provider So the four providers that have a system-extension form show up in app-extension form in the Development profile and in -systemextension form in the Developer ID one. The other four values are identical in both. To rule out a "it happens when you use the web" scenario, I tried using fastlane sigh (--development), which as far as I understand it, drives the App Store Connect API, to see if generating the development profiles via that method gives different results but I got a profile back with the exact same issue. Right now I'm not sure how I can build a system extension NETransparentProxyProvider and sign it with my Apple Developer certificate for testing on a registered Mac/VM. Am I doing something wrong? Happy to send over the raw profiles etc in a DTS ticket if you feel that's the better route? Thanks,

Apologies for the delay responding, thanks both for the replies they've helped me fill in the missing gaps in what I'd already tried and got a solution now!

I was able to get a macOS 27 VM on a macOS 26 host by creating a macOS 26 VM, signing in to iCloud, and enabling the macOS 27 beta channel for software updates. Initially I got an error saying it was unable to customise the install, but I simply quit System Settings, and tried again, which then worked. Note: macOS 27 appears to actively prevent SIP disablement, lots of people reporting it refuses to install if SIP is already disabled, and I get errors disabling SIP once installed from the recovery mode, which is troublesome for my dev-workflow.

I have the same frustration. We use VMs to do integration testing with our software which has an Endpoint Security System Extension. VMs are perfect for testing this as we can quickly revert the VMs back to a known state, boot them, install our software, and run an automated testing suite. Currently, we are having to rebuild beta VMs every time a new beta is dropped as it's becoming essentially impossible to do in-place updates of the beta OS on a VM :(. Given we need to make use of configuration profiles to ensure smooth operation of our solution, this is a laborious process and simply updating the OS in place would save us a lot of time and effort.

As per the other commenters above, the principal reason for running macOS in virtualized containers is to bypass the need to dual boot a machine to get access to a beta OS for testing software, which as a workflow is cumbersome and in reality completely impractical when also needing to be joining video conferences and conforming to corporate IT security policies. Please provide us with a solution for logging in to the App Store / other iCloud services from macOS VMs on Apple Silicon. I posted the above in this thread 9 months ago. The recent removal of seedutil from macOS requiring to be logged in to an Apple account for access to developer seed beta updates to macOS has now enormously impacted our workflow for automation testing of our EndpointSecurity product. We regularly run integration tests to exercise features of our EndpointSecurity product to validate that We have not introduced regressions in to our code macOS updates (especially beta udpates) haven't changed something that results in previously unexpected behaviour We are now in a position where we're going to have to completely rebuild our Apple Silicon based VMs used for integration testing every time a new beta build is released, this also means having to join said VM to our MDM, and handle any other manual setup tasks required (such as providing user-approval for screenrecording in PPPC so that our integration suite can capture screenshots should any integration tests fail etc) I am enormously frustrated by this. My original request in my post above stands - please, please provide a solution for logging in to iCloud accounts in Apple Silicon based VMs.