The File Provider API is very limited. In particular, it can't be used to implement file systems where the directory hierarchy is dynamic. It can't materialize directories on `chdir(1)`, for example.
The design was obviously tailored for providers that implement real disk files, like Dropbox and Apple's own iCloud Drive.
Btw, Apple also ships with an undocumented 9P implementation. It seems to be used for mounting the host filesystem in virtualized guests. It is unclear if it can be made to work over a normal (non-PCI) transport like TCP.
I found the api incredibly hard to use as someone who hasn't used swift or macOS API's before. Because of the way some of the code runs as a separate plugin from the main app, you can't really use traditional logging as a debug tool. There is also a lot of split state to be handled. You have to provide sync anchors and diffed tree updates to change the folder contents, which just aren't available with most backends.
I started on a program to mount a website resource directory on your computer using this api, but I gave up due to the restrictions of the api: https://github.com/mathiasgredal/Itslearning
I meant why not make a project like this that emulates the FUSE API, but use the file provider API to present the file system to the OS instead of NFS. It would have the advantage that it would be better integrated with the OS, for example you can display upload progress indicators on files in Finder. Maybe that can also be done with NFS though, I don't know.
The design was obviously tailored for providers that implement real disk files, like Dropbox and Apple's own iCloud Drive.
Btw, Apple also ships with an undocumented 9P implementation. It seems to be used for mounting the host filesystem in virtualized guests. It is unclear if it can be made to work over a normal (non-PCI) transport like TCP.