Can confirm it also affects CPU profiling on macOS on Apple Silicon. macOS 15.3, Xcode 16.2, M4 Pro Edit: https://stackoverflow.com/questions/79311572/kpc-config-sysctl-call-returns-1-in-ibiremes-kpc-demo-on-m4-apple-silicon Thanks, Apple! Looks like it's broken on the M4 too.

Now that Sequoia is out, you'll be forced to use Xcode 16. Try that and see if they didn't keep it broken?

Xcode 15 beta 3 and newer (including the current beta 5) fails to link certain x86_64 objects. It also fails to link libbass and friends from un4seen.com, unless they are built to target macOS 10.6 or newer. The current public distributions of those are built with Xcode 8 and target 10.5 or newer. The same problem may apply to code built with non-Xcode versions of GCC or Clang. This appears to be a regression in Xcode, which I have reported as FB 12698037. Though they may just close it as intentional behavior, in which case, say goodbye to compatibility for who knows how long.

It seems I was able to work around this issue, by actually opening a project first before attempting to attach to something.

And how do I set a minimum size for a toolbar item with a slider control in it? I want a minimum size, but I want it to be able to get wider than the minimum size on its own. If I don't set a minimum size, the toolbar shrinks the slider to as small as 32px wide, which I don't want.

This whole thing raises the point as to whether it is even worth running the betas at all if you're a developer. If you're a developer, you need to release your app to the App Store on a regular basis, and you can't do this with a beta. So why even bother testing it? I cannot take a four month vacation from releasing app updates, and dual booting is inconvenient when I actually have to use the machine, as I'd rather spend time using the OS I can actually develop from.

I solved my Xcode Cloud issue, but dual booting is not really that useful of an option. I have the 256GB storage option, which is criminally small.

I have this issue randomly with Xcode 13.4.1 under macOS 12.4 on Apple Silicon, debugging a Mac app, not Rosetta. Breaking the app shows the main thread is stuck in a function called uniquing_table_stack_retain, underneath of an NSWindow function. The rest of the app is non-responsive. The only thing I've found to fix it is to completely terminate the debug session and hope the next one doesn't get stuck. I should mention that my hangups mostly happen when debugging with full Guard Malloc and Malloc Scribble enabled for the run, which also has a huge impact on memory usage and allocation overhead, both used memory and time to allocate.

Whee, I guess I shouldn't allocate temporary audio buffers on the stack. Fixed.

Oh, I forgot, that function has some significant stack usage.

For some reason, a function that has barely any local variables incurs a local stack frame difference like this:       sp = 0x000000016ec7eb40       sp = 0x000000016ebfea40

Oh, drat. I have to --unshallow the repository to get the commit counts. I hope that works.

Okay, nope, it needs to be in the pre xcodebuild script, since the submodules aren't fetched yet.

Okay, I figured out what was wrong. Xcode Cloud build system isn't fetching the tags in my repository when pulling it. So I need to add a git fetch --tags to the post clone script.

Incidentally, it's also not possible to maintain a beta install on a primary development machine if you develop for the App Store, as the beta does not support stable Xcode, and the beta, like all betas in the past, cannot be used to publish to the App Store, unless you use Xcode Cloud to build using a stable version. And I find I cannot use Xcode Cloud, because it messes with my app's Info.plist bundle version in unpredictable ways. I cannot get it to build consistent versioning. I use a template Info.plist and generate the version number from the Git repository at build time, and Xcode Cloud ignores this and stamps the Info.plist with its own decided version string, even one which is incompatible with the App Store, as it contains letters. (It uses the first five of the Git hash as the version string, ignoring my chosen version template of commit number since a specific tag.)