In my previous post I asked why copyfile is slower than the cp Terminal command. In this other post I asked how I can make copyfile faster by changing the block size. Now I discovered that the cp implementation on macOS is open source and that when copying regular files it doesn't use copyfile but fcopyfile. In a test I noticed that fcopyfile by default seems to be faster than copyfile. When copying a 7 GB file I get about the same results I observed when comparing filecopy to cp: copyfile: 4.70 s fcopyfile: 3.44 s When setting a block size of 16_777_216, copyfile becomes faster than fcopyfile: copyfile: 3.20 s fcopyfile: 3.53 s Is this expected and why is it so? I would have expected that they both have the same performance, and when changing the block size they would still have the same performance. Here is the test code. Change #if true to #if false to switch from fcopyfile to copyfile: import Foundation import System let source = "/path/to/source" let destination = "/path/to/destination" #if true let state = copyfile_state_alloc() defer { copyfile_state_free(state) } //var bsize = 16_777_216 //copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize) let sourceFd = try! FileDescriptor.open(source, .readOnly) let destinationFd = try! FileDescriptor.open(destination, .writeOnly) if fcopyfile(sourceFd.rawValue, destinationFd.rawValue, state, copyfile_flags_t(COPYFILE_ALL | COPYFILE_NOFOLLOW | COPYFILE_EXCL | COPYFILE_UNLINK)) != 0 { print(NSError(domain: NSPOSIXErrorDomain, code: Int(errno))) } try! sourceFd.close() try! destinationFd.close() #else source.withCString { sourcePath in destination.withCString { destinationPath in let state = copyfile_state_alloc() defer { copyfile_state_free(state) } // var bsize = 16_777_216 // copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize) if copyfile(sourcePath, destinationPath, state, copyfile_flags_t(COPYFILE_ALL | COPYFILE_NOFOLLOW | COPYFILE_EXCL | COPYFILE_UNLINK)) != 0 { print(NSError(domain: NSPOSIXErrorDomain, code: Int(errno))) } } } #endif

I'm using the filecopy function to copy many files and I noticed that it always takes longer than similar tools like cp or a Finder copy (I already did a comparison in my other post). What I didn't know before was that I can set the block size which apparently can have a big influence on how fast the file copy operation is. The question now is: what should I consider before manually setting the block size? Does it make sense to have a block size that is not a power of 2? Can certain block sizes cause an error, such as a value that is too large (for the Mac the code is running on, or for the source and target devices)? When should or shouldn't I deviate from the default? Is there a way to find out the optimal block size for given source and target devices, or at least one that performs better than the default? In the following sample code I tried to measure the average time for varying block sizes, but I'm not sure it's the best way to measure it, since each loop iteration can have wildly different durations. class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { let openPanel = NSOpenPanel() openPanel.runModal() let source = openPanel.urls[0] openPanel.canChooseDirectories = true openPanel.canChooseFiles = false openPanel.runModal() let destination = openPanel.urls[0].appendingPathComponent(source.lastPathComponent) let date = Date() let count = 10 for _ in 0..<count { try? FileManager.default.removeItem(at: destination) do { try copy(source: source, destination: destination) } catch { preconditionFailure(error.localizedDescription) } } print(-date.timeIntervalSinceNow / Double(count)) } func copy(source: URL, destination: URL) throws { try source.withUnsafeFileSystemRepresentation { sourcePath in try destination.withUnsafeFileSystemRepresentation { destinationPath in let state = copyfile_state_alloc() defer { copyfile_state_free(state) } // var bsize = Int32(16_777_216) var bsize = Int32(1_048_576) if copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize) != 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 } var size: off_t = 0 copyfile_state_get(state, UInt32(COPYFILE_STATE_COPIED), &size) let appDelegate = unsafeBitCast(ctx, to: AppDelegate.self) if !appDelegate.setCopyFileProgress(Int64(size)) { return COPYFILE_QUIT } } return COPYFILE_CONTINUE } private func setCopyFileProgress(_ progress: Int64) -> Bool { return true } }

When building my app for debugging in Xcode I don't get any warning, only when archiving the product: MyIntent.appex is an ExtensionKit extension and must be embedded in the parent app bundle's Extensions directory, but is embedded in the parent app bundle's ../../../BuildProductsPath/Release/MyApp.app/Contents/Extensions directory. The MyIntent.appex is listed in the main target's Frameworks, Libraries and Embedded Content section and its Build Phase Embed ExtensionKit Extensions with Destination ExtensionKit Extensions. The extension also seems to work, since the app intent is correctly listed in the Shortcuts app. Is this an Xcode bug or do I need to do something different?

For the current app, I can get the Application Scripts directory with FileManager.url(for: .applicationScriptsDirectory, in: .userDomainMask, appropriateFor: nil, create: true), but I cannot find a similar API for application groups. Does one exist, or do I have to construct the URL manually? That would probably be ~/Library/Application Scripts/[app group id], but there doesn't seem to be a FileManager API to access ~ either, as FileManager.default.homeDirectoryForCurrentUser returns /Users/username/Library/Containers/[app id]/Data/.

Recently I realized that even though I was able to add my app's intents in the Shortcuts app, selecting any of the parameters didn't show the popup list of suggestions (the ones declared by DynamicOptionsProvider in the AppIntent subclass) and running it showed an error. In the image you can see the two suggestions for the working app version ("asdf" and "bla") that would not be there in the non-working version. I knew that when I had added this functionality, it worked, so I found the app version that caused the App Intents Extension to stop working. Apparently, the problem was that I had removed the Swift files declared in the app extension from my main app's target. Probably when I first added the App Intents Extension I had noticed that adding the extension's source files to the main target made it work, but later thought that it shouldn't be necessary and didn't test if it still worked. Today I created an empty project with a new App Intents Extension and confirmed that the Shortcuts app was correctly showing the parameter popup suggestions, even without including the extension's source files in the main target. Then during the course of almost an entire day I gradually reduced my original Xcode project to this new sample project to find what else would make the extension work, other than including the extension's source files in the main target. My very last resource was changing the bundle identifier, which solved the issue. My original project's targets have identifiers like org.domain.OriginalApp and org.domain.OriginalApp.AppIntent, while the sample project's targets have identifiers like org.domain.SampleApp and org.domain.SampleApp.AppIntent. How could including the App Intents Extension's source files in the main target or changing the bundle identifiers cause the Shortcuts app to correctly show the parameter popup suggestions?

In my app I use NSMenu.popUp(positioning:at:in:) for displaying a menu in response to the user clicking a button. But it seems that when the menu is opened inside a modal window, all the menu items are always disabled. Using NSMenu.popUpContextMenu(_:with:for:) instead works. What's the reason and what's the difference between the two methods? According to the documentation, one is for opening "popup menus" and the other for opening "context menus", but I cannot see an explanation of the difference between the two. @main class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { let window = NSWindow(contentViewController: ViewController()) NSApp.runModal(for: window) } } class ViewController: NSViewController { override func loadView() { let button = NSButton(title: "Click", target: self, action: #selector(click(_:))) view = NSView(frame: CGRect(x: 0, y: 0, width: 400, height: 400)) view.addSubview(button) } @objc func click(_ sender: Any?) { let menu = NSMenu(title: "") menu.addItem(withTitle: "asdf", action: #selector(asdf(_:)), keyEquivalent: "") menu.addItem(withTitle: "bla", action: nil, keyEquivalent: "") menu.items[0].target = self menu.items[1].target = self // NSMenu.popUpContextMenu(menu, with: NSApp.currentEvent!, for: view) // this works menu.popUp(positioning: nil, at: .zero, in: view) // this doesn't work } @IBAction func asdf(_ sender: Any) { print(0) } }

Every now and then I notice that the date modified of some files on my FTP server has slightly changed by setting the time to midnight. I notice this because I regularly sync the files from the FTP server to a folder on my Mac by comparing the date modified, and it happens every now and then that files that weren’t modified are listed for syncing. For many months after their creation, the time is correct and they are only synced once, but at some point the time is displayed as midnight for some reason and they are suddenly marked for syncing. The wrong time is reported both programmatically as well as in the Finder. The same files are displayed with what seems to be the correct time modified in the app Cyberduck. In this case it seems to be exactly 6 months old files. I didn't check this for the other files that this issue happened with in the past, but it could be about the same timeframe. Is this an issue with macOS? Is there a workaround? I already filed feedback FB13671336.

I want to show a file importer that allows to select both regular files as well as directories. When running the following code on iOS, I can tap a PDF file and the file importer closes as expected, but when tapping a directory, the file importer shows its contents. How can I instead select that directory and close the file importer? The navigation bar shows a Cancel button, but no Open button. struct FileView: View { @State private var showFileImporter = false var body: some View { ScrollView { VStack(alignment: .leading) { VStack(alignment: .center) { Button("Open") { showFileImporter = true } } } } .fileImporter(isPresented: $showFileImporter, allowedContentTypes: [.pdf, .directory], onCompletion: { result in // TODO }) } }

I have a file named ä.txt (with German umlaut) on my FTP server. I select it like this: let openPanel = NSOpenPanel() openPanel.runModal() let source = openPanel.urls[0] Running this code unexpectedly throws an error: do { print(try source.checkResourceIsReachable()) } catch { print(error) // Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory” } Manipulating the URL also seems to change the underlying characters: print(source) // file:///Volumes/abc.com/httpdocs/%C3%A4.txt print(URL(fileURLWithPath: source.path)) // file:///Volumes/abc.com/httpdocs/a%CC%88.txt Note that both variants of the URL above also throw the same error when running URL.checkResourceIsReachable(). If I download the file to my Mac, then both variants print file:///Users/me/Downloads/a%CC%88.txt and neither of them throws an error when running URL.checkResourceIsReachable(). What is the problem? How can I correctly access this file on the FTP server?

While this isn't an issue directly related with programming, I would like to share my frustration with Apple Care and their knowledge of how App Store and third-party apps work. Perhaps someone at Apple can do something about it. Every now and then a user of one of my apps contacts me asking why they get an error when downloading or updating the app in the App Store ("Unable to Download App. “App” could not be installed. Please try again later."). I tell them that third-party developers have no power over the App Store or its download/update process, and this is an issue they have to solve with Apple Care. But when they contact Apple Care, they are told that since it's an issue with a third-party app, they have to contact the app developer. Sometimes the user is more inclined to believe what Apple Care tells them and they get angry at me. In any case, I feel helpless and frustrated, because I would love to help them, but have no means of doing so. There is something about the concept of App Store that makes some users believe that third-party developers have more power than they actually have: sometimes, for example, users contact me directly, or even leave reviews on the App Store, asking for a refund, which of course only Apple can do. Have you had a similar experience? Can some engineer at Apple instruct Apple Care that third-party developers cannot help with App Store download/update issues, so that App Store users don't get mad at the app developers for not being able to install/update their app?

I use the App Store Connect API to run many parallel requests to update different parts of a single app. I am randomly getting errors such as An unexpected error occurred on the server side. or The request timed out. Usually when these errors happen, I can simply run the unsuccessful requests one or two more times and then they succeed. Is there an explanation for this? Is this possibly caused by too many parallel requests? What is the maximum suggested number of parallel requests?

I have a data object that dynamically changes the UIImage assigned to one of its instance variables, but when showing this image in SwiftUI, it's always black and white. The following sample code shows the difference between the same image, but using first the native constructor Image(systemName:) and then Image(uiImage:). When using AppKit and Image(nsImage:) this issue doesn't happen. import SwiftUI import UIKit struct ContentView: View { @State var object = MyObject() var body: some View { Image(systemName: "exclamationmark.triangle.fill") .symbolRenderingMode(.palette) .foregroundStyle(.white, .yellow) Image(uiImage: object.image) } } class MyObject { var image = UIImage(systemName: "exclamationmark.triangle.fill")! .applyingSymbolConfiguration(.init(paletteColors: [.white, .systemYellow]))! } #Preview { ContentView() }

The App Store Connect API documentation still doesn't list the new 13" iPad display type: https://developer.apple.com/documentation/appstoreconnectapi/screenshotdisplaytype When adding screenshots to 13" iPads on the website, they still seem to use the display type APP_IPAD_PRO_3GEN_129 when listed by the API, and uploading to that same type uploads them to the 13" display type instead, but then there is the requirement that one still has to upload screenshots for 12.9" display type, without an apparent way of doing so. I would expect to have an option to upload to 13" display type that is also used for 12.9" display type. Do we have to wait for Apple to update the documentation or does someone know a workaround?

I'm trying to bind a NSProgressIndicator to Progress, but with the following code I only get an indeterminate progress indicator with a blue bar forever bouncing left and right, even after the two timers fire. According to the documentation: Progress is indeterminate when the value of the totalUnitCount or completedUnitCount is less than zero or if both values are zero. What am I doing wrong? class ViewController: NSViewController { let progress = Progress() override func loadView() { view = NSView(frame: CGRect(x: 0, y: 0, width: 500, height: 500)) let progressIndicator = NSProgressIndicator(frame: CGRect(x: 100, y: 100, width: 100, height: 100)) progressIndicator.bind(.isIndeterminate, to: progress, withKeyPath: "isIndeterminate") progressIndicator.bind(.value, to: progress, withKeyPath: "completedUnitCount") progressIndicator.bind(.maxValue, to: progress, withKeyPath: "totalUnitCount") progressIndicator.startAnimation(nil) view.addSubview(progressIndicator) progress.completedUnitCount = 3 progress.totalUnitCount = 10 Timer.scheduledTimer(withTimeInterval: 1, repeats: false) { _ in print(1) self.progress.completedUnitCount = 6 } Timer.scheduledTimer(withTimeInterval: 6, repeats: false) { _ in print(2) self.progress.completedUnitCount = 0 self.progress.totalUnitCount = 0 } } }

With a Button I can directly copy contents to the clipboard via UIPasteboard.general.setObjects(objects), but this is iOS-specific so I was hoping that ShareLink would allow me to share items in a platform-independent way. Is it possible to show a Copy item in the ShareLink sheet? import SwiftUI struct ContentView: View { let myType = MyType() var body: some View { ShareLink(item: myType, preview: SharePreview(myType.text)) } } class MyType: Transferable { let text = "asdf" static var transferRepresentation: some TransferRepresentation { ProxyRepresentation { myType in return myType.text } } } #Preview { ContentView() }