Mobile app development
Mobile work usually reaches us from one of two places. Either there is no app yet, and the backend was never designed for a client that goes offline, retries, and runs an old version for months. Or there is an app, it crashes on phones nobody tested, and a release takes a week because only one person understands the signing setup. We build React Native apps for both stores, and write the native piece by hand when no library does the job.
Four ways this arrives.
And crashes on the ones your users own. We add crash reporting with readable stack traces, find the handful of devices and OS versions causing most of the crashes, and fix those before anyone touches a feature.
Signing keys on a laptop, a manual build, store notes written at midnight. We move builds and signing into CI, add over-the-air updates for JavaScript-only fixes, and write down exactly how a release goes out.
A Bluetooth device, a vendor SDK, a camera pipeline, a background task the OS keeps killing. We write the native module in Swift and Kotlin, expose a small typed interface to React Native, and keep it isolated so upgrades stay possible.
Forms that vanish, actions that send twice. We decide what must work offline, keep it on the device, queue writes with idempotency keys the backend understands, and show the user plainly what is still waiting to sync.
Our own React Native app on Android, with retraction built into the client because moderation can pull a message after it has been sent.
Read the write-up →Asked on nearly every call.
React Native or fully native?+
React Native for most products: one codebase, one team, both stores. Fully native makes sense when the app is mostly the hard native part, such as heavy camera or audio processing, complex background work, or a platform feature React Native does not support yet. We will tell you which side of that line you are on, and write the native parts by hand either way.
Expo or bare React Native?+
Expo, in almost every case now. Development builds and config plugins removed most of the old reasons to eject, and EAS handles builds and signing. We go bare only when a native dependency genuinely cannot live inside a config plugin, and we will explain why before doing it, because it makes every future upgrade more work.
Can you take over an app someone else built?+
Yes. We start by getting it to build on a clean machine, which is often the hardest step, then bring React Native and its dependencies up to a supported version before adding features. We tell you what state the app is in, including where the store listings, signing keys and accounts actually live, before quoting anything larger.
Who handles App Store and Play Store submission?+
We do, from your developer accounts, not ours. We prepare the builds, the privacy disclosures and the notes for the reviewer, and deal with rejections when they come. The accounts, signing keys and listings stay in your name, so you can change developers later without asking anyone's permission.
Does our backend need to change for a mobile app?+
Often, a little. A mobile client stays on old versions for months, retries on bad networks, and cannot be fixed by a server deploy. That means versioned endpoints, idempotent writes, and a way to tell an old client it must update. We check the backend for those before the first screen is built, because retrofitting them after launch is slower.