Thanks! I have another question now: how can I link multiple NSTextContentStorage to the same NSTextStorage? The documentation for NSTextContentStorage reads: By default, the framework initializes the NSTextContentStorage with NSTextStorage as the backing store. But I don't see any way of accessing or setting the NSTextStorage. If I'm not supposed to do so, then how can I programmatically change the text?

After a few more tests, I noticed that, while try source.checkResourceIsReachable() throws an error and FileManager.default.fileExists(atPath: source.path) returns false, calling open(source.path, O_RDONLY) returns a valid file descriptor if source is a directory; if it's a regular file, it returns -1.

Have you tried encoding the file name and creating url from it? No, since my app relies on the Finder to mount and connect to FTP volumes, so I can only use file URLs.

What if I have multiple parallel upload operations and need to map the URLSession in the delegate method to a progress indicator? Would I need a separate actor to manage this mapping?

If you implement the method -(BOOL)worksWhenModal to return YES on the target object for your menu item, AppKit will allow the menu item to be validated, and enabled if the target implements the item's action. Still doesn't seem to work for the sample code I provided. I had to leave the menu item's target to nil to make it work, but then using a normal window was enough, without the need to implement worksWhenModal. This is in fact the workaround I just found. If I leave the menu item's target to nil and make sure that the view of the view controller or a subview is first responder, e.g. with override func viewDidAppear() { view.window?.makeFirstResponder(view) } then the menu item is enabled. In my case it doesn't work though, since the view controller is a child of another view controller and it's not guaranteed that the view of the view controller showing the menu (and implementing the menu item actions) is first responder (as the parent can have other views that can be first responders). As soon as I set the menu item's target to self, the menu items are disabled again.

However, if the app is in a modal state, AppKit skips over item validation and always disables the item. Thanks for your feedback. Indeed, it seems that all menu items targeting a window or view controller are automatically disabled, while menu items targeting the app delegate can still be enabled, as well as the standard copy, paste, etc. I think the correct behaviour should be to still enable menu items targeting the modal window itself. I think you may have reported this issue with Bug Reporter as FB9190141? Yes, I opened FB9190141 2.5 years ago but got no response, which is why I decided to ask here. It would be great if you could investigate it. Also to everyone else who might be tempted to use NSMenu.popUpContextMenu(_:with:for:): provide a made-up NSEvent and don't rely on NSApp.currentEvent being non-nil. When using VoiceOver for instance, it's nil.

But NSUserScriptTask won’t find them there Then it's more like a limitation of how application scripts are designed to work, but I don't get it when you say that it doesn't make sense to have application scripts in an app group. App groups are meant to share data between apps, so why not application scripts as well? The fact that the Application Scripts directory is created automatically even for app groups adds to the confusion.

Why do you need to get this directory? For sharing scripts between apps. Why does it make sense to share any other data, but not Application Scripts? I was hoping that I could reduce user confusion by putting all shared data, including scripts, in one place (the app group).

Occasionally this warning turns into a compiler error when trying to archive the product. Then only deleting the DerivedData folder, restarting Xcode and archiving again turns it into a warning again.

By the way, I just had to learn the hard way that this code var blockSize = UInt32(16_777_216) if copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &blockSize) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } always throws on macOS 11 or older with a POSIX error 22: Invalid argument regardless of the provided block size. There's no mention of this in the documentation and I assumed that it would just work, but got bug reports from users running older systems.

And then I tested if copying a 1 KB file performs better with a 1'000 or 1'024 block size, and the first iteration of the whole test is always an outlier. Am I still doing something wrong?

It’s important when the buffer size is less than the file size because it keeps all transfers aligned within the file, which facilitates uncached I/O. Good, that's what I was aiming at: use a block size equal to the file size up to a maximum power of 2. I don't think I was really trying to optimize the buffer allocation time; rather it didn't feel right to allocate an arbitrarily large buffer. After all, space is constrained and there is a reason why we can specify the block size, or it would automatically be set to infinity... right? it’s time to benchmark and use that to guide your optimisation Here are my results when copying a file with a given size using varying block sizes and 5 repetitions. (Explicitly writing random data to the file makes the file creation quite slow, but simply writing a buffer with uninitialized data seems to work as well.) Different file sizes seem to follow a similar trend. Using a multiple of 1000 or a multiple of the page size also doesn't seem to make a difference in the overall trend. The lowest block sizes, 1'024 and 2'048, seem to be special and cause a very fast copy. From 4'096 upwards, the time decreases... ...up to 65'536, where it suddenly increases again, but from then it definitely decreases. The bigger the file, the higher the block size needs to be to notice a difference. With a 100 MB file, increasing the block size from 1'048'576 to 2'097'152 makes the operation about twice as fast, with little improvements above that block size. With a 1 GB file, increasing the block size from 1'048'576 to 8'388'608 makes the operation about twice as fast, with little improvements above that block size. Without using F_NOCACHE, the operation gets slowly faster when increasing the block size from 1'048'576, and then gets slower again from 8'388'608 upwards. Not sure if that means anything. Here are the graphs for a 100 MB and a 1 GB file. Copying a 100 MB file: Copying a 1 GB file: Copying a 100 MB file created without F_NOCACHE: And here is the code: class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { print("page size", getpagesize()) let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true openPanel.runModal() test(url: openPanel.urls[0]) } func test(url: URL) { let source = url.appendingPathComponent("file source") let destination = url.appendingPathComponent("file destination") let fileSizes = [1_000, 1_000_000, 10_000_000, 100_000_000, 1_000_000_000, 10_000_000_000, Int(getpagesize()) * 10_000] let blockSizes: [Int32] = (10..<31).map({ 1 << $0 }) let repetitions = 5 var times = [[TimeInterval]](repeating: [TimeInterval](repeating: 0, count: repetitions), count: blockSizes.count) for fileSize in fileSizes { print("fileSize", fileSize) for (i, blockSize) in blockSizes.enumerated() { print("blockSize", blockSize) let date = Date() for j in 0..<repetitions { try? FileManager.default.removeItem(at: destination) var date = Date() print("create", terminator: " ") createFile(source: source, size: fileSize) print(-date.timeIntervalSinceNow) date = Date() print("copy", terminator: " ") do { try copy(source: source, destination: destination, blockSize: blockSize) } catch { preconditionFailure(error.localizedDescription) } let time = -date.timeIntervalSinceNow times[i][j] = time print(time) } let average = -date.timeIntervalSinceNow / Double(repetitions) print("average copy", average) print() } let header = blockSizes.map({ NumberFormatter.localizedString(from: $0 as NSNumber, number: .decimal) }).joined(separator: "\t") try! Data(([header] + (0..<repetitions).map { j in (["\(j)"] + (0..<blockSizes.count).map { i in return timeToString(times[i][j]) }).joined(separator: "\t") }).joined(separator: "\n").utf8).write(to: url.appendingPathComponent("results \(fileSize).tsv")) } } func timeToString(_ time: TimeInterval) -> String { return String(format: "%.6f", time) } func createFile(source: URL, size: Int) { var buffer = UnsafeMutableRawBufferPointer.allocate(byteCount: size, alignment: Int(getpagesize())) // for i in 0..<size { // buffer[i] = UInt8.random(in: 0...255) // } let fp = fopen(source.path, "w") let success = fcntl(fileno(fp), F_NOCACHE, 1) assert(success == 0) let bytes = fwrite(buffer.baseAddress!, 1, size, fp) assert(bytes == size) fclose(fp) } func copy(source: URL, destination: URL, blockSize: Int32) throws { try source.withUnsafeFileSystemRepresentation { sourcePath in try destination.withUnsafeFileSystemRepresentation { destinationPath in let state = copyfile_state_alloc() defer { copyfile_state_free(state) } var blockSize = blockSize if copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &blockSize) != 0 || copyfile_state_set(state, UInt32(COPYFILE_STATE_STATUS_CB), unsafeBitCast(copyfileCallback, to: UnsafeRawPointer.self)) != 0 || copyfile_state_set(state, UInt32(COPYFILE_STATE_STATUS_CTX), unsafeBitCast(self, to: UnsafeRawPointer.self)) != 0 || copyfile(sourcePath, destinationPath, state, copyfile_flags_t(COPYFILE_ALL | COPYFILE_NOFOLLOW | COPYFILE_EXCL)) != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } } } } private let copyfileCallback: copyfile_callback_t = { what, stage, state, src, dst, ctx in if what == COPYFILE_COPY_DATA { if stage == COPYFILE_ERR { return COPYFILE_QUIT } } return COPYFILE_CONTINUE } }

Do you imagine that it somehow reads beyond the end of the file on the disk until it reaches the block size you have specified? In case you're wondering why I don't simply use a fixed block size of 16_777_216: I thought that the larger the allocated space, the more time it would take to allocate it, and the less space would be available to the rest of the system while the copy is in progress. It may be a negligible time difference, but since I can avoid it with a very simple calculation, why not do it?

I'd be amazed if that made any difference. Why? It sets a block size of 16 MiB for files that are larger than 16 MiB, or uses the file size itself for files that are smaller.

Things will go better if your block size matches the allocation block size of the underlying volume Thanks again for your input. To clarify the "things will go better" part: does that mean that providing a block size that doesn't match can impact performance? Should I make sure to calculate the next multiple of two bigger than the file size to copy (with a maximum threshold of course), or can I simply do this: var bsize = Int32(16_777_216) if let size = Int32(exactly: file.size) { bsize = min(size, bsize) }