FWIW - it appears I can no longer replicate the issue on 14.5 (23F79) and either Xcode 15.3 or 15.4 on two different Macs.. Fingers crossed!

Thanks for the feedback but not that straightforward I'm afraid - it's broken in Sonoma debug builds only, happening mostly for Umlauts in filenames as entered by the user, I'm not 'in the loop' here -> all AppKit (Save as -> user enters filename -> NSWindow shows broken document title) And, weirdest of all as mentioned: Only current Xcode on Sonoma in debug mode. Cheers, Jan

This Xcode bug is known and has been reported in Aug 2023… https://github.com/apple/swift/issues/68163

This bug occurs with Xcode 15.2 and 15.3. The same project compiled with Xcode 14.2 (14C18) on macOS 12.7.4 creates a binary that does not reference SwiftUI, all good and as expected. No idea why Xcode thinks that SwiftUI is required. The word SwiftUI occurs exactly twice in my build log, both: export LOCALIZED_STRING_SWIFTUI_SUPPORT\=YES

..same happening for labels (plain NSTextFields) in some views:

@kemalenver Thanks for the feedback. The fact that Apple seems to have removed most SceneKit WWDC videos is worrying to me, though. Sounds like a pre-deprecation warning… Cheers, Jay

Swift has been released 10 years ago - is there still no way to check for an SDK version at compile time..? Hard to believe.

Interesting! Thanks for your insights. I could fix the compiler error that starts popping up with Xcode 15.3 by switching to a lambda, i.e. auto isEmpty = text.empty() || std::all_of(text.begin(), text.end(), [](const auto& c) { return std::isspace(c); }); though I can't see any reason why the original code should stop compiling under the latest compiler version... Cheers, Jay

FWIW the required includes - algorithm, string, ctype - are all #included, and as mentioned this compiles fine in all previous Xcode versions…

Right... crickets. So I suppose the gist of it is then SceneKit == dead RealityKit == modern, future-proof replacement Yes? Could anybody from the mothership please provide any kind of guidance.. Cheers, Jay

It appears in my case - after switching the size mode to 'Automatic' for all items - a stray NSToolbarSeparatorItem (deprecated) was causing the warning. After removing the NSToolbarSeparatorItem the warning was gone.. Cheers, Jay

..anytime soon now, yes? Cheers, Jay

FWIW a clean re-install (removal of app plus all data, e.g. via LaunchPad) eventually resolved the issue with macOS Ventura for our users... Cheers, Jay

My bad - NSPrintInfo.sharedPrintInfo is different from NSPrintOperation.currentOperation.printInfo Cheeky! Cheers, Jay

Interesting idea - I'll give it a try and report back. Cheers, Jay