This market resolves YES if, on or before December 31, 2026 (America/Los_Angeles), Apple’s public, non-beta documentation and corresponding macOS/Xcode SDKs show that FSKit (or its renamed successor) provides a public user-space filesystem API with all of the following:

1. Read-write mounting: A third-party FSKit module can mount a local, read-write filesystem that is accessible via normal POSIX paths (no private/Apple-internal entitlements; standard FSKit entitlement is acceptable).

2. Core POSIX semantics: Documented support for creating, reading, writing, and deleting files and directories; renames; hard links and symlinks; Unix permissions and ACLs (or documented macOS equivalent); and extended attributes. (Sparse files supported if documented, but not required for resolution.)

3. Durability primitives: A documented mechanism to honor fsync/FDATASYNC (or an explicitly documented equivalent) so a filesystem can provide crash-consistent persistence semantics.

4. Public availability: The relevant APIs are marked public (not beta/preview), included in a shipping macOS release and its Xcode SDK by the deadline, and usable by third parties with the standard FSKit entitlement.

Notes

• The market resolves solely on Apple’s public docs/headers/release notes; no third-party implementations or demos are required. But a third-party ZFS for MacOS implementation would be sufficient to show that the API has the necessary features.

• If any required capability above is missing or only available via private APIs or kernel extensions by the deadline, resolves NO.

• If FSKit is renamed but clearly remains Apple’s user-space filesystem framework, treat it as FSKit.