Developing a Swift iOS App (Blackbox Plans)

Context

Many capable people carry responsibility for family, business, or both, but do not want an alarmist prepper product. They want a calm place to store what matters if they are unavailable: who to contact, what to do next, and how trusted people can act without guessing.

Blackbox Plans is being built to fill that gap. The goal is runbooks plus custody of sensitive information, starting simple for first-time users and expanding into deeper operational planning over time.

What is being built

The app centers on plans that support both contingency and emergency use, with the same underlying step model presented differently depending on context. It also includes compartments and vault-style items, with a multi-step plan editor and a dedicated emergency surface for high-stress moments.

On the technical side, the app uses a single domain store (`PlanStore`) with a repository boundary so UI flows stay fast and offline-capable. The current local repository is file-backed, and sync capabilities are layered in through Supabase rather than making online access a hard requirement for core usage.

Current direction: local-first reliability first, then stronger run execution, handover semantics, notifications, and richer sync behavior.

Where it stands today

Core navigation, plan and item mutation paths, and local persistence are in place. Authenticated pull/push sync for plan graph data exists with queueing and baseline conflict handling. That gives a usable base while still exposing where the product needs deeper semantics before a wider release.

The main open work is intentional and documented: stronger runbook-first contingency detail, explicit run completion behavior, auto-generated after-action reporting, richer per-step execution fields, and onboarding and feedback polish. Attachments, notifications, and deeper merge strategy are also still in-flight.

Challenges and trade-offs

One product has to serve different audiences: people who want a simple “first plan” experience and operators who want deeper system behavior. The product strategy leans on progressive depth so advanced capability does not overwhelm early users.

There is also a clear engineering trade-off: local-first UX makes the app resilient and responsive, but it requires careful queueing, conflict handling, and trustable sync status when users are authenticated across devices.

Outcomes and next steps

The app already has a coherent architecture for shipping iterative value without rewriting core layers. Written decisions on runs, triggers, sharing permissions, and contingency versus emergency behavior are reducing ambiguity and speeding implementation.

Next steps are focused: finalize run data models and UI, align contingency detail with execution workflows, harden sync and conflict UX, and introduce clearer start permissions for collaborators versus step assignees.