Any plans to provide (a subset of) the FUSE3 API directly on top of FSKit/an underlying primitive, in a way that doesn't compromise the new security model, but also reduces porting friction?
A FUSE compatibility layer on top of FSKit represents an excellent 3rd-party opportunity. We are definitely interested in any feedback related to obstacles in developing such a compatibility layer.
I can provide feedback as a relatively long response that describes several areas where FSKit has insufficient or absence support to match FUSE3 capability. Do you want the long response in this thread? I suppose you would also like the response via Feedback Assistant?
I've submitted Feedback FB23056342, whose text follows.
This Feedback captures my response in forum topic https://developer.apple.com/forums/thread/831338?answerId=891228022#891228022 to the request by Apple Staff to detail obstacles that FSKit may have to FUSE3 compatibility, quoted here:
"A FUSE compatibility layer on top of FSKit represents an excellent 3rd-party opportunity. We are definitely interested in any feedback related to obstacles in developing such a compatibility layer."
First, thank you. This is a helpful dialog.
We maintain a production network filesystem with a FUSE3-based implementation for Linux. We also implement this filesystem with a XNU VNOP-based kernel extension implementation for macOS. We are highly motivated to move our macOS implementation into user space (via FSKit), but we see gaps in FSKit that prevent compatible implementation to match the capabilities afforded by either the XNU VNOP or FUSE3 interface.
We are not asking Apple to publish a FUSE3 shim (though that would be nice). We are asking for FSKit (or a companion interface) to expose the complete set of VFS operations that a production network filesystem actually requires. FUSE3's struct fuse_lowlevel_ops (https://github.com/libfuse/libfuse/blob/master/include/fuse_lowlevel.h) is a useful reference to define "complete set," and mapping it against what FSKit currently provides is the most direct way to surface the gaps.
Gap list: fuse_lowlevel_ops vs. FSKit (macOS 26)
Operation: getlk / setlk
FSKit status: Absent
Impact: POSIX advisory byte-range locks (fcntl F_GETLK/F_SETLK/F_SETLKW) are not delegated to the FS implementation. For a multi-client network FS this is a hard blocker: lock arbitration must involve the filesystem, which relays it to the server.
Operation: flock
FSKit status: Absent
Impact: BSD advisory whole-file locks (flock(2)) are similarly not delegated.
Operation: ioctl
FSKit status: Absent
Impact: No mechanism for applications to issue custom ioctl calls through to the filesystem daemon. We use this for filesystem-specific out-of-band control commands that have no natural equivalent in the standard VFS call set.
Operation: getxattr / setxattr / listxattr / removexattr
FSKit status: Absent
Impact: Extended attributes are not exposed to FSKit implementors at all. This is increasingly blocking because macOS system services (sandboxing, quarantine, Finder metadata, codesigning) all rely on xattr traffic flowing through the filesystem.
Operation: forget / forget_multi
FSKit status: Absent
Impact: No inode eviction notification. A filesystem cannot release server-side references for cached inodes until the kernel silently evicts them, with no callback. This makes correct reference counting and cache coherency across clients very difficult to implement.
Operation: access
FSKit status: Absent
Impact: No delegation of access(2) / faccessat permission checks. We have a full avid_access implementation for Linux that cannot be wired up on macOS.
Operation: readdirplus
FSKit status: Absent
Impact: Combined readdir + getattr in a single round-trip is a significant network performance optimization. readdir alone forces a separate per-entry getattr on every directory listing.
Operation: fallocate
FSKit status: Absent
Impact: Space pre-allocation, important for real-time media workflows where storage must be contiguous and guaranteed before a record begins.
Operation: copy_file_range
FSKit status: Absent
Impact: Server-side copy. Without this, copying a file across a network volume requires reading every byte through the client.
Operation: lseek with SEEK_HOLE / SEEK_DATA
FSKit status: Absent
Impact: Sparse file traversal. Needed for correct backup and copy semantics on files with holes.
Operation: mknod
FSKit status: Absent
Impact: Device node creation.
Operation: poll
FSKit status: Absent
Impact: No poll/kqueue notification support for FS-backed file descriptors.
The four highest-priority blockers for us, roughly in order, are: advisory locks, ioctl, xattrs, and forget notifications.
We also have a broader concern about the FSKit's protocol model.
Beyond individual missing operations, there is a structural friction: FSKit's Swift/Objective-C protocol model has per-call overhead and limited concurrency control that is architecturally different from a C-level operations table (whether that is struct fuse_lowlevel_ops, the XNU vnode_operations table, or equivalent). For a high-throughput network filesystem handling many concurrent file handles, including media workloads with large sequential I/O, this matters. We would strongly welcome a C-callable operations table, or at minimum a stable ABI that minimizes dispatch overhead, even if the sandbox and authentication model of FSKit is preserved around it.
We are happy to provide test implementations, concrete performance data, or detailed API feedback against any new interface. The OP in the WWDC26 framed our interest well: reducing porting friction while not compromising the security model.
