React Native app development

The honest case for cross-platform

You write the app once and it runs on iPhone and Android. That’s real, and for most products it’s the right decision, the savings aren’t really in the first build, they are in every change afterwards. One fix, one review cycle, one set of tests, rather than the same work done twice by two people who have to keep agreeing with each other.

What it doesn’t save you is the platform work. Two store listings, two review processes, two sets of signing credentials, two notification systems, two privacy declarations. That’s roughly a third of the effort on a real app, and it doesn’t shrink because the UI layer is shared. Anyone quoting you a cross-platform app as "half the price of two apps" is quoting the part they can see.

What actually consumes the time

Getting into the stores

The build isn’t the milestone; approval is. Apple's review is genuinely strict and the rejections that hurt are rarely technical, account deletion, data disclosure, permission strings that don’t explain themselves, sign-in requirements. Most of these are decided by design choices made in week one, which is why I’d rather settle them before writing the screens than discover them in a rejection three days before launch.

Authentication and accounts

Mobile auth is meaningfully harder than web auth: tokens on a device you don’t control, sessions that must survive being backgrounded for a week, biometric unlock, and a sign-out that genuinely clears state. It’s also where the platform-specific traps live. This is usually the first thing I build, because everything else assumes it works.

Shipping updates without a review cycle

The ability to push a fix straight to installed devices, without waiting days for review, changes how a small team can operate. It’s one of Expo's genuine advantages and it has limits worth knowing up front: it covers your JavaScript, not native modules, so a change to the native layer is still a full store submission. Knowing which side of that line a change falls on is part of planning the roadmap.

Offline and unreliable connections

Phones lose signal. If your app assumes a connection, it’ll fail in exactly the place your customer needs it, a basement, a job site, a lift. Deciding early what works offline, what queues, and what honestly can’t is a product decision, and retrofitting it later means touching every screen.

Two apps I’ve shipped

Both are live, both are React Native on Expo, and they’re deliberately different problems.

How I’d run your build

• Store requirements first. Account deletion, privacy disclosures and permission copy get settled before the screens, because they’re design constraints rather than paperwork.
• Auth before features. Everything downstream assumes it, and it is the most expensive thing to change once real users have accounts.
• On a real device early. Simulators hide performance, keyboard behavior, safe areas and notch handling. An app that has only ever run on a simulator isn’t a tested app.
• Instrumented from day one. You can’t debug a phone you don’t own. Without crash and error reporting from the first build, your bug reports are "it didn't work" and you’re guessing.

What to expect on timing

A focused app with authentication, a handful of core screens and a real backend is typically a matter of months rather than weeks, and the store submission itself wants a week or two of that, more the first time, because the first submission for a new account always surfaces something. If you need a date, plan for the review, not just the build.

If you already have a web product and want a mobile version, that’s usually a shorter conversation than starting fresh: the backend exists, the decisions about who can do what are made, and the work is genuinely the app.