Awesome! I knew it had to be simple because it just didn't make any sense that the installer would not be a universal binary.

Just to help others get started, this is what the top of my Installer.pkg/Distribution file now looks like: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <installer-script minSpecVersion="1.0"> &#9;&#9;<options customize="always" hostArchitectures="x86_64,arm64"/>

You can get a toolbar item to resize with the window if you set its maxSize to a high value which I've been doing for years. However, minSize and maxSize for toolbar items are deprecated in Big Sur. I was able to solve the text edit field height problem by using a height constraint but I still can't figure out how to get the edit field to resize its width with the window (or at least set it to use a larger default width). I could live with the current default size but I think I'm just going to live with the warnings that minSize and maxSize are deprecated until I can find a better solution.

To answer my own question, you're supposed to use constraints. I actually had tried adding constraints earlier but Interface Builder wouldn't let me add any to my existing existing text field. I found out later that it worked with a newly added text field so I just used that one and deleted my old one. You create a custom view and embed the text field in the custom view. You make the custom view the view for the toolbar item. You then add constraints such as align center X and align center Y. I added a constraint to set the text field height to 21. That fixed the problem where the toolbar item was shrinking my text field's height. You then add a constraint to make the text field the same width as the custom view. Finally, I added a constraint for its width and made it >= to the minimum size I wanted for the text field. Now my text field's width resizes as the window resizes.

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.