Horeb.

The story

Horeb is a multi-regional digital Bible app for Android and iOS. It supports six regional languages, works fully offline, and layers in AI features and subscription-based content on top of a foundation that had to be rock solid before any of that could matter.

The core challenge wasn't features — it was data integrity. A Bible app where a verse loads incorrectly, or a language pack is half-downloaded, or the app freezes while parsing scripture is not an app people trust. Every architectural decision I made was in service of getting that right.

What I built

The complete mobile app across Android and iOS — reading experience, search, cross references, a topical Bible with unlimited recursive depth, a built-in dictionary, daily verse, and an AI chat feature for scripture questions.

A self-healing data system that automatically detects when local content is stale or corrupted and repairs it without the user knowing anything went wrong.

Offline-first reading so the app is fully usable without a connection, with real-time sync that runs quietly in the background when network is available.

Authentication with subscription-based access to premium features, with proper entitlement management so users only see what they've unlocked.

In-app updates so users always have the latest content and fixes without needing to visit the store.

A crash monitoring layer that captures device-specific failures in production so issues get diagnosed and fixed before they affect more users.

How it works

The architecture is strictly layered — UI talks to Bloc, Bloc talks to services, services talk to the repository, and the repository talks to ObjectBox. Nothing bypasses this chain. That discipline is what keeps the codebase maintainable as features pile up.

I evaluated three local databases before choosing ObjectBox. Hive was outdated, Isar had been abandoned, and Drift was overkill for a workload that is essentially key-value with relationships. ObjectBox gave the right performance profile for Bible-scale data without unnecessary overhead.

The data healing pipeline runs in a specific sequence. Firebase Remote Config tells the app which language packs are available and what version each should be. A ValidatorService compares that against what's actually on the device. A FileUpgradeService decides what needs to be fetched. A FallbackPolicyService handles failed or partial downloads — if something goes wrong mid-fetch, the app falls back cleanly rather than leaving the user with broken data. The FileDownloadService pulls the pack, and Dart's compute() function runs the JSON parsing in a separate isolate so the main thread and the UI stay completely unblocked.

Concurrency is controlled in exactly one place — a single download pool capped at three concurrent fetches. No double-pooling, no race conditions, no edge cases where two services argue over the same file.

Fuzzy search with a JSON fallback handles scripture search across all supported languages. RevenueCat manages subscriptions and entitlements. Fastlane handles automated deployment to both stores. End-to-end tests are written with Patrol.

Stack

Mobile — Flutter, Dart, ObjectBox, Bloc/Cubit, AutoRoute, Dio, RxDart.

Firebase — Auth, FCM, Crashlytics, Analytics, Performance, Remote Config, Realtime DB, Vertex AI, App Check.

Monetization — RevenueCat (subscriptions + entitlements).

Tooling — Fastlane (deployment), Patrol (E2E tests), build_runner, flutter_gen, derry.

Outcomes

Horeb serves over 10,000 users reading scripture daily across six regional languages, on devices and network conditions that range from fast to unreliable.

Data loads 3x faster than the previous architecture — not from optimization tricks, but from getting the structure right in the first place.

The lesson I took from it: if you do something architecturally right, performance pays you back for free. I wrote about the full migration on Medium.