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.

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 just saw another post regarding bookmarks on iOS where an Apple engineer made the following statement: [quote='855165022, DTS Engineer, /thread/797469?answerId=855165022#855165022'] macOS is better at enforcing the "right" behavior, so code that works there will generally work on iOS. [/quote] So I went back to my macOS code to double-check. Sure enough, the following statement: let bookmark = try url.bookmarkData(options: .withSecurityScope) fails 100% of the time. I had seen earlier statements from other DTS Engineers recommending that any use of a URL be bracketed by start/stopAccessingSecurityScopedResource. And that makes a lot of sense. If "start" returns true, then call stop. But if start returns false, then it isn't needed, so don't call stop. No harm, no foul. But what's confusing is this other, directly-related API where a security-scoped bookmark cannot be created under any circumstances because of the URL itself, some specific way the URL was initially created, and/or manipulated? So, what I'm asking is if someone could elaborate on what would cause a failure to create a security-scoped bookmark? What kinds of URLs are valid for creation of security-scoped bookmarks? Are there operations on a URL that will then cause a failure to create a security-scoped bookmark? Is it allowed to pass the URL and/or bookmark back and forth between Objective-C and Swift? I'm developing a new macOS app for release in the Mac App Store. I'm initially getting my URL from an NSOpenPanel. Then I store it in a SQLite database. I may access the URL again, after a restart, or after a year. I have a login item that also needs to read the database and access the URL. I have additional complications as well, but they don't really matter. Before I get to any of that, I get a whole volume URL from an NSOpen panel in Swift, then, almost immediately, attempt to create a security-scoped bookmark. I cannot. I've tried many different combinations of options and flows of operation, but obviously not all. I think this started happening with macOS 26, but that doesn't really matter. If this is new behaviour in macOS 26, then I must live with it. My particular use requires a URL to a whole volume. Because of this, I don't actually seem to need a security-scoped bookmark at all. So I think I might simply get lucky for now. But this still bothers me. I don't really like being lucky. I'd rather be right. I have other apps in development where this could be a bigger problem. It seems like I will need completely separate URL handling logic based on the type of URL the user selects. And what of document-scoped URLs? This experience seems to strongly indicate that security-scoped URLs should only ever be document-scoped. I think in some of my debugging efforts I tried document-scoped URLs. They didn't fix the problem, but they seemed to make the entire process more straightforward and transparent. Can a single metadata-hosting file host multiple security-scoped bookmarks? Or should I have a separate one for each bookmark? But the essence of my question is that this is supposed to be simple operation that, in certain cases, is a guaranteed failure. There are a mind-bogglingly large number of potential options and logic flows. Does there exist a set of options and logic flows for which the user can select a URL, any URL, with the explicit intent to persist it, and that my app can save, share with helper apps, and have it all work normally after restart?

I'm having a problem on macOS 26 that has not happened on previous macOS versions. When I call guard url.startAccessingSecurityScopedResource() else { return } try url.bookmarkData(options: [.withSecurityScope]) with url being "file:///", I get an error Error Domain=NSCocoaErrorDomain Code=256 "File descriptor doesn't match the real path." Given that Google returns 0 results on this error, I suppose this is a macOS 26 novelty. (The bookmark data created before upgrading to 26 resolve well). Does anyone already met this or have an idea on how to get around it? The app is a file manager, so having bookmarked access to "/" is crucial.

With the RC version of macOS 26, an issue persists when you try to create a bookmark with security scope for the root folder "/". This leads to an error "The file couldn’t be opened.". However, you can create bookmark for /Applications, /System, /Users... This is quite annoying for one of my app because a user can create a cartography of his disk usage, and the access to the root folder "/" is the only way to do so! Is there a workaround? PS: reported the issue with ID FB20186406 let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true openPanel.canChooseFiles = false openPanel.beginSheetModal(for: self.view.window!) { (result) in guard result == .OK, let folderURL = openPanel.url else { return } openPanel.close() do { let data = try folderURL.bookmarkData(options: .withSecurityScope, includingResourceValuesForKeys: nil, relativeTo: nil) print("Bookmark data was created for \(folderURL.path)") } catch (let error) { print("Error creating bookmark for \(folderURL.path), with error: \(error.localizedDescription)") } }

We use File Provider Extension in our main app, and it is working fine. We always call "NSFileProviderManager.add(_:completionHandler:)" function to start the extension, and "NSFileProviderManager.disconnect(reason:options:completionHandler:)" to temporarily quit the extension with the reason which will be shown in the Finder at the top of the FP domain folder. But sometimes, when the main app calls the above functions, the following issue cases occur, and the extension does not start/stop: The completionHandler function doesn't get called (As we noticed, we waited for 2 minutes. Then, we restarted the main app.) One of the following errors returned: i) "The application cannot be used right now", ii) "Couldn't communicate with the helper application", iii) "No valid file provider found with identifier" Here, the important thing is that restarting the main app once or twice clears the issue, and the extension starts. But it is frustrating to restart the app each time we get this issue. We want to know the following things: Why and when do the above issues occur? Why do they occur only sometimes, and how does the app restart clear the issue? How do we resolve them without restarting the main app? This has become a critical issue, so a detailed explanation would be greatly appreciated. TIA.

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?

I have an iOS app that allows user to select a folder (from Files). I want to bookmark that folder and later on (perhaps on a different launch of the app) access the contents of it. Is that scenario supported or not? Can't make it work for some reason (e.g. I'm getting no error from the call to create a bookmark, from a call to resolve the bookmark, the folder URL is not stale, but... startAccessingSecurityScopedResource() is returning false.

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.

I want to traverse my local Google Drive folder to calculate the size of all the files on my drive. I'm not interested in files or directories that are not present locally. I use getattrlistbulk for traversing and it takes way too much time. I think it is because FileProvider tries to download metadata for the directories that are not yet materialised. Is there a way to skip non-materialised directories?

Understand dataless files and how to minimize the performance impact as the system materializes them. View Technote TN3150 >

https://developer.apple.com/documentation/fileprovider/nsfileproviderpartialcontentfetching/3923718-fetchpartialcontents fetchPartialContents(for:version:request:minimalRange:aligningTo:options:completionHandler:) I need to use this function to fetch contents of the files partially. But it seems I'm just unable to receive any callback when i try to open the file via double click on finder. I've tried to open files of different types and sizes but still i'm defaulting back to fetchContents(for:version:request:completionHandler:) . I've been thinking if there are any specific configurations or requirements that i have to meet , so i could trigger this callback function for all the fetch Operations for files ? If No, then where am i going wrong ?

Hello! Some colleagues and work on Jujutsu, a version control system compatible with git, and I think we've uncovered a potential lock contention bug in either APFS or the Darwin kernel. There are four contributing factors to us thinking this is related to APFS or the Kernel: jj's testsuite uses nextest, a test runner for Rust that spawns each individual test as a separate process. The testsuite slowed down by a factor of ~5x on macOS after jj started using fsync. The slowdown increases as additional cores are allocated. A similar slowdown did not occur on ext4. Similar performance issues were reported in the past by a former Mercurial maintainer: https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/. My friend and colleague André has measured the test suite on an M3 Ultra with both a ramdisk and a traditional SSD and produced this graph: (The most thorough writeup is the discussion on this pull request.) I know I should file a feedback/bug report, but before I do, I'm struggling with profiling and finding kernel/APFS frames in my profiles so that I can properly attribute the cause of this apparent lock contention. Naively, I ran xctrace record --template 'Time Profiler' --output output.trace --launch /Users/dbarsky/.cargo/bin/cargo-nextest nextest run, and while that detected all processes spawned by nextest, it didn't record all processes as part of the same inspectable profile and didn't really show any frames from the kernel/APFS—I had to select individual processes. So I don't waste people's time and so that I can point a frame/smoking gun in the right system, how can I can use instruments to profile where the kernel and/or APFS are spending its time? Do I need to disable SIP?

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.

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?

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 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.)

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.

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 }