Open source · live APK and Firefox add-on · 2026

Zakkir

An Arabic-first prayer and Azkar system that keeps one calm, RTL-native experience across Android, Electron desktop, and a Manifest V3 browser extension. The hard part is the shared product surface underneath platform-specific scheduling and lifecycle rules.

Role: Designer and implementerStatus: Live releasesStack: React Native, Expo, Electron, MV3, SQLite, Leaflet
Zakkir desktop home showing the next prayer, today’s prayer times, and Arabic Azkar
Desktop utility · Electron.The portrait capture is the complete desktop home: next prayer, daily schedule, Arabic reading surface, and navigation in one compact window.
Zakkir mobile home showing prayer countdown and Arabic Azkar
Android home · same renderer.The hierarchy compresses into a focused RTL experience with the prayer countdown and Azkar content intact.
3shared product surfaces
138bundled adhkar entries
114defined CSS themes
31automated tests

01 · Architecture

One renderer, three platform shells.

The product’s visual consistency comes from a shared renderer and data contract. Electron, Android, and Manifest V3 each add their own lifecycle and permission behavior, but the prayer and Azkar experience stays recognizably the same.

Shared experience layer

Reusable views, settings, themes, Arabic typography, bundled content, and the core prayer-time presentation are composed once, then hosted by each target.

Dataprayer times, 138 adhkar, settingsRendererRTL views, themes, countdowns, summariesShellnotifications, storage, lifecycle, packaging
WIN
Electron desktopalways-on-top window, reminders, sounds, bundled assets
AND
Android / Exponative notification channels, location, long-horizon scheduling
MV3
Firefox extensionbrowser lifecycle, extension packaging, shared settings
What belongs in the shared layer?

The shared layer includes the content model, countdown and progress presentation, morning/evening automation, Arabic fonts, Basmala and Istiadhah rendering, themes and accent colors, settings, summary views, and the platform-neutral visual rhythm. Scheduling and storage remain adapters because each shell has different constraints.

02 · Time and reliability

Notifications are a rolling schedule, not a daily illusion.

Prayer times change. The scheduler therefore creates a finite horizon, refreshes it, and cancels/reschedules when settings or location change. It does not pretend that one day of alarms is an eternal schedule.

One rolling Android horizon · up to 420 scheduled notifications · explicit refresh and cancellation behavior

Platform-specific rules, one user promise.

Desktop polls and refreshes. Android holds a 28-day schedule and respects channels/silent behavior. The Firefox surface follows its own extension lifecycle and storage constraints. Desktop and Android deduplicate, cancel, and reschedule rather than stacking stale reminders.

  • Before / at / after: offsets are part of the schedule model.
  • Location: GPS, map, city, or manual coordinates can drive recalculation.
  • Graceful state: cached times remain readable when the network is absent.
  • Bounded horizon: Android schedules up to 420 notifications at a time.

03 · Visual system

A theme wall, not one hard-coded skin.

The app defines 114 CSS themes, with 16 featured in the primary visual system. Themes change accent, background, typography, and component atmosphere while keeping the Arabic reading experience legible.

DunePalmPlumRoseBlueGoldOliveBerrySeaStoneEmberSlateLeafIrisSaffronLagoon
RTL by default

Typography carries meaning.

Bundled Arabic fonts and deliberate Basmala/Istiadhah rendering protect rhythm and readability instead of treating Arabic as a translated afterthought.

Offline first

Content travels with the app.

Adhkar and cached prayer data remain available without connectivity, with reminders and summaries built around the same state.

Tested behavior

Visual polish has a contract.

31 automated tests cover RTL, settings, themes, scheduler behavior, midnight edges, and platform-facing interactions.

04 · Release engineering

The same product ships through different platform pipelines.

Zakkir is packaged for Windows, Debian, AppImage, Android, and Firefox. GitHub Actions builds the release surfaces, while platform adapters keep packaging, storage, permissions, and scheduling concerns out of the shared Arabic-first experience.

Desktop

Electron builds

Windows, Debian, and AppImage packages share the renderer, bundled content, fonts, themes, and desktop reminder adapter.

Mobile

Android APK

Native notification channels, location access, and the 28-day scheduling horizon are explicit mobile responsibilities.

Browser

Firefox add-on

Manifest V3 packaging, popup constraints, extension storage, and settings wrap the same prayer and Azkar core.

State changes

Recalculate from the source.

A location or method change refreshes prayer times before dependent countdown and reminder state is rebuilt.

Reminder changes

Cancel stale events.

Offsets and notification preferences regenerate bounded schedules with deterministic identities instead of accumulating duplicates.

Boundary tests

Protect midnight transitions.

Automated tests cover the day boundary, RTL rendering, settings, themes, scheduler behavior, and platform-facing interactions.

05 · Product in motion

Watch the released surfaces.

The two walkthroughs show the experience running on Android and Firefox. The Android recording keeps the same 9:20 phone proportions as the app itself; the Firefox recording stays in its wide browser frame. The APK is available for a hands-on review of the mobile build.

Android walkthrough · 1:33Prayer countdown, Arabic reading, navigation, and reminder surfaces in the mobile build.
Firefox walkthrough · 1:01The extension popup and its compact browser surface running as a released target.