A Verse Every Day is an Arabic-first Islamic companion app for Android and iOS. It puts a daily verse, dua, and hadith in front of the user each morning, calculates accurate prayer times, carries the full Quran with search, tracks the Islamic calendar, and handles personal reminders.
The decision that shaped the whole build is that the app assumes the network isn't there. Prayer times are calculated on the device, the Quran is bundled inside it, and daily content is cached the moment it arrives. A backend keeps that content fresh, but almost nothing the app does at the moment that matters — dawn, a weak signal, airplane mode — waits on the backend being reachable. I built the entire stack: the mobile app, the API, and the admin panel the team uses to run it.
Core Capabilities
A daily verse, dua, and hadith, refreshed from the backend and cached on the device
On-device prayer times, with the calculation differences that real communities follow
A live countdown to the next prayer, front and center on the home screen, alongside the day's Hijri and Gregorian date
The full Quran offline, browsable by chapter and by section, with search across the entire text and adjustable reading size
Diacritic-insensitive Arabic search that matches the way people actually type
An Islamic calendar with a manual day-shift for moon-sighting differences, plus religious occasions
A personal reminders agenda where the user can add, edit, or delete reminders on a calendar, each backed by a scheduled local notification
Per-prayer and per-content notification sounds, chosen by the user
A browsable archive of past daily content, kept rather than discarded
Broadcast announcements the team can push to every user
An Arabic-first interface, right-to-left, with dedicated Quran typography
Dark and light themes, remembered between sessions
Core Architecture
Offline-first, by design
The decision that shaped everything else: the app assumes the network is not there.
Daily content is fetched when a connection exists and written straight into on-device storage. From then on, the home screen reads from local storage, not the wire. When the app starts, it asks the backend whether anything is new; if the request fails — bad signal, airplane mode, dead server — it silently serves what it already has. The user never sees a spinner waiting on a verse. They see the verse. Reading marks, reminders, theme choice, and notification settings all live on the device too, so the app comes up fully formed before it ever reaches out.
This is the difference between an app that uses a server and an app that depends on one. This one uses it.
Prayer times are calculated, not downloaded
Prayer times are computed on the device from the user's coordinates using astronomical calculation. No request goes out to fetch them. That is what makes them trustworthy at the exact moments they matter: before sunrise, after sunset, in a basement with no signal. If the location lookup fails, the app falls back to sensible default coordinates rather than showing nothing.
But calculating prayer times is the easy part. The hard part is that there is no single correct answer. Communities differ. So the app exposes the choices that genuinely change the result: the school of jurisprudence that shifts the afternoon prayer, and a separate adjustment used by another tradition that moves two of the daily prayers by a fixed amount. On top of that, each user can nudge any individual prayer by a few minutes to match their local mosque. The coordinates also get resolved into a readable city and country in Arabic, so the user can confirm at a glance that the app located them correctly.
Notifications that fire without the server
A reminder that depends on a push from a server is a reminder that fails when the server has a bad night. So the app does not rely on remote pushes for anything time-critical.
Instead, it schedules a rolling window of notifications directly on the device: upcoming prayers, and the daily verse, dua, and hadith, each at its own time of day, plus the user's own personal reminders. Each prayer can be silenced on its own or all of them at once, and the user can assign a different sound to every prayer and every content type. When settings change — a prayer toggled off, a tone swapped, the calculation method adjusted — the app clears the affected reminders and rebuilds the schedule. The phone fires them locally, on time, whether or not it can reach the internet.
Remote push is still there, but it's reserved for what it's actually good at: occasional announcements from the team to everyone at once.
Quran search that matches how people actually type
The complete Quran ships inside the app, so reading and searching never touch the network. Search is the part that needed real thought.
Arabic text carries diacritics, and most people don't type them. A naive search would return nothing for almost every query. So the app normalizes both the query and the underlying text, stripping the marks that users omit, matches against that, then highlights the hits in the original, fully-marked verses. A result links straight to its place in the text. The reader types the way they think; the app does the reconciliation. Reading position is remembered, the reading size adjusts, verses can be bookmarked and returned to, and a reader can select a starting verse and the ones after it to copy a clean passage rather than a single line.
The Backend and Admin Experience
The app is the surface. Behind it is an API and an admin panel I built so a non-technical team can run the whole thing without me.
Everything the user reads each day — the verse, the dua, the hadith, the religious occasions, the about and contact pages — is authored and scheduled from a fast admin panel, where edits and updates happen without page reloads. The team edits content; the API serves it; the app pulls it and caches it. Past content isn't thrown away. It's kept and exposed back in the app as a browsable archive, paged so the history can grow without the app trying to load all of it at once.
The same backend is the origin point for broadcast announcements, delivered to every installed app through Firebase. The whole arrangement exists to take content off the release cycle: a new hadith, a holiday entry, an updated contact detail, or an announcement should never require a new store release, and here it doesn't.
Arabic-First, Not Arabic-Translated
This was built in Arabic from the first screen, not translated into it. The entire interface is right-to-left, dates are shown on the Islamic calendar in Arabic, and the Quran is rendered in dedicated Quranic scripts rather than a generic system font. These are the details that decide whether a religious audience trusts the product or uninstalls it in the first minute.
Performance
The app makes a deliberate tradeoff: static religious reference data lives inside the app, and only changing editorial content comes from the backend. Bundling the full Quran means reading and search are instant and never wait on a connection. The content archive pages in on demand, so a year of past verses and hadith can accumulate without the app loading all of it at once. The build also precompiles its shaders, so the interface stays smooth from the first frame instead of stuttering while the engine warms up. The common flows simply don't wait on the network.
Experience Details
A first-launch onboarding flow introduces the app, then stays out of the way
A clear navigation split: a bottom bar for the four daily areas (home, Quran, daily content, prayer times) and a side drawer for the rest, including occasions, reminders, settings, charity, about, and contact
Prayer controls sit close to the user: notifications can be turned off globally or one prayer at a time, and each prayer's time can be tuned by a few minutes
A graceful offline state: when something genuinely needs the network and it isn't there, the app says so plainly instead of hanging
My Role
Full product architecture and the offline-first approach
Flutter app for Android and iOS
Laravel 9 API and the Livewire admin panel the content team uses
On-device prayer-time engine with madhab options, the alternate fixed adjustment, and per-prayer offsets
Local notification scheduling with per-category custom sounds
Diacritic-insensitive Quran search over a bundled, offline Quran
Bookmarks, reading position, adjustable reading size, and verse-range copying in the reader
Right-to-left Arabic interface and dedicated Quran typography
Backend content workflow, the browsable archive, and the Firebase broadcast pipeline
Build First, Sync Later
The through-line of every decision was the same: the moments this app exists for — dawn, dusk, a quiet minute with the Quran — are exactly the moments a network can't be relied on. So the app doesn't rely on it. It works first, and syncs when it can.
If you're planning a cross-platform app with a content backend behind it, especially one that has to keep working offline, that's the kind of problem I like to start from. Let's talk.