There are a couple of partial solutions here: https://stackoverflow.com/questions/75175699/get-human-readable-name-for-mac-model-on-ventura

I'm not sure if this counts as getting it "programmatically", but you can get this information using the command line tool system_profiler. (You can run a command line tool programmatically using the Swift class Process or the Objective-C class NSTask.) For instance if you parse the output of the command system_profiler -detailLevel mini -json and look for the key SPHardwareDataType, and within that machine_name, you'll find the friendly name. This will be the first part, like "MacBook Pro". The less friendly model name is under the key path SPHardwareDataType.machine_model. But I don't know how to get the user-friendly second part like "15-inch, 2018".

Bug report submitted, FB15657061

@DTS Engineer I am a little confused by your mentions of LSUIElement=0 and LSUIElement=1 in your numbered list. Do you have them backward maybe? As I read the docs, the plist key LSUIElement has a boolean value, and the true value means that the app does not appear in the Dock, as in your case 2. So case 2 should say LSUIElement=1, right?

I've gotten rid of the assertion failure, but I can't say I understand how. I had code that retrieves a view pointer via a void* output parameter of a library function, like so: NSView* theView = nil; Q3Object_GetProperty( inDC, 'PWin', sizeof(void*), nullptr, &theView ); When I changed it to the following code, the error went away: NSView* theView = nil; void* rawViewPtr = nullptr; Q3Object_GetProperty( inDC, 'PWin', sizeof(void*), nullptr, &rawViewPtr ); theView = (__bridge NSView*) rawViewPtr;

After more fooling around with deleting builds, deleting the copy from the App Store, and so forth, the problem no longer reproduces. So, that's good, I guess, but I'm not in the position of being able to file a useful bug report. But to answer your questions: The helper is an app bundle with LSBackgroundOnly set true in its Info.plist. I launch it using NSWorkspace. I granted permission to the helper, not the main app. Since the helper is background only, not a LSUIElement, I'm not sure that what you're saying there is relevant.

Well, now I'm seeing everything get deallocated properly, and I'm not even sure what I did wrong before, maybe looked at memory at a breakpoint that was too early. But thanks for the reply!

I tried it in Objective-C, and it does work, but it's not super obvious how it works. If you look up NSDirectoryEnumerationIncludesDirectoriesPostOrder in the header, comments say: NSDirectoryEnumerationIncludesDirectoriesPostOrder causes the NSDirectoryEnumerator to enumerate each directory a second time after all of its contained files have been enumerated. Use NSDirectoryEnumerator.isEnumeratingDirectoryPostOrder to differentiate a post-order enumerated directory from a pre-order one. What this means is that the enumerator visits a directory, then visits the contents of the directory, and then visits the directory again, and the second time, the isEnumeratingDirectoryPostOrder property of the enumerator is true. Maybe you should file a feedback about the documentation.

Correction: In order for the softwareupdate tool to find the Sequoia beta, you must have the Sequoia beta update channel turned on:

Thanks for your reply, but I'm not actually asking for help in interpreting this particular crash log. As I indicated in my first post, I have already used the atos command line tool to figure out the symbols in my app involved in the crash. I was just wondering whether there is an easier way to handle future crash logs. The links you provided for symbolicating crash reports using Xcode does not appear relevant to Mac crashes. It says "click the Device Logs button in the Devices and Simulators window, then drag and drop the crash report file into the list of device logs", but I have nothing under Devices, and in particular no Device Logs button.

It turns out it is possible to get a full installer for the Sequoia beta: softwareupdate --fetch-full-installer --full-installer-version 15.0 And running that installer, I didn't get the weird error.

Tried to install Sonoma on an empty volume a couple of times, and got this: My Internet connection was good enough to download the installer. Maybe everyone is doing this and the server is overloaded?

It was suggested that maybe the control gets deallocated on a thread other than the main thread, but I set things up to write to a log file whenever an NSSegmentedControl gets a dealloc message off the main thread, and that's not happening.

I'll be darned, thank you very much for the documentation link!

Thanks for the additional information, which I assume is all undocumented except the part about Finder info using bigendian order.