Adding to what Quinn has said. Yes, you can use Endpoint Security in Swift. The Endpoint Security header files include a module.modulemap file, which allows CLang to expose the C API in Swift. The headers also contain nullability annotations (e.g. _Nonnull and _Nullable).

Hi trungflm, Xcode's File Provider Extension template is not enough for fetchContentsForItemWithIdentifier:version:request:completionHandler: to work as you have expected it too. You will need to update the method to call the completionHandler with the NSURL to the file containing the file's data (downloaded by your extension to a temporary location) and a NSFileProviderItem instance that represents the file. The template's default implementation of the NSFileProviderItem protocol also needs implementations for the following optional properties: @property (nonatomic, readonly, copy, nullable) NSNumber *documentSize; @property (nonatomic, readonly, copy, nullable) NSDate *creationDate; @property (nonatomic, readonly, copy, nullable) NSDate *contentModificationDate; Once I implemented those properties, I was able to download a file using my own File Provider implementation. Omar

Hi, The only way to deal with the deadline is to either have your ES Client perform the required action within the deadline; or deny the Auth Event (without caching the result) and have your ES Client perform the action, in the background, so that it is ready to allow/deny the Auth Event the next time it occurs. An Apple Security Engineer has previously posted about managing the deadline: https://developer.apple.com/forums/thread/649552?answerId=615802022#615802022 Unfortunately, I doubt it's the answer you're looking for. Although I'm not sure that Endpoint Security is the best method for loading files from the cloud. A couple of alternatives come to mind: Using a VFS plug-in (not deprecated at the moment, but the way things are going you know it will eventually happen). I've done this before on a 'Dropbox' like product. Apple has recently made the File Provider framework available for macOS (docs says macOS 10.15+, but the required NSFileProviderReplicatedExtension protocol is only available from macOS 11.0): https://developer.apple.com/documentation/fileprovider/macos_support Hope that's of some help, Omar

Hi Aleksandr, Assuming you've not been granted the necessary entitlements and want to test Endpoint Security and System Extensions. You will need to boot into Recovery mode and do the following from the terminal: If you just want to test Endpoint Security directly in a stand-alone binary, you will need to disable SIP: csrutil disable As you're using a System Extension. You will also need to disable AMFI on your test machine: nvram boot-args="amfi_get_out_of_my_way=0x1" Just use caution when doing so, because of the inherited risk from disabling these system protections (i.e. do so at your own risk!). I've discussed this a bit more here: https://gist.github.com/Omar-Ikram/8e6721d8e83a3da69b31d4c2612a68ba#gistcomment-3504906 Hope that helps, Omar

Hi Trace, You're seeing the password prompt, because the deactivation request is triggering an authorization right "com.apple.system-extensions.admin", which has to be authorized using Authorization Services, even when running as root. However, there is a workaround for this too. You can grant root access to the right by running the command: security authorizationdb write com.apple.system-extensions.admin is-root That way, your background update process (assuming it is running as root) can deactivate the System Extension without a password prompt appearing. I strongly recommend that you backup the right first, before making any modifications, and restore it back to it's original state when done. Again, not that great, but does work. Omar

Hi Trace, I have encountered the same issue before on macOS 11.0.1, which I had previously raised with Apple: FB8963999. I suspect this is a bug, because on the affected systems, I was seeing crash reports for sysextd with the message: Fatal error: Activate found 2 extensions in active state, ID: bundleid, teamID("teamid"): file sysextd/extension_manager.swift, line 1371 Our product is shipped as an installer package. To work around the issue, the install script for the package was updated to deactivate the current System Extension before installing the updated Application containing the new System Extension. Not great, but does seem to stop the issue from happing and is much better solution than telling affected customers to disable SIP and use systemextensionsctl uninstall. Hope that is of some help, Omar