Thank you! Would love to see these kinds of posts for any new releases too :)

Got it. ❯ xcodebuild -downloadComponent metalToolchain Beginning asset download... Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData/Restore/022-17211-415.dmg Done downloading: Metal Toolchain 17A324. ❯ xcodebuild -importComponent metalToolchain [1] 72228 trace trap xcodebuild -importComponent metalToolchain

From gpt-5 with max context after explaining the situation and using the test project's code as context: APNs registration in iOS Simulator does not reliably work in virtualized macOS (GitHub Actions VMs, Anka, etc.). The simulator’s APNs path depends on host hardware services that aren’t fully available/exposed in VMs, so callbacks may never arrive (neither success nor failure). This matches your observation that it always works on bare metal but never in the VM. Simulator APNs registration does not consistently work in virtualized macOS. Validate notification UI/delivery in CI without APNs. Use xcrun simctl push to inject a notification payload locally (no device token required). Your permission UI test already handles the prompt.

By default Anka VMs have SIP and Firewall disabled. I can reproduce on a vanilla macOS VM using the latest 16.4 Xcode, Simulators etc. I don't see any ~/Library/Logs/CoreSimulator/ logs indicating a problem there. I've generated a sysdiagnose from the VM right after reproducing the issue which should be helpful for the Apple team: https://drive.google.com/file/d/1tkbnm8bxuJwlAoAU6-0u1_v-LeQpt95D/view?usp=sharing

Nevermind, I had to security unlock-keychain first

Looks like it may be fixed in 15.3 Mac-mini:~ anka$ xcrun simctl list devices --json | head { "devices" : { "com.apple.CoreSimulator.SimRuntime.iOS-18-2" : [ { "dataPath" : "\/Users\/anka\/Library\/Developer\/CoreSimulator\/Devices\/DE110594-CF92-470F-B10E-5636C4CD9EBC\/data", "dataPathSize" : 18337792, "logPath" : "\/Users\/anka\/Library\/Logs\/CoreSimulator\/DE110594-CF92-470F-B10E-5636C4CD9EBC", "udid" : "DE110594-CF92-470F-B10E-5636C4CD9EBC", "isAvailable" : true, "deviceTypeIdentifier" : "com.apple.CoreSimulator.SimDeviceType.iPhone-16-Pro",

Bump, same here.

Veertu has built Anka Virtualization to get as close as possible to Docker/containers as possible on macOS (intel and arm). You can use it to run ephemeral macOS VMs from templates of different version of macOS. We have plugins for almost all of the commonly used CI/CD platforms, like Jenkins, Github Actions, etc.

Bug number: FB16084148

Just to clarify a bit -- When running through Virtualization on Intel, it looks as if any xcrun simctl list devices --json or other simulator related command is throwing the AVPIdentity errors. This, obviously, breaks json parsing and any tool that parses it. We see the simctl errors in the Console logs too, but are unsure where they're coming from or what could be missing here to cause it. We're looking for some guidance from Apple about the issue either: how to hide the log messages, or how to prevent them from happening at all by modifying the OS in the VM. Also, this does not seem to happen on 14.x VMs, so this was something introduced in 15.x.

Another quick note: It looks as if the length it takes to eventually timeout/proceed differs between networks. In a corporate network behind a different proxy, it cannot be worked around by waiting for 15/19minutes like I can locally. Sometimes it's double that.

OK, after 15 minutes it finally allows me to go to the siri screen. Here are the logs from that time: Very odd...

Lots of different requests to apple urls from the squid proxy logs and I'm not sure if they're even related or not... 1730834097.486 610093 192.168.1.79 TCP_TUNNEL/200 4681 CONNECT o22381.ingest.sentry.io:443 - HIER_DIRECT/34.120.195.249 - 1730834054.010 120115 192.168.1.79 TCP_TUNNEL/200 8605 CONNECT swdist.apple.com:443 - HIER_DIRECT/23.213.44.215 - 1730834272.626 1387 192.168.1.79 TCP_TUNNEL_ABORTED/200 14481 CONNECT weatherkit.apple.com:443 - HIER_DIRECT/23.47.52.133 - 1730834267.351 67 192.168.1.79 TCP_TUNNEL/200 22175 CONNECT init-p01md.apple.com:443 - HIER_DIRECT/23.220.102.59 - 1730834267.381 97 192.168.1.79 TCP_TUNNEL/200 16394 CONNECT init.ess.apple.com:443 - HIER_DIRECT/17.253.7.133 - 1730834309.963 42 192.168.1.79 TCP_MISS/200 256 GET http://netcts.cdn-apple.com/ - HIER_DIRECT/23.38.189.98 text/html 1730834310.772 17 192.168.1.79 TCP_MISS/200 256 GET http://netcts.cdn-apple.com/ - HIER_DIRECT/23.38.189.98 text/html 1730834344.022 117504 192.168.1.79 TCP_TUNNEL/200 49043 CONNECT developer.apple.com:443 - HIER_DIRECT/17.253.23.201 - 1730834346.178 443467 192.168.1.79 TCP_TUNNEL/200 4645 CONNECT github-partners.slack.com:443 - HIER_DIRECT/3.134.44.134 -

I can reproduce it by: Block all internet traffic to my MBP but allow all LAN Set up squid proxy on another machine on the LAN Set my http/s_proxy envs in the shell, set System Preferences > Network > ETH Proxy settings to the proper IP and port of the squid proxy. This allows me to tunnel through the squid proxy and reproduce the issue easily without a corporate proxy setup.

iCloud login inside of Anka VMs work great if they are Silicon/arm. On Intel, we see This is on 15.1 host and 15.1 VM.