Current stage: the native SwiftUI foundation exists and security feasibility work uses synthetic data only. This page describes the approved architecture direction and release gates—not completed protection.
Native by design
Inner Vault is being built in Swift and SwiftUI for iPhone, close to the security and lifecycle guarantees iOS actually documents. Apple frameworks provide the interface, camera and audio foundations, file protection, Keychain integration, and hardware-backed cryptographic operations. Dependencies stay narrow, pinned, and independently reviewed.
Not a lock screen over ordinary storage
The interface does not own cryptographic keys, persistence transactions, capture engines, or export authority. A central session authority controls whether sensitive work may occur. Locking is intended to stop operations, close protected files, conceal pixels, invalidate capabilities, and release usable key material—not merely replace one screen with another.
Independent keys, bounded damage
The planned format gives every item its own random content key. A vault master key wraps those item keys, while normal unlock combines an owner-held passphrase with a device-bound factor. Recovery is a separate, domain-separated path protected by an app-generated owner-held secret. Cross-path substitution must fail.
Private capture as a data pipeline
The camera and recorders are being prototyped so captured material can move toward authenticated encryption without entering Photos or becoming a persistent plaintext working file. Cancellation, interruption, low storage, memory pressure, device lock, and force quit are part of the design—not afterthoughts.
Metadata is content
A private original with a plaintext filename, thumbnail, transcript, search index, waveform, or timestamp can still betray a person. Inner Vault’s design treats derived content and descriptive metadata as sensitive. The storage format must authenticate structure, bound allocations, resist malformed input, and recover transactionally after interruption.
Protection while content is visible
Encryption at rest cannot protect material already on screen. Documented lifecycle and capture-state controls are required to conceal sensitive pixels during backgrounding, mirroring, recording, or external-display exposure. Any undocumented rendering technique remains defense in depth and will never be presented as an unconditional iOS guarantee.
Recovery before real content
A private tool that silently loses the owner’s material has failed. Inner Vault will not accept real private content until a complete encrypted recovery package has been created, moved away from the device, restored into a clean installation, and reviewed against corruption, rollback, key loss, and interrupted export.
One app, every way in
VoiceOver, Voice Control, Switch Control, Dynamic Type, keyboard access, Reduce Motion, strong contrast, and non-colour cues are evaluated across complete tasks. Security must not quietly disable the assistive technology its owner relies on, and accessibility must not casually expose sensitive content to system surfaces.
Evidence, not confidence
Deterministic tests, adversarial fixtures, physical-device inspection, operating-system matrices, interruption testing, and independent security review are release gates. If a protection cannot be demonstrated, the claim narrows or the feature waits. The developer’s confidence is not evidence.
Engineering in service of ownership
The technical goal is not complexity for its own sake. It is a quiet tool where the difficult work happens underneath, the person can understand the important consequences, and the developer never becomes necessary for ordinary access to someone else’s material.
The app should feel calm because the complexity has been carried carefully—not because risk has been hidden.