What it is
NoorConnect is a production iOS and Android app for Muslim prayer guidance, built for BRS Engineering. The app covers prayer time tracking, a Bluetooth-connected prayer mat, cross-platform alarm scheduling with custom adhan sounds, and a full Quran module — all running offline-first, with multilingual support across six languages.
I joined BRS Engineering in 2025 as Lead Software Engineer and inherited a disorganised legacy codebase. I rebuilt the architecture from the ground up while simultaneously shipping new features under real production pressure. I am the sole mobile engineer across the full lifecycle.
BLE prayer mat integration
The prayer mat connects over Bluetooth Low Energy. The Flutter app handles device discovery, pairing, and maintains a persistent BLE connection throughout the prayer session. Real-time sensor data from the mat feeds the app live during prayer. There is also a zen mode that responds to mat state and adjusts the in-session experience.
BLE on Flutter is more demanding than it looks. Managing connection lifecycle, characteristic subscriptions, and graceful handling of mid-prayer drops required working at the platform-channel level — not just wrapping a package.
Cross-platform alarm scheduling
Getting exact prayer alarms right on both platforms required two distinct implementations that had to feel like one.
On Android, exact alarms fire for all five daily prayers via AlarmManager, with boot recovery so they survive device restarts. Each prayer has a custom adhan sound. This required navigating Android’s evolving exact alarm permissions across API levels.
On iOS, AlarmKit (iOS 26+) handles exact alarm scheduling, with local notification fallback for older devices. iOS severely limits background execution, so AlarmKit is the only reliable path for alarms that must fire at a precise time without the app being open.
Quran module
The Quran feature ships with local caching for offline access, recitation playback settings, and multilingual support across six languages. Rendering Arabic script correctly, caching sura audio without bloating install size, and managing playback state across app lifecycle required careful design throughout the feature.
Architecture decisions
The legacy codebase had no clear structure and was difficult to extend. I rebuilt it using Clean Architecture with a feature-based folder structure. For state management I used GetX state only — not routing, not DI — which gives clean reactive state without the global-registration patterns that make GetX codebases hard to maintain at scale.
Navigation uses go_router and dependency injection uses get_it. These choices established consistent conventions the rest of the team can follow as the product grows.
What I learned
BLE connection management in Flutter is substantially more complex than the package documentation suggests. Connection lifecycle, characteristic subscriptions, and mid-session drops all require platform-native understanding.
Cross-platform alarm scheduling exposed the fundamental difference in iOS and Android’s background execution models. Android gives you low-level scheduling control. iOS resists it at every layer, and AlarmKit — still very new at iOS 26 — is the first viable path to exact alarms without background-app tricks.
Taking over a legacy codebase under production pressure sharpened my judgment about what to refactor now versus what to isolate and replace incrementally. The temptation is always to rewrite everything at once — the right answer almost never is.