This article is published in English.
Shipping Feyz: a React Native faith-reflection app from side project to stores
How a TypeScript React Native codebase moved Tawakkul to Feyz, through store governance, older-device performance, and a distraction-free reflection UX.
Many engineers keep a quiet goal of taking an independent idea from a blank repository all the way into public stores. That milestone can feel distant for a long time. With a cross-platform mobile product named Feyz—which began under the working title Tawakkul—that goal became a shipped App Store and Play Store binary. Among React Native projects, this one stands out as especially meaningful because it forced production decisions rather than tutorial comfort.
Product origins and a clearer UI direction
Feyz did not appear from nowhere. Progress accelerated after collaboration with a peer developer who introduced cross-platform native frameworks and offered ongoing mentorship through the early learning curve.
The product vision was a polished, low-distraction space that helps people fold spiritual awareness and daily faith reflections into busy schedules. Looking at existing apps in the same category revealed a sharp gap. Many titles either buried the experience under cluttered, dated interfaces or dragged attention down with sluggish, poorly optimized layers. What began as a sketch for a small utility grew into a focused product sprint with higher quality bars.
Choosing React Native for both platforms
Deployment planning raised the usual fork: separate native codebases in Swift and Kotlin, or a shared cross-platform approach. React Native won on logistics. A single TypeScript codebase that ships native UI binaries to Android and iOS cut cycle time and reduced duplicated product logic.
The project also became a production classroom for React Native. Work moved past structured video courses and generic sample repositories. Instead of styling static screens, the effort covered asynchronous state hydration, dynamic endpoints, and layout components that had to behave correctly across different pixel densities.
Growth architecture and post-launch governance
Moving a cross-platform app from a local emulator into official store review introduces a different class of friction. Clean component code turned out to be the easier stretch. Maturity arrived while resolving deployment bottlenecks.
First, the experience had to stay intuitive: menu bloat removed, layout minimal, spiritual reflections reachable through a single low-friction touch target. Second, telemetry and data flow needed careful tuning so state hydrated predictably without blocking the main thread on older hardware. Third, native platform configuration meant Android permissions, CocoaPods dependency trees, and local package settings adjusted to avoid runtime crashes during store governance.
Renaming Tawakkul to Feyz was more than cosmetic. As production telemetry accumulated and audience profiles stabilized, Feyz better matched a mature, inclusive, and broader product. The rename tracked improvements in code quality and scope as much as branding.
What shipping taught about engineering craft
Building and releasing the app challenged the idea that elite engineering equals the cleverest syntax. Shipping a real product requires setting ego aside and thinking like a product builder. Patience with broken environment setups, consistency through store rejection cycles, and humility when absorbing real user feedback matter more than showcase algorithms. Finishing an application and keeping it healthy in production demands discipline that starting a fresh repository never teaches. Feyz is no longer only a GitHub folder; it is evidence that a focused idea can cross the production finish line.
Try the live builds
Engineers, designers, and product-minded readers who want to audit the production interface, test cross-platform rendering, or explore the reflection architecture can install the live binaries from the public Apple App Store and Google Play listings for Feyz.
The path from abstract concept to store listing is still the same for any similar side project: pick a stack that keeps platforms aligned, design for calm focus instead of feature noise, and treat store governance and post-launch telemetry as first-class engineering work rather than afterthoughts. React Native made the dual-platform release tractable; production constraints made the craft real. Hydration that never blocks older devices, permissions that survive review, and CocoaPods trees that stay coherent are not glamorous, yet they decide whether users ever see the reflection experience at all.
A distraction-free spiritual app also forces ruthless product cuts. Every extra menu item competes with the moment someone opens the client for a short practice. Absolute typographical clarity, predictable state updates, and background synchronization that stays out of the way are not polish layers—they are the product. That is why Feyz prioritized a single frictionless entry into daily reflections over a dense dashboard of secondary tools.
For teams evaluating React Native for a similarly opinionated niche app, the lesson is practical. Shared TypeScript can carry UI and business logic across stores, but native seams still appear: Android permission surfaces, iOS dependency graphs, and hardware variance. Budget time for those seams early. Treat emulator green builds as a midpoint, not a finish line. Store pipelines, rejection notes, and older-device performance checks are where a side project becomes a maintained binary.
Independently owned apps also teach ownership of the full loop—idea, UX, TypeScript modules, native configuration, submission, and runtime health. That loop is what turns an abstract milestone into something users can download today.