I should also clarify that when I said "This performance difference happens even when I use a version of my application that was built with Xcode 12.4 on an older Mac running Catalina", I meant that I built my application with Xcode 12.4 on an older Mac (since you can't run older versions of Xcode on Monterey) and ran that application on both Big Sur and Monterey and still got the slower results.

I should've pointed out that I don't distribute from the Mac App Store but outside of it. I use a Developer ID certificate to sign my app and an installer certificate to sign my app's installer. I just noticed another annoying thing. The pro version of my app uses a shared library that's placed in the Resources folder of the app bundle. But now that I can't use the MacOS folder of the app bundle as a build location for my console and shared library versions, they don't have access to the necessary shared library from the Resources folder and Xcode is creating a separate Resources folder for them. All this because the modern build system treats shared folders being created by different targets as an error. I'm not sure Apple is putting too much effort in supporting those of us who don't wish to distribute via the Mac App Store in Xcode. I can still use the legacy build system but I just want to be prepared for when it's no longer available.

Here's another annoyance. To prevent myself from mistakenly shipping a debug build of my app(s), I have different product names for the debug and release builds. But in the Products group of my Xcode project, rather than Xcode listing products A, B, and C, products A Debug, B Debug, and C Debug are listed instead. Even if I go into the project.pbxproj file and manually remove Debug from the product names under the Products group, Xcode insists on putting Debug right back in the names. Not a big deal. However, with the modern build system, I also end up with extra empty app bundles A Debug.app, B Debug.app, and C Debug.app even though I'm just building release builds. This didn't happen with the legacy build system. A new annoyance with Xcode 13--while building, you no longer see the current target being built in the project status bar.

We use OpenMP because our application is a cross platform application. Having separate code in our computational engine isn't practical or economical at this time.

I have the exact same issue on a mini with an M2 Pro I use for testing betas. I've tried turning beta updates off/on, rebooting, etc.

Just to follow up on yevhenfromukraine's post since it's easy to miss the response that their solution worked, turning off Find My Mac and network did solve the problem for me.

Oof, as much as I'd like to, migration to Swift/SwiftUI is just not practical at this time. Our application is very big with a lot of distinct parts (think Xcode but with more parts) so this is not trivial to do even if it's one file at a time. I've got a team working on porting the Windows MFC version of our application to .NET and they've been working on it for 3 years and still aren't done! Our application is available for Windows, Mac, and Linux and one of the nice things about ObjC is that it can be mixed in with C/C++ code which makes writing multiplatform code very easy. I did look at perhaps writing all new GUI code in Swift a few years ago when it first came out but had problems with the ObjC and Swift bridging and gave up as I had more pressing things to work on.

LOL, they censored the word that's a synonym for abut and adjoin. Anyway, the buttons are right next to each other with no gap.

So prefersCompactControlSizeMetrics will use the compact size if you set it to true for the button. However, the documentation for prefersCompactControlSizeMetrics says When this property is true, any NSControls in the view or its descendants will be sized with compact metrics compatible with macOS 15 and earlier which I took to mean that I could set that property for a super view and all of its subviews would use the compact size which is not the case. I filed a bug.

This has been fixed in beta 4. prefersCompactControlSizeMetrics now works as expected.

I ended up grepping for 26 in the appkit headers and found in NSViewLayoutRegion.h + (NSViewLayoutRegion *)safeAreaLayoutRegionWithCornerAdaptation:(NSViewLayoutRegionAdaptivityAxis)adaptivityAxis; + (NSViewLayoutRegion *)marginsLayoutRegionWithCornerAdaptation:(NSViewLayoutRegionAdaptivityAxis)adaptivityAxis; This new header file was not mentioned in the macOS 26 release notes.