Thanks for the update. After updating to macOS 26.6 and installing the additional components that Xcode 27 beta prompts you to install when launching it for the first time, I was able to create a VM of the newest macOS 27 beta in virtualOS (found on the App Store).

See? That's what I meant. Already the mention of an unspecified "magic user default" tells me that I shouldn't bother messing with this. If even an Apple employee doesn't have the time or energy to share the necessary steps that anyone could follow without having to do "research", imagine how willing a third-party developer must be. The cumulative millions of hours spent globally to figure this out, each one on their own... I would be happy to test if issues are fixed. Right now I feel like Apple doesn't value my time.

How you created that VM is what I'd like to have confirmed. Should I use this VirtualBuddy app? Is that app actually enough? In the link I read that one needs to actually create the VM on a macOS 27 host, but again, I haven't been able to install macOS on separate partitions in the past years, and installing it on separate hardware is out of the question for me.

I wasn't looking for advice for a specific product. I was just wondering since installing macOS on a separate partition doesn't work, and the Virtualization framework currently doesn't work either... what's the official way of installing macOS 27? Are we really supposed to have dedicated hardware for that, separate from our working machines?

The release notes have now been updated to point to this page: https://developer.apple.com/support/xcode/ It shows indeed that the minimum deployment target for macOS 27 is macOS 12-27. But I have doubts that it's the correct information. That page also shows that the deployment target of Xcode 26 is macOS 11-26.5, but I have been using Xcode 26 with a minimum deployment target of 10.13 for many of my App Store apps. How is this possible?

I skimmed through this post but I'm not sure there are official steps to install macOS 27 yet for those poor developers who don't have separate machines for macOS betas. I'm getting pinged by Feedback Assistant to verify bugs apparently fixed on macOS 27, but when asked if there is a way to test them without spending thousands of dollars on new hardware, their reply is that "We're confident that you can figure out steps for yourself". What a forthcoming answer. Not only did I invest my time in creating feedbacks to help Apple fix bugs in their own software, but now I also have to invest time in figuring out workarounds on how to test them. I already mentioned before: installing new macOS releases on a separate partition hasn't been working for the last few years anymore, as I pointed out last year (nobody answered), and now that the official virtualization framework doesn't work either, it's never been more frustrating to test feedback reports: https://developer.apple.com/forums/thread/799898 Could someone from Apple confirm if there is an official way of installing macOS 27 without having to buy new hardware (and possibly without resorting to time- or money-consuming workarounds), and if there currently is not, to let us know when there will? And pleeease... hold back those Feedback Assistant pings until there is an official way to test the reports.

I thought I had found a solution with the official virtualization framework (I use the app virtualOS on the App Store). But there seems to be a bug in the virtualization framework that prevents creating macOS 27 VMs. Can Apple provide any official steps on how to install macOS 27 without spending thousands on dollars on new hardware?

I just had a suspicion this might be an issue with Swift itself, so I split the tuple private var skQueue = (queue: DispatchQueue(label: "skQueue", qos: .userInteractive), updates: [() -> Void]()) into two separate instance variables: private var skQueue = DispatchQueue(label: "skQueue", qos: .userInteractive) private var skQueueUpdates = [() -> Void]() then updated the rest of the code accordingly, and the crash seemed to disappear. Does anyone have an explanation for this?

I even added the following lines in GameViewController to check that the class it not deinitialized: deinit { print(0) // never printed, nor is a breakpoint at this line ever hit }

I would truly appreciate some feedback on my approach above. At first, it seemed to reduce the number of crashes. Now I would like to use it in more places in my code to hopefully reduce the number of crashes even further... but instead I get another crash that I'm able to reproduce about 50% of the times I launch my game. The crash happens at the line skQueue.updates.append(block) // crash: Thread 9: signal SIGABRT The Xcode console prints the following warning twice: Object 0xc1b5c9e00 of class _ContiguousArrayStorage deallocated with non-zero retain count 2. This object's deinit, or something called from it, may have created a strong reference to self which outlived deinit, resulting in a dangling reference. If I show the Memory Graph, search for the address 0xc1b5c9e00 in the Debug Navigator and select the search result, the Memory Graph seems to confirm that the address is in fact some private storage belonging to the skQueue.updates array. How could this crash happen, if skQueue.updates is only ever modified in those two places shown in the code above, both of which are run in a queue , as far as I know, sequentially?

Thanks, I'll try NWPathMonitor as a workaround. And to clarify, this issue is caused by setting the authentication handler, but the handler is not even called when the alert is presented, so there's no way to manipulate the view controller.

I tried creating a macOS 27 VM as well and it failed. I would try to install it on a separate partition, but the last few years I haven't been able to install macOS on separate partitions anymore, as I pointed out last year (nobody answered): https://developer.apple.com/forums/thread/799898

It works for me too.

Thanks. If in the meantime you should happen to know why Xcode crashes, e.g. because of some configuration of the repository, please let me know, so that I can see if I can find a workaround and go on with publishing it without having to wait for the next Xcode update.

Thanks, I'll do that, although I'm not very hopeful that I'll get the crash again soon (while I've been observing the crash reports downloaded by Xcode for many months). Just to be clear, should I then extract the sysdiagnose and look in the system_logs.logarchive file? In the sysdiagnose I uploaded to Feedback Assistant I can only see the last 5 minutes, is that correct?