Building Istiqomah: A Habit Tracker App with No Server and No Account

Istiqomah came from a simple need: I wanted a daily worship tracker that wasn’t a hassle — no account required, no ads, and most importantly, no personal data sent to any server. The idea actually started from my own discomfort installing similar apps and finding a pile of permission requests for a feature this simple.

The design principle

The design is built around atomic habits: start small, track effortlessly, watch progress grow. Features include a daily worship checklist, accurate prayer schedules (GPS-based or manual city selection), a qibla compass, a 114-chapter digital Quran with translations, an Islamic calendar with fasting-day markers, and progress tracking through streaks and a GitHub-style contribution heatmap.

The technical challenge: an architecture with no backend

The biggest challenge wasn’t the features — it was the “no-backend” architecture: all data — prayer schedules, progress, preferences — has to be computed and stored entirely on-device, with no API calls to any server for personal data. For prayer schedules, that means I can’t just call an API like most other apps do; I use a local astronomical calculation library that computes the sun’s position from the device’s GPS coordinates. The real challenge only showed up while testing at high latitudes — several classic calculation methods (Umm al-Qura, MWL, and similar) started producing odd or inconsistent results near the poles, because the solar-position assumptions those methods were built on were originally designed for mid-latitudes. I had to research and pick the most sensible fallback method for that edge case, even though realistically, most of my users are unlikely to ever be at a latitude that extreme.

Why native, not cross-platform

I built native versions for iOS (Swift) and Android (Kotlin) — not a cross-platform framework — so I could use the device’s compass sensor directly for the qibla-direction feature, and squeeze out maximum performance on each platform. The compass is one of the features most sensitive to a device’s specific sensor calibration, and I didn’t want to risk losing accuracy to an extra abstraction layer.

The privacy-vs-convenience trade-off

The “no account, no server” decision has a real cost: no sync across devices — if a user switches phones, their streak progress doesn’t automatically carry over — and I can’t offer social features like “see a friend’s progress,” since that would require a server to store other people’s data. I’m aware that cuts out features that might make the app “stickier.” But for an app that touches personal worship data, I’d rather have users trust the app completely than chase an engagement metric that requires sending their data somewhere.

The result: an app that’s light, fast, and doesn’t trade away user privacy for development convenience. Not the app with the most features compared to competitors, but one I actually trust to use myself, every day.