Appendix K: Claudes X26 Swift6 Bible — iPad Reader App (Shop Manual)

Status: v1.0 pre-release. Created 2026-04-20. Distribution-ready binary for iPhone, iPad, and Mac (via Designed for iPad on Apple Silicon). GPL v3 — share and share alike, attribution required. Public repo at github.com/fluhartyml/Claudes-X26-Swift6-Bible. Claudes X26 Swift6 Bible is the native SwiftUI reader engine for this book's content vault. The vault is a tree of HTML rich-text documents (Books, Appendices, Lexicon Pages, Build-Alongs, figures); the app renders any of those files inline via WKWebView, with a sidebar that mirrors the vault's folder structure.

What it is

A universal reader for the book's HTML vault. The vault is the canonical authoring format — HTML, not markdown, because rich text survives the trip to print and EPUB without a translation step. Obsidian was considered as the authoring surface and is good at file-tree navigation and full-text search, but it does not render standalone .html files inside its own panes. The reader app fills that gap with a SwiftUI shell + WKWebView content pane.

The reader serves three roles at once:

  1. Authoring navigator while the book is being written.
  2. Reader app for anyone consuming the book on iPhone, iPad, or Mac.
  3. EPUB packaging cockpit — the vault's HTML files are already EPUB-shaped, so building an EPUB is a package step, not a translation step.

The final paperback and EPUB still ship through Apple Books, Amazon, and the other print / EPUB venues. The reader app is the in-house tool that makes the vault usable as a vault rather than as a folder full of HTML files.

Architecture overview

SwiftUI app, no SwiftData, no networking. The data is the vault — a bundle of HTML files copied out of the app target into Application Support on first launch.

File roles:

The vault — data and folder structure

The vault lives at ~/Developer.complex/Claudes-Xcode-26-Swift-Bible/ during development and inside Application Support on a reader's device. The structure mirrors the reading order:

Every leaf is a standalone HTML file with its own <head>, styles, and hyperlinks. The folder tree IS the table of contents.

Rendering pipeline

When the user selects a sidebar entry:

  1. ContentView resolves the selection to a file URL via VaultModel.
  2. The URL is passed to VaultWebView, which is a UIViewRepresentable wrapping WKWebView.
  3. The web view loads the file via loadFileURL(_:allowingReadAccessTo:) with read access scoped to the vault root, so relative links to images and other HTML files resolve.
  4. Hyperlinks the user taps go through VaultURLSchemeHandler, which intercepts vault-relative paths and routes them to the appropriate file inside the extracted vault rather than handing them to Safari.

First-launch extraction

The Bible vault ships inside the app target as a flat-layout resource bundle (BibleContent.bundle). On first launch:

  1. OnboardingView shows a brief progress affordance.
  2. VaultBundleExtractor walks the flat bundle and copies each file into its proper subfolder inside Application Support, using targetPath(forFlat:) to route Books to Part-N/, Build-Alongs to Part-VII-Dedicated-Build-Alongs/{folder}/, Lexicon Pages to Part-II-The-Swift-Language/Chapter-X/, and so on.
  3. Subsequent launches skip extraction and read directly from the Application Support copy.

The flat-layout source + structured-layout destination pattern is what Book 11 references as a complete extract-from-bundle FileManager example.

Build + deployment

Relationship to other projects

Known gotchas

Roadmap status

v1.0 (MVP — Vault Reader)

v1.x — Pending

Sources