Process: Xcode [41066] Path: /Applications/Xcode-beta.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 15.0 (22265) Build Info: IDEApplication-22265000000000000~3 (15A240d) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2023-09-13 09:13:53.6230 -0400 OS Version: macOS 13.5.2 (22G91) Report Version: 12 Anonymous UUID: 8FD0A40F-8939-D918-2E3C-DA44A4E72AE0 Sleep/Wake UUID: 3612D58F-129A-484C-9E23-54956E51A450 Time Awake Since Boot: 49000 seconds Time Since Wake: 2597 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: archive info plist lock Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: Xcode [41066] Application Specific Information: abort() called com.apple.main-thread Application Specific Signatures: (string) != nil Thread 0 Crashed:: Dispatch queue: archive info plist lock 0 libsystem_kernel.dylib 0x1808b8764 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1808efc28 pthread_kill + 288 2 libsystem_c.dylib 0x1807fdae8 abort + 180 3 IDEKit 0x107b1cd58 +[IDEAssertionHandler _handleAssertionWithLogString:assertionSignature:assertionReason:extraBacktrace:] + 972 4 IDEKit 0x107b1d198 -[IDEAssertionHandler handleFailureInMethod:object:fileName:lineNumber:assertionSignature:messageFormat:arguments:] + 872 5 DVTFoundation 0x1033c19a8 _DVTAssertionHandler + 424 6 DVTFoundation 0x1033c1b28 _DVTAssertionFailureHandler + 196 7 DVTFoundation 0x1032843d4 +[DVTFilePath _filePathForParent:pathString:] + 360 8 DVTFoundation 0x103284b20 -[DVTFilePath filePathForRelativePathString:] + 48 9 IDEFoundation 0x1096e686c -[IDEArchive _embedPackageFromDistributionRecord:error:] + 312 10 IDEFoundation 0x1096e6ea4 __36-[IDEArchive addDistribution:error:]_block_invoke + 56 11 libdispatch.dylib 0x180740400 _dispatch_client_callout + 20 12 libdispatch.dylib 0x18074f97c _dispatch_lane_barrier_sync_invoke_and_complete + 56 13 DVTFoundation 0x103408014 DVTDispatchBarrierSync + 148 14 DVTFoundation 0x1033e42b4 -[DVTDispatchLock performLockedBlock:] + 60 15 IDEFoundation 0x1096e6d30 -[IDEArchive addDistribution:error:] + 200 16 IDEFoundation 0x10938c2f0 __35-[IDEDistributionUploadStep upload]_block_invoke.115 + 116 17 DVTFoundation 0x103407330 __DVT_CALLING_CLIENT_BLOCK__ + 16 18 DVTFoundation 0x103407b08 __DVTSyncPerformBlock_block_invoke + 68 19 CoreFoundation 0x1809ce1d4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 20 CoreFoundation 0x1809ce0e8 __CFRunLoopDoBlocks + 364 21 CoreFoundation 0x1809cd58c __CFRunLoopRun + 2432 22 CoreFoundation 0x1809cc4b8 CFRunLoopRunSpecific + 612 23 HIToolbox 0x18a21edf0 RunCurrentEventLoopInMode + 292 24 HIToolbox 0x18a21ec2c ReceiveNextEventCommon + 648 25 HIToolbox 0x18a21e984 _BlockUntilNextEventMatchingListInModeWithFilter + 76 26 AppKit 0x183bf397c _DPSNextEvent + 636 27 AppKit 0x183bf2b18 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716 28 DVTKit 0x103c88a9c -[DVTApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 300 29 AppKit 0x183be6f7c -[NSApplication run] + 464 30 DVTKit 0x103c87cbc -[DVTApplication run] + 60 31 AppKit 0x183bbe3cc NSApplicationMain + 880 32 dyld 0x180597f28 start + 2236 (rest snipped to fit within character limitations)

Oddly enough I haven't been able to get it to do it with a minimal test case yet. It must be something about my gargantuan project :-/ I went ahead and submitted the report as FB12287778 anyway, because I really do think that just making localization only compile the active architecture would be more efficient anyway. I may try a few more times to get a test case made over the weekend, but time is tight. Also: I don't know if Apple engineers have edit access, but if you do, and if you could fix that "compex" typo in the thread title, I'd greatly appreciate it. :-)

Okay, so for the benefit of the next person who runs into this, here's the steps I ended up using to defuse this: Download and run the Monterey 12.4 installer. Select the hard disk for the installation. When the installer displays the progress bar with 30ish minutes remaining, it's setting up the install partition, and thus overwriting the one that Ventura set up. Click Cancel in the installer. Check less /System/Volumes/Update/mnt1/System/Library/CoreServices/SystemVersion.plist to make sure the partial boot partition has an incomplete 12.4 on it, and not 13.0 anymore. Reboot. Hold your breath while the system tries to install the OS. Since the boot partition was incomplete, I arrived at my usual Monterey 12.4 setup, with the boot partition having apparently been deleted, and all well other than the hours I spent trying to avert disaster. Not Cool, Apple. Don't trick users into accidentally installing a beta OS.

Yeah, if it's just straight up expecting no more than 3 buttons, that's definitely a problem, because the old horizontal layout version of NSAlert always handled this just fine...

To me, this seems like a tooling issue, rather than a code-level support issue, but I suppose that my code-level incidents for this year will expire soon anyway, so may as well use them. Here is the number of a code-level DTS incident that I just opened: 789609043

Sorry for taking so long to respond; in the meantime, Xcode 13.2 came out, and I wanted to have time to test it properly to see if it might fix the problem I was complaining about (unfortunately, it did not). I actually created a DTS incident a few days before making this thread; the number is 101572491467. I created the thread because I wasn't seeing a lot of traction there. I have a new Xcode crash report that I can also e-mail to you privately, if desired; else, it should now be attached to the referenced DTS incident.

I’m sure that someone, somewhere at Apple will have access to this. However, there’s no easy way for me to map your details to such reports (data privacy and all that). If you can post that crash report here, that’d be grand. Sure thing; I've e-mailed the crash report privately to your e-mail address so I don't have to go through and redact any private details of my machine from it. :-) What sometimes works is to use xcrun xcodebuild -exportArchive. When that fails, how does it fail? Crashing as well? Or something else? Frustratingly, I can't seem to reproduce this with xcodebuild -exportArchive today. In the past, a lot of the times this one has failed have been when running as part of my post-archive script, which famously doesn't show a lot of the output. So I'm not 100% on what was going on there, although if I had to hazard a guess, I'd guess that the xcodebuild tool is probably crashing in the same way that the GUI app does. If I can get this one to occur again, I'll update with more details. What does the following report for the app that you submit to the notary service? % codesign -v -vvv --deep Pacifist.app $ codesign -v -vvv --deep Pacifist.app ( ... bunch of "prepared:" and "validated:" lines that were causing this post to be over the character limit ... ) Pacifist.app: valid on disk Pacifist.app: satisfies its Designated Requirement The odd thing about this particular build is that this very build passed the notarization process (via xcodebuild -exportArchive) earlier today. Fails every time with notarytool, though, and crashes the GUI if I try it there. ps Love your app! Ironically, it’s an important tool in my toolbox when debugging notarisation issues for third-party developers (-: :-)

I should add the specific error that the notary service is complaining about: $ xcrun notarytool log eaa1e96e-38d0-4d6d-ad0f-bc58564b7eca --apple-id ##redacted# --team-id HRLUCP7QP4 Password for ##redacted##: { "logFormatVersion": 1, "jobId": "eaa1e96e-38d0-4d6d-ad0f-bc58564b7eca", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "Pacifist.zip", "uploadDate": "2021-12-11T17:52:07.189Z", "sha256": "c589ce3b11429ebfc3f343c77053df3416438c11bad690f0ca1307aee585529e", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "Pacifist.zip/Pacifist.app/Contents/MacOS/Pacifist", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "Pacifist.zip/Pacifist.app/Contents/MacOS/Pacifist", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "arm64" }, { "severity": "error", "code": null, "path": "Pacifist.zip/Pacifist.app/Contents/XPCServices/PacifistXPCService.xpc/Contents/MacOS/PacifistXPCService", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "Pacifist.zip/Pacifist.app/Contents/XPCServices/PacifistXPCService.xpc/Contents/MacOS/PacifistXPCService", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "arm64" }, ( ... repeat for every other binary in the app ... ) However, as we've seen above, both codesign -vv and spctl seem to think the signature is fine 🤷‍♂️

Hi all, Turns out that the custom superclass of my custom button class had an alignmentRectInsets override that I forgot was in there. 🤦 Leaving this here in case anyone else runs into the same problem.