The AppleArchive module is pretty cool, but it relies almost entirely on two stream types, ArchiveByteStream and ArchiveStream, which don't really work well in a Swift Concurrency-based workflow since they all use thread-blocking mechanisms like pthread mutexes for synchronization, and threads in the cooperative pool should not be blocked. They also use their own thread pools for processing, independently of the cooperative thread pool, making it easy to end up with more threads than one has cores. (Perhaps even more so if you try to compress/decompress multiple files at once? The documentation isn't clear on whether separate archive operations share the same thread pool or not, but since it allows you to choose the size of the pool, it seems that these may be separate from each other as well.) Are there any plans for an interface to Apple Archive that would fit better with the structured concurrency model?

I've been waiting over an hour at this point—is something down or is the pipeline just really, really backed up?

Just wondering if anyone else is running into this; every time I try to notarize my app, Xcode crashes on the "Uploading" step. I've submitted a radar FB13163393 via Feedback Assistant with the full crash logs and other details.

Running on a Core i9 MacBook Pro with macOS 13.4 (22F66) and the Xcode 15 beta. Running "Export Localizations" seems to work fine with smaller projects, but in my larger project, it's not working unless I do a "Clean" first. The way my project is set up is that the main project depends on a few dynamic frameworks built from other Xcode projects which are incorporated into the main project and set as dependencies. What happens is that I'm getting the error "Unable to build project for localization string extraction. See the build logs for failure description." In the logs, I see that the Link (x86_64) step succeeds, but the Link (arm64) step fails, with a Could not find or use auto-linked framework 'MyFramework' message for each framework dependency that's in another Xcode project. This would suggest that the dependencies are being built only for x86_64. If I clean the project, the "Export Localizations" will then succeed, but if I do a regular build again, "Export Localizations" goes back to being broken. What I think is happening is that the "Export Localizations" workflow is using the same binaries as Debug builds, and leveraging any existing Debug builds that happen to exist instead of rebuilding them, but it's also trying to build for all supported architectures whereas a Debug build usually only builds the current one. This, of course, causes a failure to link to dependent libraries/frameworks, since they don't have binaries for the non-active architecture. Is there any way to turn off building for all architectures for the "Export Localizations" workflow? I don't think it's necessary just for localizations TBH.

So, like many other people, I've just been bitten by the Ventura update being a straight-up immediate installation instead of just downloading an install app that I can then use to install inside a Parallels VM. Fortunately, I had an app open that had a modal window active, which prevented the system from actually rebooting, so I haven't actually installed a beta OS on my production machine. However, the /System/Volumes/Update/mnt1 volume is still there on /dev/disk1s1, even after I reset the profile to the default in the Software Update prefpane, and I'm worried that I'm destined to install this the next time my machine restarts. Is there any way to get rid of this, so that it doesn't install the beta the next time I have to reboot my machine for some random reason?

This started happening this Thursday, and hasn't seemed to have gotten better since; every time I try to notarize my app, it fails. The app is signed: $ codesign -vv Pacifist.app Pacifist.app: valid on disk Pacifist.app: satisfies its Designated Requirement $ codesign -dvv Pacifist.app Executable=##redacted##/Pacifist.app/Contents/MacOS/Pacifist Identifier=com.charlessoft.pacifist Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=12004 flags=0x10000(runtime) hashes=364+7 location=embedded Signature size=9009 Authority=Developer ID Application: Charles Srstka (HRLUCP7QP4) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Dec 11, 2021 at 12:36:01 PM Info.plist entries=39 TeamIdentifier=HRLUCP7QP4 Runtime Version=12.0.0 Sealed Resources version=2 rules=13 files=428 Internal requirements count=1 size=216 $ spctl -a -v --raw Pacifist.app Pacifist.app: accepted <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>assessment:authority</key> <dict> <key>assessment:authority:flags</key> <integer>2</integer> <key>assessment:authority:row</key> <integer>6</integer> <key>assessment:authority:source</key> <string>Developer ID</string> </dict> <key>assessment:remote</key> <true/> <key>assessment:verdict</key> <true/> </dict> </plist> Looks good, right? But since Thursday, notarytool isn't having it: $ xcrun notarytool submit Pacifist.zip --apple-id ###redacted### --team-id HRLUCP7QP4 --wait Conducting pre-submission checks for Pacifist.zip and initiating connection to the Apple notary service... Password for ###redacted###: Submission ID received id: eaa1e96e-38d0-4d6d-ad0f-bc58564b7eca Successfully uploaded file77.6 MB of 77.6 MB) id: eaa1e96e-38d0-4d6d-ad0f-bc58564b7eca path: ###redacted###/Pacifist.zip Waiting for processing to complete. Current status: Invalid............. Processing complete id: eaa1e96e-38d0-4d6d-ad0f-bc58564b7eca status: Invalid Trying to export from Xcode's "Organizer" window actually crashes Xcode. I can provide the crash log upon request, although since I've clicked the "Send to Apple" button each time, this should be available for Apple engineers to look at. What sometimes works is to use xcrun xcodebuild -exportArchive. However, this is not 100%, and so far all the times that that has worked have been when I've run the tool by hand; for some reason, running as a post-archive action fails every time (I don't know if this is just a weird coincidence or not). The status page for Apple's services seems to be all green... What is going on? Is anyone else running into this same issue?

Has anyone seen something like this before? (lldb) po self.constraintsAffectingLayout(for: .horizontal) ▿ 5 elements - 0 : <NSLayoutConstraint:0x60000243f2f0 H:|-(NSSpace(20))-[MyApp.MyCustomButton:0x7fe67e83b000'Some Label'] (active, names: '|':MyApp.MySuperView:0x7fe68d7073f0 )> - 1 : <NSLayoutConstraint:0x60000243e1c0 H:[MyApp.MyCustomButton:0x7fe67e83b000'Some Other Label']-(NSSpace(20))-| (active, names: '|':MyApp.MySuperView:0x7fe68d7073f0 )> - 2 : <NSAutoresizingMaskLayoutConstraint:0x6000024046e0 h=-&- v=-&- MyApp.MySuperView:0x7fe68d7073f0.minX == 0 (active, names: '|':NSThemeFrame:0x7fe68d735be0 )> - 3 : <NSAutoresizingMaskLayoutConstraint:0x600002404730 h=-&- v=-&- H:[MyApp.MySuperView:0x7fe68d7073f0]-(0)-| (active, names: '|':NSThemeFrame:0x7fe68d735be0 )> - 4 : <NSLayoutConstraint:0x600002426a80 'NSWindow-current-width' NSThemeFrame:0x7fe68d735be0.width == 465 priority:500 (active)> (lldb) p self.frame (NSRect) $R1 = (origin = (x = 19.5, y = 19.5), size = (width = 426, height = 81)) It appears that per the constraints, this should be 20 pixels from the edge of the screen, but instead it's 19.5. As you may expect, this is causing the button to draw all blurry on non-Retina displays. Anyone seen anything like this before and/or know what sort of thing could cause something like this? Is there anything I should look for to debug this?

Given the code below: let alert = NSAlert() alert.alertStyle = .informational alert.messageText = "Foo" alert.informativeText = "Bar" alert.addButton(withTitle: "Foo").keyEquivalent = "\r" alert.addButton(withTitle: "Bar") alert.addButton(withTitle: "Cancel").keyEquivalent = "\u{1b}" // esc alert.runModal() The resulting alert looks like one would expect: However, add another button: let alert = NSAlert() alert.alertStyle = .informational alert.messageText = "Foo" alert.informativeText = "Bar" alert.addButton(withTitle: "Foo").keyEquivalent = "\r" alert.addButton(withTitle: "Bar") alert.addButton(withTitle: "Baz") alert.addButton(withTitle: "Cancel").keyEquivalent = "\u{1b}" // esc alert.runModal() And suddenly you get this: As you can see, the "Bar" and "Baz" buttons no longer get drawn (except when the mouse hovers over them), even though the "Bar" button draws perfectly normally when it's the only middle button. I Have Questions: Is this behavior intentional, or some kind of glitch? The pictures in the macOS HI Guidelines still seem to be showing the Yosemite-era layout, making it difficult to determine what these alerts are supposed to look like. If this is a glitch, is there a better way to work around it than messing with the NSButton display properties directly? If this is intentional... why? It's so weird looking...

Recently, I decided to try to experiment with NSFilePromiseProvider, in order to replace some legacy code that implements drag-and-drop from an outline view to the Finder using the old-fashioned drag-and-drop methods. The process seems simple enough; just have the outline view delegate’s -outlineView:pasteboardWriterForItem: method return an NSFilePromiseProvider. However, for some reason, when I drag something from the outline view to the Finder, the drag-and-drop system seems to completely ignore my NSFilePromiseProviderDelegate methods, and calls the old-fashioned -outlineView:namesOfPromisedFilesDroppedAtDestination:forDraggedItems: method instead. If it's not there, it throws an exception. What gives?I've reduced it down to a base-bones example, which you can see below:import Cocoa @NSApplicationMain class AppDelegate: NSObject, NSApplicationDelegate { @IBOutlet var outlineView: NSOutlineView? class Item: NSObject { @objc let name: String @objc let children: [Item] init(name: String, children: [Item] = []) { self.name = name self.children = children super.init() } } @IBOutlet weak var window: NSWindow! dynamic var items = [Item(name: "Foo"), Item(name: "Bar"), Item(name: "Baz", children: [Item(name: "Qux")])] func applicationDidFinishLaunching(_ aNotification: Notification) { self.outlineView?.setDraggingSourceOperationMask(.copy, forLocal: false) } } extension AppDelegate: NSOutlineViewDataSource { func outlineView(_ outlineView: NSOutlineView, pasteboardWriterForItem item: Any) -&gt; NSPasteboardWriting? { return NSFilePromiseProvider(fileType: kUTTypePlainText as String, delegate: self) } // If this method doesn't exist, an exception is thrown on drag func outlineView(_ outlineView: NSOutlineView, namesOfPromisedFilesDroppedAtDestination dropDestination: URL, forDraggedItems items: [Any]) -&gt; [String] { print("Why does this get called instead of my NSFilePromiseProviderDelegate methods?!") try! "foo".write(to: dropDestination.appendingPathComponent("foo.txt"), atomically: true, encoding: .utf8) return ["foo.txt"] } } extension AppDelegate: NSFilePromiseProviderDelegate { func filePromiseProvider(_ filePromiseProvider: NSFilePromiseProvider, fileNameForType fileType: String) -&gt; String { print("fileNameForType: got called with type \(fileType)") // is never logged return "foo.txt" } func filePromiseProvider(_ filePromiseProvider: NSFilePromiseProvider, writePromiseTo url: URL, completionHandler: @escaping (Error?) -&gt; Void) { print("writePromiseTo: got called with URL \(url)") // is never logged do { try "foo".write(to: url, atomically: true, encoding: .utf8) completionHandler(nil) } catch { completionHandler(error) } } }I mean, it works, but it works using the older system. I want it to use the modern system. Why won’t it?