MySolat: Precision Offline Islamic Habit Platform

Beyond the Commodity Prayer Clock

The mobile app ecosystem is saturated with generic prayer utility apps. Most treat Islamic daily prayers as passive wall clocks: a user opens the app, glances at the upcoming time, and closes it. They fail to address the core human desire: building sustained, daily spiritual consistency.

I designed and built MySolat around behavioral habit mechanics. Instead of a dead timetable, MySolat operates as an active spiritual journal: tracking prayer completion streaks, recording personal reflections, providing daily Quranic insights, and delivering reliable Adhan notifications without draining battery or requiring internet access.

Exhibit 1.0 · MySolat home dashboard: high-contrast solar progression timeline, upcoming prayer countdown, and 1-tap completion logging.

Solar Geometry, Out-of-Sample Testing & Highland Anomalies

Most Islamic apps rely on generic open-source calculation libraries (such as raw AlAdhan formulas). In early development, I benchmarked my calculations against AlAdhan and thought they were accurate. However, I realized a fundamental flaw: AlAdhan simply runs the same generic mathematical equations, so matching it proved nothing.

When cross-referenced against actual published national timetables, generic calculations drifted by 2 to 21 minutes across the Balkans, Turkey, North Africa, and Southeast Asia. In Islamic practice, praying even two minutes before the official call can invalidate a prayer. To solve this, I built an offline solar geometry engine paired with empirical authority calibration.

Every religious authority uses this same underlying physical model. They differ only in their local parameters: twilight angles, ihtiyat (safety buffer) minutes, rounding rules, and zone reference coordinates. MySolat encapsulates each country into a lightweight method file containing that authority's exact parameters and quirks. The engine runs offline with zero yearly expiry, ensuring users receive accurate times forever without recurring server downloads.

Out-of-Sample Authority Verification (15 Countries)

To ensure I discovered each authority's authentic mathematical methodology rather than overfitting numbers to a single year, I implemented strict out-of-sample testing. I fit the method file on one baseline year, then verified it against independent historical and future years published by the authority:

• Saudi Arabia (Umm al-Qura): Fitted on 2025, verified out-of-sample against 2026, 2027, 2030, and 2035.
• UAE (Awqaf), Bosnia (IZ BiH), Oman: Verified across 2025, 2026, and 2027.
• Algeria (MARW): Cross-checked across two separate Hijri calendar years.
• Turkey, Kosovo, North Macedonia, Bulgaria (Diyanet): Benchmarked against full 2026 published municipal tables.
• Indonesia (Kemenag): Fitted on 2026 and validated against 2025 and 2027 across all 517 regencies.

An automated test fails if any prayer on any single day deviates by more than 1 minute. Successfully matching years the engine was never fitted on proves the underlying authority algorithm was recovered.

Malaysian Geospatial Edge Cases: Zon Khas & Rompin

In Malaysia, assigning prayer zones purely by administrative district polygons introduces severe timing errors. Through rigorous field analysis, I resolved two major geospatial anomalies:

1. Highland Altitude Anomalies (Zon Khas)

JAKIM defines Zon Khas (Special Zones) by a reference coordinate and elevation, not by a boundary polygon. Each special zone physically resides inside another district's polygon. A pure district polygon query returns the surrounding lowland zone, introducing massive real-world prayer time shifts:

The Solution: I engineered a dedicated Zon Khas spatial layer evaluated prior to polygon searches. Each zone is defined as a point coordinate with an intentional ~8 km tight radial threshold. Coordinates were extracted from JAKIM's official Penyelarasan Zon-Zon Waktu Solat documentation and cross-checked by calculating longitude backwards from published solar noon (Zohor). The radius is deliberately constrained: a highland user outside the circle can manually select their zone, but lowland residents will never be accidentally assigned highland times.

2. Rompin (PHG07) Sub-District Mukim Slicing

JAKIM divides Pahang's Rompin district at the mukim level: Mukim Rompin, Endau, and Pontian belong to PHG07, while Mukim Keratong (Muadzam Shah) remains in PHG02. A standard district boundary cannot express this division (Kuala Rompin at 2.8146, 103.4867 incorrectly returns PHG02 on generic APIs).

Building PHG07 from geoBoundaries ADM3 mukim polygons uncovered three subtle traps:

• Town Enclave Cutouts: Municipal areas (Pekan Kuala Rompin, Bandar Rompin I to IV, Bandar Pontian, and Bandar Endau) were cut out of mukims as separate units. Using mukim boundaries alone created hollow polygon "holes".
• Cross-State Name Collisions: Identical mukim names across Malaysia were merged into single shapes. For example, "MUKIM ROMPIN" erroneously combined Pahang's Rompin with Jempol's Mukim Rompin in Negeri Sembilan (NGS01), and "MUKIM PONTIAN" merged with Pontian, Johor.
• Coastline Slivers: ADM3 mukim coastlines diverged from official district maps, causing coastal users to fall outside all zones.

The Solution: I constructed PHG07 by subtracting Mukim Keratong and Muadzam Shah from the master Rompin district boundary, snapping to within 500 meters of the three target mukims and municipal towns. PHG02 was assigned the district remainder. Both zones share an exact border and preserve the official district coastline.

3. 165 km Sanity Fallback Circuit Breaker

To prevent anomalous polygon assignments (such as detached administrative exclaves in Putrajaya), MySolat applies an anomaly threshold: if a matched polygon centroid is greater than 165 km from the device's GPS coordinate, the polygon result is rejected and falls back to nearest-neighbor spatial distance.

Conquering Android 15 Doze Mode & OEM Killers

The single most difficult engineering challenge in mobile utilities is background alarm reliability. Aggressive OEM power-saving algorithms (Xiaomi MIUI, Samsung OneUI, and Android 15 Doze Mode) routinely kill scheduled timers, causing users to miss Fajr (pre-dawn prayer).

I engineered a hardened, multi-tiered alarm architecture in Flutter and native Kotlin:

• Unified Alarm Singleton: Replaced fragmented scheduling plugins with a unified Android Foreground Service using exact AlarmManager.setExactAndAllowWhileIdle() triggers.
• Dynamic 30-Minute Cancellation: MySolat schedules a gentle 30-minute reminder before prayer expiration. If a user logs their prayer early, the system immediately queries the active alarm registry and cancels the pending reminder, eliminating irritating false alarms.
• Zero Background Data Leakage: All prayer calculations run completely on-device. The app requires zero server roundtrips to calculate times, protecting user privacy and ensuring alarms fire even in airplane mode.

Exhibit 2.0 · MySolat habit analytics: daily completion streaks, missed prayer attribution, and monthly consistency charts.

Visual Restraint and Sacred Ergonomics

Spiritual applications require cognitive calm. Flashing banners, loud colors, and distracting advertisements degrade the sacred experience.

• Dark Surface Token System: Built on a deep charcoal foundation (#121212 background with #1E1E1E cards) paired with an energetic neon lime brand accent (#9CFF65) for active countdowns and prayer badges.
• Scripture Typography: Integrated the authentic King Fahd Glorious Quran Printing Complex font (KFGQPC Uthmanic Hafs) for Arabic scripture, paired with geometric Poppins for UI legibility.
• Dampened Qibla Compass: Raw mobile magnetometers oscillate wildly indoors due to electromagnetic interference. I implemented low-pass sensor filtering and mathematical smoothing to provide a calm, jitter-free Qibla pointer.

Exhibit 3.0 · MySolat Qibla compass: smoothed sensor dampening with degree alignment and Kaaba coordinate calculations.

The Quran Khatam Engine & Gender-Specific Considerations

Completing the recitation of the Quran (Khatam) is a primary goal for many Muslims, especially during Ramadan. Most apps provide a static PDF without pace guidance.

• Adaptive Pace Calculator: Users define a target completion date (e.g., 30 days) or daily page goal. MySolat dynamically redistributes required daily readings across the 5 daily prayer windows (e.g., "Read 4 pages after Asr"), recalculating pace if a user falls behind.
• Dignified Female Exemption Tracking: Islamic jurisprudence exempts women from prayer during menstruation and post-natal bleeding. Standard prayer apps penalize women by breaking their completion streaks. I designed an explicit exemption toggle (specialPink token) that pauses streak tracking respectfully without counting days as missed.

Exhibit 4.0 · MySolat Quran in Daily Life discovery engine: curated thematic guidance for protection, healing, exams, and daily comfort.

Measurable Organic Impact & Engineering Truths

With zero paid advertising or marketing spend, MySolat grew organically purely through word-of-mouth:

• Domain accuracy creates defensibility: Verifying math against official religious institutions rather than relying on generic third-party APIs was the single biggest driver of positive 5-star reviews.
• Background execution is a platform war: Mobile operating systems are increasingly aggressive toward background services. Building reliable offline alarm systems requires understanding native OS lifecycle internals.
• Habit design over passive utilities: Adding streaks, daily reflections, and pace calculators transformed a 10-second utility into a daily anchor in users' spiritual routines.
• Product-Led Growth & Friction Elimination: Eliminating the mandatory login gate and moving to 1-tap inline micro-interactions grew monthly sessions by +73.5% and completed habits by +124.2%. Full growth metrics and funnel breakdown in the companion case study →