PhantomProtect is our first planned release. Alongside that work, PhantomVault now has a native filesystem foundation and a movie carrier that can hold encrypted files. This development update explains what those changes mean and the work ahead.
The suite remains in development. This article was first published on August 18, 2026 and has been updated to reflect the current release plan.
PhantomVault uses a native filesystem
Earlier PhantomVault prototypes used macOS disk image tools to create and attach Vaults. The native development path now creates encrypted containers and mounts them through a dedicated filesystem extension, giving Finder a volume that serves the Vault’s files.
Apple introduced FSKit in macOS 15.4. PhantomVault’s selected creation and Finder-mounting path uses newer macOS 27 APIs, so the framework’s original availability does not establish compatibility for this implementation. Native Vault creation and mounting currently require macOS 27 or later.
When you unlock a Vault, the app checks your credentials and authorizes the filesystem to open it. Finder can then work with the files inside. This lets us build creation, everyday file use and safe eject around the same filesystem.
Testing needs to follow that whole experience: create a Vault, open it in Finder, work with files, eject it and reopen it after a restart. Recovery after an interrupted operation is part of the same work.
The movie carrier keeps a playable film alongside encrypted files
PhantomVault’s movie option preserves a complete playable MP4 and stores the encrypted Vault data in an additional part of the file. Finder and a movie player can read the film, while PhantomSecure can open the protected filesystem after authorization.
The original update described a development example using 300: Finder could preview the film, a movie player could play it, and PhantomSecure could open the Vault. We need to repeat that experience across supported systems and after changes to the Vault’s contents as part of release testing.
Movie creation reserves the file’s full size at the start. The creation flow also assesses the proposed size against the cover movie’s duration and resolution, helping a person choose a suitable cover and capacity. Preserving the film’s media information lets ordinary previews remain useful.
The playable film gives the carrier a credible everyday purpose and supports the plausible deniability we’re developing for PhantomVault during ordinary inspection. Someone can preview or watch the movie while the vault stays locked. A specialist may still identify unusual media structure or an unreferenced data region, and older copies or device records may reveal additional information.
PhantomProtect must stay dependable across updates and restarts
PhantomProtect is being built for automated threat detection and response. PhantomWatch has a separate role in network visibility and manual firewall decisions. Protect’s continuing work connects the main app’s controls to the background Agent and the extensions that enforce selected protections.
The August update highlighted work on component version checks, replacing outdated extensions, authenticated health signals, and communication after an update. These tasks address a practical failure case: the app can be open even when an enforcing component is missing, outdated, or unable to confirm its state.
An active-protection display therefore needs fresh evidence from the components doing the work. If enforcement cannot be confirmed, the interface must explain the condition and any required action. Detection, quarantine, restoration, and remediation also need validation together, including what happens after an interrupted operation or restart.
Protect targets macOS 26.5; native Vault mounting requires macOS 27
The current app and protection targets specify Apple silicon and macOS 26.5 or later. PhantomVault adds the macOS 27 requirement for its native creation and Finder-mounting APIs. These are development requirements; the final supported combinations still need release validation.
The separate requirements allow the Protect release to move ahead without waiting for every planned Vault feature. Before launch, we still need to verify protection, privacy, account access, installation and updates together. Paid access also needs its own validation.
URL Filter approval and production validation remain open
PhantomProtect’s planned URL filtering follows Apple’s NetworkExtension URL Filter architecture: an on-device prefilter handles initial checks, and private database lookups resolve possible matches. Apple describes a distribution onboarding process for this capability.
The URL Filter still needs Apple approval and validation with the production service before it can be enabled for customers. That work is one of several steps ahead of launch.
For Vault, testing includes sustained Finder use, safe eject, interrupted operations, lost credentials and movie playback after files are changed. External review of encryption and key handling is also required before public release for protecting confidential files. The roadmap tracks these areas as they progress.