FB17103305 seems to be fixed in macOS 27, so overriding shouldDrawInsertionPoint to always return false hides the default insertion point. But now the question is, how should I draw my own insertion point? Regardless whether shouldDrawInsertionPoint is true or false, overriding drawInsertionPoint(in:color:turnedOn:) and just calling super with a different color or frame doesn't change the insertion point's appearance.

[quote='902221022, DTS Engineer, /thread/842708?answerId=902221022#902221022'] this behavior should only reproduce on larger devices where there is still a Split View Controller sidebar [/quote] Thanks, so do you mean on iPads? But if the navigation bar of the sidebar disappears on iPads, that would still be a problem. Why would it be expected on iPad but not on iPhone?

I just created FB24231156.

Unfortunately I found another issue with this approach. Until now I thought that adding, modifying and removing nodes should be done inside updateSpriteKit. But I hadn't tested my code on iPad yet... on iPad (not on iPhone!), calling removeFromParent() causes a crash: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Call must be made on main thread' Wrapping that method in Task { @MainActor in {} avoids the crash. This is a problem, because if I have to add a node in one thread (with updateSpriteKit) and remove it from another thread (the main thread) within a short time interval, there's no guarantee that they will be executed sequentially, so I might end up removing the node first (without effect, since it's not in the scene yet) and adding it to the scene shortly later. In my case, the time interval between adding and removing the node can be influenced by the user, so it might be a fraction of a second.

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.