I would suggest looking into the header file for NSFileProviderUserInteractions. It provides the following hooks: 'Copy' : copying item(s) within the same provider 'CopyOut' : copying item(s) out of the provider 'CopyIn' : copying item(s) into a folder/root of the provider You can access these hooks via the info.plist of you File Provider Extension. The header file provides an example of this. I have personally used it to display an alert when preventing forbidden user actions. I expect you could also use it to call custom functions. Hope this helps :)

Got a response from tech support. Can't believe I missed this :P The root was not loading because enumeration (AKA populating a folder) is a testing operation. Therefore the FileProviderExtension was closing after ~5 seconds as it was doing nothing. Solution is to run the enumeration testing operation. Here is the response from support: "The system is waiting for you to run the enumeration process. You should be able to make it work by having a loop to periodically run at least the available children enumeration operations. The following code snippet runs the operations once. Since you use .interactive testing mode, you will need to create a loop so you can interactively pick and run an operation." if let fileProviderManager = NSFileProviderManager(for: domain) { do { let testingOperations = try fileProviderManager.listAvailableTestingOperations() for operation in testingOperations { if operation is NSFileProviderTestingChildrenEnumeration { try fileProviderManager.run(testingOperations) } } } catch { print(error) } }

I would also like to add that there are no crash reports for the extension in the Console App.

Note: I also attempted removing the Sandbox entirely and had the same result.

Try URL.startAccessingSecurityScopedResource()! As described in the 2/2 File Provider video

I believe I have solved this issue. I was missing an implementation of the evictItem() function.

Have you found a solution? I would very much like to know if this implementation works! Though it appears, at least according to (this post)[https://developer.apple.com/forums/thread/739722], that only one works at a time :(

I also had this problem for a long time. Please do a deep dive on proper signing and notarization. Personally for me what fixed it was that I was providing the wrong provisioning profile so the notarization was failing. Turns out I needed a Distribution provisioning profile as opposed to a Developer provisioning profile. Also beware that if you sign an extension, package it within an app, then sign the app, then the extension signature will be overridden and possibly invalidated.

I discovered that the issue was that the provisioning profile being generated from XCode was using my personal ID instead of my organization ID so I had to turn off automatic signing and manually provide the correct provisioning profile. You can see more in detail the steps I took in my response to this StackOverflow post. Hope this helps someone :)

Made a sister post on stackoverflow here.

Upon further inspection I found that I'm getting an error in the Console that seems to be the cause of the issue: "Sandbox: fileproviderd(684) deny(1) file-read-data /Applications/myApp.app/Contents/PlugIns/myHelperApp.app". Any clues as to how to resolve this issue? Is this is a code signing issue? If so I am failing to see what I am doing wrong. I am signing my helper app through XCode with a MacOS provisioning profile, packaging it within my application, and then signing my application.

I had what I believe is the same issue and it took me forever to figure out. I believe the full error I got in the console was Error Domain=NSFileProviderErrorDomain Code=-2003 "An older version of the application is currently in use which maps to olderExtensionVersionRunning. https://developer.apple.com/documentation/fileprovider/nsfileprovidererror/code/olderextensionversionrunning It occurs when you run the extension from different file system locations. It is caused by the older version of your extension never being removed from the plugin registry. I have found what fixes it is described in this stackoverflow post: https://stackoverflow.com/questions/44211893/extensions-pluginkit-and-craziness-on-macos In summary: Use pluginkit -v -m -D -i my.bundle.id to get the location of your old extension. Use pluginkit -r path-to-my-extension to remove it. Extra tip: you can use pluginkit -vvvvm to list all your registered plugins. Hope that helps :)