Sacred Grove

An immersive reading app for scripture and wisdom literature, designed by conversation first and built on a public-domain corpus. A planting note before the full case study.

The library, by conversation.

Sacred Grove is an immersive reading app for scripture and wisdom literature. The first version is iOS, built in SwiftUI, with a bundled corpus of public-domain translations and a design system carried in code. It is the project where I am testing what AI-first design actually means when the brief is “build the whole thing, not just a screen.”

This entry is a planting note. The full case study will come once the rooms are furnished. For now, here is how the project is being made.

1 Chronicles book intro on parchment with a gold roman numeral XIII drop cap, the subtitle 'Plate XIII · History · Priestly,' an opening epigraph 'Adam, Sheth, Enosh,' a brief liturgical-lens summary, and an Enter the Book · Chapter I action — A roman drop cap, a small mark of provenance, a single instruction: enter the book. 1 Chronicles is one of sixty-six rooms; the door treatment is the same for all of them.

Conversation as the first artifact

The starting point was not a sketch. It was a conversation.

Most projects begin with a moodboard, a wireframe, or a brief. Sacred Grove began in a chat window, working with an LLM agent on what a serious long-form reader should feel like in 2026. The output was a document, then another document, then a small library of working memos: a product thesis, a content model, a design principles list. Each one came out of an exchange where I pushed on the model and the model pushed back.

The discipline I keep relearning is that a chat is not a deliverable. The deliverable is a written artifact you can hand to the next collaborator, the next agent, or the next version of yourself. I now treat the LLM session as an interview that produces specifications, not a brainstorm that produces vibes.

Discover surface with a Christianity hero card showing the Sermon on the Mount, a small ideas-and-echoes-across-traditions byline, and a Continue Reading card pointing to Malachi Chapter 3 — A featured tradition up top, a small line that names the thesis ("ideas and echoes across traditions"), and a Continue Reading card that puts you back into Malachi where you left off. The opening screen makes the argument before you read a single verse.

Collecting the corpus

Before any UI, the question was what the app reads.

The answer is open content. The bundled database ships with four public-domain English Bibles: KJV, ASV, BBE, and YLT. The first imported addition is the World English Bible, fetched from eBible.org and parsed out of USFX into a per-translation table with an FTS5 search index. The next shelves are Meditations by Marcus Aurelius and the Dhammapada, both clean public-domain texts from Project Gutenberg, normalized into the same shape as the scripture tables.

Old Testament book index with five translation tabs (KJV, ASV, BBE, YLT, WEB) at the top and an editorial book list — Genesis, Exodus, Leviticus, Numbers, Deuteronomy, Joshua, Judges, Ruth, 1 Samuel, 2 Samuel — each row showing chapter counts in the gutter — Five public-domain translations sit as a tab strip at the top — KJV, ASV, BBE, YLT, WEB — so the work-first model holds: one Old Testament, five readable versions. The book list is dense and editorial, ordinals in the gutter, chapter counts on the right.

The agent did the unglamorous middle. It wrote the import script, picked the schema, mapped the book ordering, set up the full-text search virtual table, and produced a rerunnable command. My job was to decide which sources to pull, what license posture to take, and how strict to be about provenance metadata. That split is where AI-first work earns its keep: the model handles the grammar of the import, I make the editorial calls.

Analysis: finding the unit of the app

The biggest design decision in Sacred Grove came out of an analysis pass, not a Figma session.

I had a Bible reader with comparative overlays. I wanted a multi-tradition research corpus. The model and I walked through the existing code and listed every place the UI was assuming “verse.” Selection was anchored to a VerseRecord. Share cards took verse text and a reference. Compare was organized around curated Bible pairs. Music attached to chapters through Bible-only metadata.

The conclusion was that the canonical interaction object had to change. The unit of the app is not a verse. It is a PassageSelection: a pointer into any work, in any tradition, at any granularity. Copy, compare, share, annotate, link to music, link to art, every interaction builds on top of it.

Volume detail showing The Creation of Adam by Michelangelo (c. 1512) over Genesis 1:27, with an Enter the Volume action and a Collection atlas peer card flagged Work first — The Read tab opens on a volume, not a verse list. Genesis 1:27 is anchored by Michelangelo's *Creation of Adam*; the "Collection atlas" peer card sits below as another way into the work. The body of art that orbits a passage rides at the level of the text, not below it.

That is a refactor that touches almost every screen. It is also the kind of insight that is hard to land in a meeting and easy to land in a conversation where you can ask the model to enumerate every coupling in the codebase before you commit.

Design: stable shell, adaptive atmosphere

The product thesis is that the app should feel like moving through the greatest reading rooms, archives, and listening chambers in history, without literal page turns or fake bookshelves.

The principles, written before any screen:

The shell is stable. Navigation, dock, header structure, spacing rhythm, motion timing. These do not change between a Psalm and a stanza of the Tao Te Ching.
The atmosphere adapts. Background tones, hero imagery, accent metals, material density, media overlays, share-card styling. These shift with the work.
Read, listen, compare, save, and quote are peer actions. None of them is a secondary utility tucked behind an overflow menu.

The design system is a Swift file, not a Figma library. Color, type, spacing, motion, and component shapes live in DesignSystem.swift next to the views that use them. Figma is downstream of the code, not upstream.

Pray surface featuring The Lord's Prayer (Matthew 6:9-13) over the Sermon on the Mount, with a Listen action and an All Prayers list including The Lord's Prayer, The Shema, and Al-Fatiha — Same shell, two atmospheres. The Lord's Prayer is anchored in a Christianity hero; *Retreat Within* stands as pure Stoic typography on dark. Chrome unchanged, type unchanged — only the tradition's atmosphere moves. Christianity, Judaism, Islam, Buddhism, and Stoicism all share the same room.

Pray surface featuring Marcus Aurelius's Retreat Within from Meditations 4.3, set as Stoicism with a Return Inward kicker on a dark atmosphere — Same shell, two atmospheres. The Lord's Prayer is anchored in a Christianity hero; *Retreat Within* stands as pure Stoic typography on dark. Chrome unchanged, type unchanged — only the tradition's atmosphere moves. Christianity, Judaism, Islam, Buddhism, and Stoicism all share the same room.

Development: SwiftUI as the rendering layer

The app is a SwiftUI project in Xcode. SQLite is the runtime store, with FTS for search and structured tables for works, versions, sections, and segments. SwiftData holds user state: notes, highlights, bookmarks, research links. Audio is a first-class peer of text, with a mini player and a now-playing surface modeled after a music app rather than an ebook reader.

Pray surface featuring Metta (Loving-Kindness) over the Great Buddha of Kamakura, with a Playing state and a now-playing mini player at the bottom showing Tibetan Singing Bowl Meditation — Buddhism's *Metta* with the Kamakura Daibutsu as hero, a now-playing mini player anchored at the bottom, audio promoted to a peer of text. The mini player is the same primitive whether you're listening to a Gregorian chant under the Lord's Prayer or a singing-bowl track under Loving-Kindness.

The agentic workflow runs all the way through implementation. I write the brief in plain English, the model produces a Swift file, I read it the way I would read a junior engineer’s pull request, I push back on the choices that are wrong, and we converge. The loop is fast enough that the bottleneck is taste, not typing.

Why this is a planting note

A case study explains a finished thing. Sacred Grove is not finished. Right now it is a thesis, a corpus, a design system, and a working iOS build. I am writing this entry to mark the moment the workflow itself became the subject worth documenting.

The full case study will cover the screens, the typography, the audio model, the share cards, the multi-tradition expansion, and the question every AI-first project eventually has to answer: what does the human do.