Psalm Path
A quiet, offline companion for a life of faith — and an archive of it that gets better the longer you own it.
- Product design, iOS engineering
- Swift 6 · SwiftUI · GRDB / SQLite + FTS5 · StoreKit 2 · Modular SPM packages
- iOS 18+
- 2026
Executive summary
Psalm Path is a private, offline Christian companion for iOS: Scripture, prayer, a short daily practice, and — the part that actually distinguishes it — a record of your own walk that accumulates. Every highlight, prayer, finished journey and answered request is deposited into an archive on the phone, and the archive is the thing you cannot get anywhere else.
I designed and built it end to end. The interesting design problem was not the reading experience — that category is well solved — but the positioning: every major competitor in 2026 is racing toward cloud accounts, social graphs, engagement mechanics and an AI assistant on the home screen, which leaves a specific and completely unserved position open.
"A place to spend time with God — no feed, no noise, no streaks to lose."
— the positioning sentence the whole product is held to
- 5
- public-domain translations, none paywalled
- 9
- devotional classics, human-authored
- 0
- accounts, servers or runtime model calls
- 9
- convictions enforced as build invariants
Product context
Bible apps are consumed and forgotten. You read a chapter, you highlight a verse, you pray for a friend — and none of it is anywhere in particular a year later. The category optimises for daily opens, and daily opens are a measure of the app's health, not of yours.
Meanwhile the mechanics used to produce those opens — streaks, badges, chains you can break — attach guilt to a spiritual practice. That is a strange thing for devotional software to do, and it is nearly universal.
The gap is not a feature gap, it is a values gap: the app that requires no account, sends nothing anywhere, runs no model while you use it, and gets better the longer you own it. Values gaps produce the durable kind of loyalty — someone with three years of prayers in Psalm Path does not switch, and no competitor can import that archive.
| Product | Genuinely great at | Structural weakness we design against |
|---|---|---|
| YouVersion | Free, universal, enormous reach, plans with friends | A distribution product: your data is theirs, on their servers, and AI features now sit front and centre |
| Hallow | Guided audio prayer with extraordinary production values | Audio-first, tradition-specific, account-required and network-dependent |
| Glorify | Beautiful daily-routine UX and slick onboarding | The routine is the whole product — a user ends up with a habit rather than an archive |
| Day One / Apple Journal | The private-journal craft worth admiring | Not Christian, and Scripture is not a first-class link type |
- Translation count. There will never be NIV or ESV, so no feature may assume there will be.
- Audio library size — ceded to the apps built around it.
- Reach. The goal is not half a billion installs; it is a much smaller number of people who will not leave.
- Social. Not in v2, not in v3. A feed is the thing this product is defined against.
Convictions as invariants
The convictions page is not a marketing surface. Each line is an engineering rule, and the interesting design work was translating a value into something the codebase can actually enforce — because a promise that lives only in copy decays the first time a deadline argues with it.
| Conviction | What it means to the user | How the code enforces it |
|---|---|---|
| Scripture is never paywalled | All five translations, every chapter, the audio, your journal and your prayer list are free. The subscription opens the material written around the Bible — never the Bible, and never anything you wrote. | The reader has no entitlement check to fail; gating is opt-in per content item rather than a switch someone could flip globally. |
| Scripture is never generated, and every text says where it came from | No model touches Scripture or the devotional library. The app's own writing is disclosed as AI-assisted, on the wall, rather than quietly implied to be human. | Generated text can only enter through an attribution kind that forces a visible label, so shipping an unlabelled line is a type error rather than an oversight. |
| There are no streaks to lose | Rhythm is the days you practiced lately, not an unbroken chain. Every morning, the mercies and the count are new. | There is no streak-loss state anywhere in the data model, so the guilt mechanic cannot be added later by a product decision alone. |
| Your prayers never leave your phone | No accounts, no server for writing to reach. Prayer and journal text travels in a wrapper that refuses to print itself, so it cannot slip into a log by accident. | The analytics contract accepts only typed, non-free-text properties. There is no string escape hatch to leak through. |
| No feed, no algorithm, no noise | The app is a place you visit and leave filled, not a stream engineered to hold you. It measures meaningful completion, never screen time. | The metric the business is allowed to optimise is written into what the analytics layer can even express. |
| Scripture is never a ransom | Nothing is locked behind finishing a reading or ticking a box. No quota, no chapter held back until it has been earned. | Progress cannot be used as a lever, which removes the most common retention mechanic in the category from the toolbox entirely. |
The content pipeline is held to the same standard. Every Scripture reference is resolved against the Bible bundled on the phone before the app is built; every correct answer in the thousand-question bank has to be supported by the text of one of its own citations; every guided fast has to name who should not keep it, and every prayer journey has to say what it does not promise. The build fails rather than ship something that falls short.
The hardest one to write was the second. The app's own reflections, study answers and photography were drafted with AI assistance — and the honest move was to say so on the wall rather than let a "no AI" line do marketing work it could not survive. What is guaranteed instead is narrower and true: no model touches Scripture or the devotional library, nothing is generated while you use the app, and every text names its source.
The archive
Everything else in the product is table stakes. This is the part that is actually the product: Psalm Path is deposited into rather than consumed.
Every meaningful action — a highlight, a prayer, a finished journey, a sermon note, a prayer marked answered — writes to an append-only event log. That log feeds two surfaces: My Journey, which shows the shape of a practice (what you have read, what you return to, what you have prayed for), and My Story, a chronological narrative of your life with God, assembled automatically.
The sequencing decision that mattered most: the event log shipped in v1, even though My Story did not render until v2.
If the log had started when the feature shipped, every early user would have opened the signature surface to an empty screen — and the signature surface is the entire retention argument. Logging is cheap; retroactive history is impossible. It is the clearest example in the project of a design decision that is invisible in the interface and decisive for the product.
Progress is measured without guilt, which is a data-model choice before it is a visual one: rhythm is days practiced within a window, and there is no streak-loss state to render. The Journey map fills in as you read — an accumulating picture rather than a chain that can break.
Key screens
Design & architecture
Quiet, warm and photographic. The interface gets out of the way of two things — the text of Scripture and the user's own writing — so the design system spends its energy on typographic rhythm and reading comfort rather than on chrome. Imagery is used at full bleed as a place to arrive, then withdraws entirely once you are reading.
- All product code lives in compiler-enforced modules —
ScriptureKit,Persistence,DesignSystemand one module per feature. Features never import each other; a composition root wires them together. - That boundary is what makes the convictions checkable rather than aspirational: Scripture rendering lives in one module, and generated text can only enter through an attribution type that forces a visible label.
- Persistence is GRDB over SQLite with FTS5 for search, local-first by construction — there is no networking code that can reach the user database, which is what turns the privacy claim from a promise into a property.
- Swift 6 with strict concurrency, so the offline-first data path is verified by the compiler rather than by hoping.
An earlier specification carried an AI assistant, semantic search, a Postgres backend with row-level security, church claiming and verification, and accounts with an outbox sync. All of it was removed. Once no user data leaves the device there is nothing left to authorise server-side, and a solo-operated product cannot honestly run a moderated places directory. Deleting a backend, an architecture decision record and two models is cheap; carrying them into v1 would not have been.
Challenges & trade-offs
The honest version of the AI claim was worse marketing and better design
"No AI wrote a word of this" was the line I wanted, and it was not true of the app's own reflections and photography. Replacing it with a narrower, literally-true set of guarantees — nothing generated at runtime, no model near Scripture, every text attributed — costs a punchy slogan and buys a claim that cannot collapse. Positioning built on a half-truth fails all at once, and usually publicly.
Refusing engagement mechanics means refusing the measurement too
Removing streaks is easy. Removing the ability to notice you are losing users without them is the actual cost — the analytics contract accepts only typed, non-free-text properties and the product measures meaningful completion rather than screen time. That is a deliberate blindness, and it means product decisions lean on qualitative evidence far more than a category norm would.
Ceding translations narrows the market permanently
Five public-domain translations means never having the one a given church reads on Sunday. That is a real, permanent reason for some people not to use the app, accepted so that Scripture can stay free and un-paywalled — licensing is what forces the paywall in most competitors. The constraint has to be designed around rather than apologised for: no feature may assume a translation the product will never have.
An app that points away from itself
Psalm Path is built to move someone toward a real church rather than to substitute for one, and it says so. Designing a surface whose success condition is the user closing the app and going somewhere else is a genuinely odd brief — location is optional, a place can be typed instead, and refusing changes nothing else in the product.
What's next
- My Story deepening now that real event logs have accumulated — the narrative gets more interesting the more history it has to read.
- More devotional works in the library, since the public-domain corpus is large and the pipeline that validates them already exists.
- A wider accessibility pass across the newer surfaces, holding them to the contrast and reduced-motion standard the reader was built to.
- Keeping the convictions honest as the product grows — every new feature has to be checked against nine invariants, and the answer is sometimes that the feature does not ship.
Tessera
A marketing site for a browser cloud that AI agents use to work on the open web. The audience is engineers, so the page sells with code instead of adjectives.
