FileProvider Testing Setup

Question

T-dawg OP

Created Apr ’24

Replies 3

Boosts 0

Participants 2

TL:DR

Can anyone provide guidance as to how to get the FileProvider testing API to work? It closes with no error and I have not been able to determine the issue despite careful attention to the documentation and signing. The Console logs seem to imply it is a Sandbox issue.

Hi,

Writing this as per suggested in the technical support section.

I am trying to create some tests that involve controlling the calls from MacOS to the corresponding "event" functions in the FileProvider (e.g. fetchContents()) using the FileProviderExtension test API provided by Apple. I have thoroughly read the documentation (both online and within the API code) in order to get this to work. I have:

Added the com.apple.developer.fileprovider.testing-mode entitlement to both my Main App as well as my FileProviderExtension
Ensured my I have the correct account permissions, and provisioning profiles for my Main App as well as FileProviderExtension
Added the line domain.testingModes = [.alwaysEnabled, .interactive]

The issue: I found that setting the .interactive option in my domain.testingModes will result in my domain in Finder appearing to be stuck loading the root folder, and that my FileProviderExtension instance is being invalidated and closing in ~5s. It is reproducible. Is this a bug?

Some things I have noticed:

Attaching the debugger to the FileProviderExtension process results in no error. Additionally there is no error received when calling add(:domain).
I noticed through testing that the Main App appears to be required to have the com.apple.developer.fileprovider.testing-mode entitlement in order to run a FileProviderExtension with that same entitlement. Otherwise I would receive the error: Error Domain=NSCocoaErrorDomain Code=257 "The file couldn’t be opened because you don’t have permission to view it"
When trying to sign manually using a group Developer ID Application certificate as opposed to automatically with my Apple Development certificate Xcode presents the error "Main app provisioning profile" doesn't support the FileProvider Testing Mode capability." Despite this I can clearly see that is an enabled capability though the online Apple Developer portal under the Profiles section. Note that the only capabilities enabled when viewing the bundle identifiers of the Main App and FileProviderExtension are "FileProvider Testing Mode", "App Groups", and the (seemingly required) "In-App Purchases". I later realized that this was likely due to using the wrong type of provisioning profile so I generated and switched to MacOS Developer Profiles (as opposed to Distribution) and this error in XCode went away. However the above issue (FileProviderExtension instance being invalidated) persisted.
If I look at the Console I see various errors from when the extension is launched till it closes:
- Sandbox: mdbulkimport(922) deny(1) mach-lookup com.apple.FileProvider
- Sandbox: hiveDiskProvider(37981) deny(1) mach-lookup com.apple.mobile.keybagd.UserManager.xpc
- [ERROR] Cannot query for providers. Error: NSError: Cocoa 4099 "<private>"
- Error from beginMonitoringProviderDomainChangesWithHandler: Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription=<private>}
- Synchronizer coordinateReadingItemAtURL error: Error Domain=NSCocoaErrorDomain Code=3072
With the Development Provisioning Profiles I see a couple new errors:
1. From secinitd(App Sandbox) Failed to set LS data container personality info: <private>
2. A new error repeated a number of times from cfprefsd after trying to access some .plist files that don't appear to be on my system:
  - Error: Couldn't open parent path due to [2: No such file or directory]
  - Paths are: ~/Library/Containers/<extensionBundleID>/Data/Library/Preferences/ByHost/<extensionBundleID>.<ID>.plist
  - /Library/Managed Preferences/<username>/<extensionBundleID>.plist

Any help would be greatly appreciated :)

Boost

Answer 1

T-dawg OP

Apr ’24

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

0

Answer 2

T-dawg OP

Apr ’24

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

0

Answer 3

T-dawg OP

May ’24

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

1