I use the code below to rename a file, it works ok, but then the system calls accommodatePresentedItemDeletion(completionHandler:) on a NSFilePresenter that presents the file, immediately after the call to presentedItemDidMove(to:) What am I doing wrong? NSFileCoordinator().coordinate(writingItemAt: oldURL, options: .forMoving, writingItemAt: newURL, options: [], error: &error) { (actualURL1, actualURL2) in do { coordinator.item(at: actualURL1, willMoveTo: actualURL2) try FileManager().moveItem(at: actualURL1, to: actualURL2) coordinator.item(at: actualURL1, didMoveTo: actualURL2) } catch {...} }

My process running with root privilege, but got below error with API SecStaticCodeCreateWithPath(::_:) to create static code object for Cortex XDR Agent app, it working fine for other app like Safari on same device. 2025-07-22 02:02:05.857719(-0600)[23221:520725] DBG Found /Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app,/Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app running. Will verify the process now 2025-07-22 02:02:05.859209(-0600)[23221:520725] ERR Failed to create static code for path /Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app/Contents/MacOS/Cortex XDR Agent. Error: Optional(UNIX[Operation not permitted]) Code Snippet let fileURL = URL(fileURLWithPath: processPath) var code: SecStaticCode? let rc = SecStaticCodeCreateWithPath(fileURL as CFURL, [], &code) if rc == errSecSuccess, let code = code { staticCode = code } else { ZSLoggerError("Failed to create static code for path \(processPath). Error: \(String(describing: SecCopyErrorMessageString(rc, nil)))") return nil }

On macOS 26.1 (25B78) I can't give Full Disk Access to sshd-keygen-wrapper. Now my Jenkins jobs do not work because they do not have the permission to execute the necessary scripts. Until macOS 26.1 everything worked fine. I restarted the machine several times and tried to give access from Settings -> Privacy & Security -> Full Disk Access but it just does not work. I tried logging with ssh on the machine and executing a script but again nothing happened.

This script from man hdiutil no longer works: devnode=$(hdiutil attach -nomount ram://102400) newfs_hfs “$devnode” mount -t hfs “$devnode” /path/to/ramdisk because $devnode contains spaces and tabs!! $ hdiutil attach -nomount ram://1 | xxd 00000000: 2f64 6576 2f64 6973 6b34 2020 2020 2020 /dev/disk4 00000010: 2020 2020 0920 2020 2020 2020 2020 2020 . 00000020: 2020 2020 2020 2020 2020 2020 2020 2020 00000030: 2020 2020 090a # remember to clean up afterwards $ hdiutil detach /dev/disk4 Please properly quote your variables in CI test scripts to catch such regression. It could pass because unquoted expansion of $devnode undergoes word splitting after the variable is substituted, removing the trailing whitespaces. FB20303191

Since macOS 26.1, creating bookmark data based on a NSOpenPanel URL, does not return the expected bookmark data when the selected source concerns a Windows NTFS fileshare. When the returned data is being resolved, the returned URL points to the local drive of the current Mac. Which is of course super confusing for the user. This issue did not occur in macOS 26.0 and older. In essence, the following code line with 'url' based on an URL from a NSOpenPanel after selecting the root of a Windows NTFS share, creates an incorrect bookmark in macOS 26.1: let bookmark = try url.bookmarkData(options: .withSecurityScope, includingResourceValuesForKeys: nil, relativeTo: nil) I have tested this on two different Macs with macOS 26.1 with two different Windows PC both hosting NTFS files shares via SMB. My questions: Have anyone else encountered this issue in macOS 26? Perhaps even with other fileshare types? Is there a workaround or some new project configuration needed in Xcode to get this working?

I am slowly converting an Objective C with C program to Swift with C. All of my menus and dialog boxes are now in Swift, but files are still opened and closed in Objective C and C. The following code is Objective C and tries to open two files in the same directory with two related names after getting the base of the name from a Save Panel. The code you see was modified by ChatGPT 5.0, and similar code was modified by Claude. Both LLMs wrote code that failed because neither knows how to navigate Apple’s sandbox. Does anybody understand Apple’s sandbox? I eventually want to open more related files and do not want the user to have to click through multiple file dialog boxes. What is the best solution? Are the LLMs just not up to the task and there is a simple solution to the Objective C code? Is this easier in Swift? Other ideas? Thanks in advance for any help. (BOOL)setupOutputFilesWithBaseName:(NSString*)baseName { NSString *outFileNameStr = baseName; if (outFileNameStr == nil || [outFileNameStr length] == 0) { outFileNameStr = @"output"; } // Show ONE save panel for the base filename NSSavePanel *savePanel = [NSSavePanel savePanel]; [savePanel setMessage:@"Choose base name and location for output files\n(Two files will be created: one ending with 'Pkout', one with 'Freqout')"]; [savePanel setNameFieldStringValue:outFileNameStr]; if (directoryURL != nil) { [savePanel setDirectoryURL:directoryURL]; } if ([savePanel runModal] != NSModalResponseOK) { NSLog(@"User cancelled file selection"); return NO; } // Get the selected file URL - this gives us security access to the directory NSURL *baseFileURL = [savePanel URL]; // Get the directory - THIS is what we need for security scope NSURL *dirURL = [baseFileURL URLByDeletingLastPathComponent]; // Start accessing the DIRECTORY, not just the file BOOL didStartAccessing = [dirURL startAccessingSecurityScopedResource]; if (!didStartAccessing) { NSLog(@"Warning: Could not start security-scoped access to directory"); } NSString *baseFileName = [[baseFileURL lastPathComponent] stringByDeletingPathExtension]; NSString *extension = [baseFileURL pathExtension]; // Create the two file names with suffixes NSString *pkoutName = [baseFileName stringByAppendingString:@"Pkout"]; NSString *freqoutName = [baseFileName stringByAppendingString:@"Freqout"]; NSURL *pkoutURL = [dirURL URLByAppendingPathComponent:pkoutName]; NSURL *freqoutURL = [dirURL URLByAppendingPathComponent:freqoutName]; NSLog(@"Attempting to open: %@", [pkoutURL path]); NSLog(@"Attempting to open: %@", [freqoutURL path]); // Open the first file (Pkout) globalFpout = fopen([[pkoutURL path] UTF8String], "w+"); if (globalFpout == NULL) { int errnum = errno; NSLog(@"Error: Could not open Pkout file at %@", [pkoutURL path]); NSLog(@"Error code: %d - %s", errnum, strerror(errnum)); if (didStartAccessing) { [dirURL stopAccessingSecurityScopedResource]; } return NO; } NSLog(@":white_check_mark: Pkout file opened: %@", [pkoutURL path]); // Open the second file (Freqout) globalFpfrqout = fopen([[freqoutURL path] UTF8String], "w+"); if (globalFpfrqout == NULL) { int errnum = errno; NSLog(@"Error: Could not open Freqout file at %@", [freqoutURL path]); NSLog(@"Error code: %d - %s", errnum, strerror(errnum)); fclose(globalFpout); globalFpout = NULL; if (didStartAccessing) { [dirURL stopAccessingSecurityScopedResource]; } return NO; } NSLog(@":white_check_mark: Freqout file opened: %@", [freqoutURL path]); // Store the directory URL so we can stop accessing later secureDirectoryURL = dirURL; return YES; }

When running the currently latest version of macOS (26.1) on a machine with ARM CPU (I could not reproduce the issue with Intel-Based machines) Finder Sync extensions do not work any more in general. Steps to reproduce the problem: In Xcode create a new macOS App project with default settings (in my case I chose XIB for the UI and Objective-C as language, and disabled testing, but that should not make any difference) In Xcode add a new target / "Finder Sync Extension" to the project with default settings, this adds a new Finder Sync Extension with example code to the app. Run the application and open Finder and navigate to "/Users/Shared/MySyncExtension Documents" In the system settings ("Login Items & Extensions") enable the extension (Listed as "File Provider"). On systems where it is working, in the context menu of that folder an entry "Example Menu Item" will appear. On systems where it does not work it is missing. Some findings: Adding the *.appex with "pluginkit -a" registers the extension as expected, it is then visible in the system settings, removing it with "pluginkit -r" is also reflected in the system settings. "pluginkit -m -i " returns the extension on systems where it is working (assuming it is registered while this command is executed), on systems wehre it is not working, nothing is returned, regardless of the registration state. When enabling the extension in the system settings nothing more happens, there is no process started for the extension (unlike as on systems where it is working), and thus no context menu entries and no badges are displayed in Finder. Restarting Finder or the system does not help. Any ideas what I could be missing here?

A user of one of my apps reported that since the update to macOS 26.1 they are no longer able to scan Macintosh HD: the app used to work, but now always reports that Macintosh HD contains a single empty file named .nofollow, or rather the path is resolved to /.nofollow. Initially I thought this could be related to resolving the file from the saved bookmark data, but even restarting the app and selecting Macintosh HD in an open panel (without resolving the bookmark data) produces the same result. The user tried another app of mine with the same issue, but said that they were able to scan Macintosh HD in other App Store apps. I never heard of this issue before and my apps have been on the App Store for many years, but it looks like I might be doing something wrong, or the APIs that I use are somehow broken. In all my apps I currently use getattrlistbulk because I need attributes that are not available as URLResourceKey in all supported operating system versions. What could be the issue? I'm on macOS 26.1 myself and never experienced it.

I’ve filed this as FB20943098 (macOS 26.1 – FileProvider v3 synchronous enumeration bug), but posting here in case others can reproduce and add duplicates. Systems: macOS 26.1 (26B82) M4 Mac mini Pro and M4 MacBook Air Symptoms: In any app (TextEdit, Pages, Browsers, etc.), the Open/Save dialog lags for ~1s per folder navigation click. CPU spikes from fileproviderd, cloudd, bird, and siriactionsd. Key discovery: If my iCloud Drive root is empty (only “Documents” and “Downloads”), performance is perfect. As soon as any folder or file exists at the root of iCloud Drive, the lag returns immediately. Moving those items into “Documents” or “Downloads” makes everything smooth again. Analysis: Based on process traces and container paths, this appears to originate in the FileProvider.framework subsystem (via fileproviderd), which mediates iCloud Drive. Early evidence suggests that folder enumeration of the iCloud Drive container root may be blocking UI threads in macOS 26.1. I believe this may be related to the recent internal migration of the file-provider backend (often referred to as “v3”), but I do not have direct confirmation from Apple of that exact change. MacOS 26.1’s new FileProvider v3 backend seems to be blocking the Open/Save panel while enumerating the iCloud Drive root container (~/Library/Application Support/FileProvider/723EBBFF-…). Folder enumeration seems to wait synchronously for metadata from fileproviderd, and if the local SQLite DB is busy (WAL writes or sync state checks), UI freezes briefly. Workarounds: Disabling iCloud Drive entirely fixes the issue. Simply disabling Desktop/Documents sync does not help. Keeping the iCloud Drive root empty avoids the lag without turning iCloud off. I am able to store whatever I please in the Desktop or Documents folder which is currently syncing. Would appreciate if others on 26.1 could confirm. Engineers: I’ve attached fs_usage, log stream, and process samples to my Feedback ticket via the FB20943098. Expected behavior: Folder enumeration in NSOpenPanel should remain asynchronous regardless of FileProvider background activity. Open/save modal should be responsive and smooth.

Hey there, I have an app that allows picking any folder via UIDocumentPickerViewController. Up until iOS18 users were able to pick folders from connected servers (servers connected in the Files app) as well. On iOS26, the picker allows for browsing into the connected servers, but the Select button is greyed out and does nothing when tapped. Is this a known issue? This breaks the whole premise of my file syncronization application.

I'm working on an iOS document-based app. It uses ReferenceFileDocument and custom creation of documents via DocumentGroupLaunchScene + NewDocumentButton. It works fine when I use the plain NewDocumentButton("Whatever") (without any more arguments), but when I want to perform additional setup via preapreDocumentURL or even just add a contentType it gives such output in the console when I hit it: Content serialization failed, document won't be saved. UTType.replayable is correctly wired up in the plist. It looks like a bug in the SDK, but maybe there is a chance that I'm doing something wrong? Here's a code: import SwiftUI import UniformTypeIdentifiers import Combine @main struct MyApp: App { var body: some Scene { DocumentGroup { Document() } editor: { documentConfiguration in EmptyView() } DocumentGroupLaunchScene("Yoyo") { NewDocumentButton(contentType: .replayable) { return URL(string: "whatever, it doesnt even go there...")! } } } } final class Document: ReferenceFileDocument { static var readableContentTypes: [UTType] { [.replayable] } @Published var x = 0 init() {} init(configuration: ReadConfiguration) throws {} func snapshot(contentType: UTType) throws -> Data { Data() } func fileWrapper(snapshot: Data, configuration: WriteConfiguration) throws -> FileWrapper { .init(regularFileWithContents: snapshot) } } extension UTType { static var replayable: UTType { UTType(exportedAs: "com.whatever.yo") } }

I want to check whether a sandboxed application already has access permission to a specific URL. Based on my investigation, the following FileManager method seems to be able to determine it: FileManager.default.isReadableFile(atPath: fileURL.path) However, the method name and description don't explicitly mention this use case, so I'm not confident there aren't any oversights. Also, since this method takes a String path rather than a URL, I'd like to know if there's a more modern API available. I want to use this information to decide whether to prompt the user about the Sandbox restriction in my AppKit-based app.

For bookmark creation and resolving, there's a NSURLBookmark{Creation,Resolution}MinimalBookmark enum value. What does this value imply on macOS and iOS? Specifically, to create security scoped bookmarks on macOS, we use NSURLBookmarkResolutionWithSecurityScope, but that is not available on iOS. Are iOS bookmarks always security scoped? Does the minimal enum imply security scoped bookmarks? Is 0 a valid value to bookmarkDataWithOptions, and does that give an even less scoped bookmark than NSURLBookmarkCreationMinimalBookmark`? We are also using NSURLBookmarkCreationWithoutImplicitSecurityScope on both iOS and macOS, to avoid any implicit resolution of bookmarks we resolve, so that we can explicitly control access by explicit calls to start/stopAccessing. How does NSURLBookmarkCreationWithoutImplicitSecurityScope relate to the enum values discussed above? Thanks! (https://mothersruin.com/software/Archaeology/reverse/bookmarks.html provides some really interesting insights, but doesn't discuss the minimal bookmarks.)

Users of my different apps started reporting an issue that could be related to the ones discussed in this other post: paths on an external volume, such as one mounted by "NTFS for Mac", or a path on a Synology volume, are "converted" to / (Macintosh HD) after going through "laundry" (creating the security-scoped bookmark, resolving the URL from it and using this new URL instead of the one returned by the open panel). Because of this issue, users of my apps are unable to select external volumes, which renders the different apps more or less useless. I've already received many emails regarding this issue in the past few days. A timely fix or suggestion for a workaround would be much appreciated, so that they don't have to wait for months before the next minor macOS release. The intention of this post is also to show users of my apps that this is a real issue. I created FB21002290 and TSI 16931637.

I'm writing a read-only filesystem extension. I see that the documentation for loadResource(resource:options:replyHandler:) claims that the --rdonly option is supported, which suggests that this should be possible. However, I have never seen this option provided to my filesystem extension, even if I return usableButLimited as a probe result (where it doesn't mount at all - FB19241327) or pass the -r or -o rdonly options to the mount(8) command. Instead I see those options on the volume's activate call. But other than saving that "readonly" state (which, in my case, is always the case) and then throwing on all write-related calls I'm not sure how to actually mark the filesystem as "read-only." Without such an indicator, the user is still offered the option to do things like trash items in Finder (although of course those operations do not succeed since I throw an EROFS error in the relevant calls). It also seems like the FSKit extensions that come with the system handle read-only strangely as well. For example, for a FAT32 filesystem, if I mount it like mount -r -F -t msdos /dev/disk15s1 /tmp/mnt Then it acts... weirdly. For example, Finder doesn't know that the volume is read-only, and lets me do some operations like making new folders, although they never actually get written to disk. Writing may or may not lead to errors and/or the change just disappearing immediately (or later), which is pretty much what I'm seeing in my own filesystem extension. If I remove the -F option (thus using the kernel extension version of msdos), this doesn't happen. Are read-only filesystems currently supported by FSKit? The fact that extensions like Apple's own msdos also seem to act weirdly makes me think this is just a current FSKit limitation, although maybe I'm missing something. It's not necessarily a hard blocker given that I can prevent writes from happening in my FSKit module code (or, in my case, just not implement such features at all), but it does make for a strange experience. (I reported this as FB21068845, although I'm mostly asking here because I'm not 100% sure this is not just me missing something.)

Does FSKit support the ability to get the process information, such as the pid, when a process accesses a resource? Being able have the process context is important for implementing certain access patterns and security logging in some contexts. For instance, we have a system that utilizes (pre-FSKit) a FUSE mount that, depending on the process has different "views" and "access" based on the process id.

SMBClient-593 introduces a crtitical bug. When reading and writing data at high volume, the SMBClient no longer properly receives and handle responses from the server. In some cases, the client mishandles the response packet and the following errors are seen in the logs: 2025-12-02 21:36:04.774772-0700 localhost kernel[0]: (smbfs) smb2_smb_parse_write_one: Bad struct size: 0 2025-12-02 21:36:04.774776-0700 localhost kernel[0]: (smbfs) smb2_smb_write: smb2_smb_read_write_async failed with an error 72 2025-12-02 21:36:04.774777-0700 localhost kernel[0]: (smbfs) smbfs_do_strategy: file.txt: WRITE failed with an error of 72 In other cases, the client mishandles the response packet and becomes completely unresponsive, unable to send or receive additional messages, and a forced shutdown of the computer is required to recover. This bug is only present on macos 26. We believe the operative change is in the latest commit, SMBClient-593 beginning at line now 3011 in smb_iod.c. The issue seems to be a race, and occurs much more frequently once throughput exceeds around 10Gbps, and again more frequently above 20Gbps.

I'm new to swift and iOS development. I'm trying to create a file provider extension for my app. I have able to use createItem, modifyItem, fetchContents functions. But when I try to add a GarageBand file or a big size mp3 file(18 Mb) I can see multiple upload is happening. I checked the FruitBasket project where they are doing chunked upload when file size is more than 100 Mb. How do I fix this to only one upload? I'm getting suggestions like I have to do debounce upload but that seems not a proper solutions.

I try saving the value of NSURLVolumeURLKey when creating a bookmark. When resolving the bookmark later I pass the bookmark data to +resourceValuesForKeys:fromBookmarkData: but always pull out "file:///" which is wrong. In contrast the value for NSURLVolumeURLForRemountingKey is properly saved and restored using the same method.

There are multiple iOS simulator runtimes located at /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime which I don't need. I tried the following approaches to delete them but not working. Xcode > Settings > Components > Delete (It can delete some but not all of them) xcrun simctl runtime list (It doesn't show the old runtimes) sudo rm (Operation not permitted) sudo rm -rf cc1f035290d244fca4f74d9d243fcd02d2876c27.asset Password: rm: cc1f035290d244fca4f74d9d243fcd02d2876c27.asset/AssetData/096-69246-684.dmg: Operation not permitted rm: cc1f035290d244fca4f74d9d243fcd02d2876c27.asset/AssetData: Operation not permitted rm: cc1f035290d244fca4f74d9d243fcd02d2876c27.asset/Info.plist: Operation not permitted rm: cc1f035290d244fca4f74d9d243fcd02d2876c27.asset/version.plist: Operation not permitted rm: cc1f035290d244fca4f74d9d243fcd02d2876c27.asset: Operation not permitted I have two questions: Why "xcrun simctl runtime list" is unable to list some old runtimes? How to delete them?