React Native app development for iOS and Android

React Native or native: how do we decide?

Most of our mobile work is written in Expo and React Native: FitZen, GlowTira, PeakUp, HuntLine IQ, RichlyMe, Muslim Mubarak, in5min and Karaman Mobile among them. Two iOS-only products are SwiftUI: PersonaDreams (145 Swift files) and AppsPaper. We decide on how much flow the two platforms share, how deep the device integration goes and what maintenance will look like, not on screen count.

Choosing React Native does not mean giving up native code. The platform-specific part goes in as a small native module:

• In Muslim Mubarak, modules/widget-bridge writes prayer data to shared storage, and the five SwiftUI widgets under targets/widget read it.
• In in5min, Live Activities and a home-screen widget were added as native modules, and the same Expo codebase serves iPhone, Mac and Vision Pro.
• In Amenza, the home-screen widget reads the app’s data through a native bridge.

When the product’s core value is a platform-specific interaction, we say so during discovery and put the native option on the table.

How do builds and store submissions run on Expo and EAS?

HuntLine IQ’s iOS and Android apps were submitted to TestFlight and Play through EAS from a single Expo SDK 57 codebase. Push goes through the Expo Push Service with no Firebase SDK in the app; a credentials-only Firebase project supplies the FCM key to EAS.

For Karaman Mobile, the client would build for the stores from their own Expo and Firebase accounts, so no secret lives in the source. Calls to the Karaman API go through karaman-proxy, and the production profile refuses to build with mock data.

The most instructive bug appeared in FitZen’s Android 2.0.2 release. A local EAS build left the $VARIABLE placeholders from eas.json unresolved, so the RevenueCat, Firebase and Google sign-in keys entered the bundle as literal placeholder text. The fix treats any value starting with $ as empty in app.config.js and defines defaults for client keys. One item on FitZen’s release checklist comes straight from that: verify from inside the bundle that environment variables actually resolved, for local and cloud builds alike. A separate item requires keys to live in the EAS environment, not only in .env.

How do we set up subscriptions with RevenueCat?

In FitZen, six store products were created under identical IDs in both stores, and the three subscriptions map to a single "premium" entitlement in RevenueCat. RevenueCat is the source of truth; Firebase only holds a mirror, and the server, not the client, writes it:

• a secret-gated webhook uses the event ID as the document ID, so redelivery is never double-counted;
• a callable invoked on sign-in and app foreground asks the RevenueCat REST API for the subscriber’s real state;
• a nightly job at 03:15 closes expired access.

Firestore rules reject client writes to 18 entitlement fields. The audits left two lessons: refunds do not arrive as their own event type but as CANCELLATION with a cancel_reason, and a one-time pack with no expiry date must never count as open-ended premium.

The same pattern runs elsewhere. RichlyMe sells membership only through Apple in-app purchase, managed with RevenueCat; GlowTira and HuntLine IQ use a RevenueCat webhook. The tool can change with the product: Parent Daily runs its subscriptions on Adapty.

Supabase or Firebase for the backend?

We have live products on both; the choice depends on the shape of the data and where the authorisation rule has to live.

On Firebase: FitZen, Wardrova, Muslim Mubarak, in5min, Garaj and Düzce Biz. In Garaj, every decision in a 1v1 quiz match is made in Cloud Functions; the client only calls and listens to the match document. The GPS-timed performance test, by security rule, can write only to the user’s own document.

On Supabase, relational data and row-level authorisation lead:

• RichlyMe: 49 migrations, 17 Edge Functions, 401 tests across 38 SQL test files.
• GlowTira: 29 Edge Functions; rate limits per subscription tier are atomic in a Postgres RPC, and no provider key ships in the bundle.
• PeakUp: 15 Edge Functions, 36 database and RLS tests.
• Karaman Mobile: delivery zones are validated on the server as PostGIS polygons.

Some projects connect to an existing backend instead of rebuilding it. In Karaman, a bridge Edge Function maps karaman.com accounts to Supabase profiles; HuntLine IQ’s mobile app uses the same Supabase project as the web platform.

How do you build a mobile app that shares rules with a web product?

A mobile app rarely lives alone; it usually sits next to a web panel or a web product. The most expensive mistake then is the two sides applying the same rule differently.

In HuntLine IQ the client’s web app already existed, and there were three weeks to get the iOS and Android apps ready for the Tennessee fair window. The scope sentence was clear: exact behavioural parity with the web, plus two features contracted for native. The typed API layer, constants, date formatting and EXIF-preserving photo preparation were ported from the web repo. TanStack Query keys mirror the web cache, and design tokens were frozen from the web CSS and moved to NativeWind. The server gained only two things: a push-token registry and a RevenueCat webhook.

In PeakUp, members, trainers and the studio owner share one Expo app, with a Next.js 16 panel for the owner. The shared @peakup/shared package carries zod schemas and the VAT, absence and package-deduction rules, and the same rules are enforced by CHECK constraints in the database. Düzce Biz keeps its Expo app, Next.js 16 panels and shared types in one monorepo as well.

What matters for store release and App Review?

In FitZen, the App Review risk sat less in the code than in how the paywall was presented. Our audit of build 91 (1.2.3) found two blockers: the paywall showed "3 days free" without an eligibility check, and prices plus struck-through discounts were hard-coded by UI language rather than storefront. In the new usePaywall hook, prices and trial info come straight from the RevenueCat offering, and if eligibility is unknown no trial is promised. Review notes and a premium demo account are prepared so the reviewer can get past the paywall.

A quality gate runs before release. In PeakUp, database and RLS tests, contract checks and unit tests sit under one pnpm dogrula command, and nothing ships unless it is green. The app went out on iOS and Android as the 2.0.0 update to the existing store listing.

App Store and Google Play developer accounts are opened in the client’s name. Karaman Mobile is a typical case: the client builds from their own Expo account, and the app was delivered in September 2026 with source, setup instructions and server release notes.

Frequently asked questions

RELATED STUDIO NOTES