I Will build a cross-platform mobile app with React Native for iOS and Android

What this covers

One React Native codebase, two stores, one set of bugs to fix. Navigation, authentication, push notifications, offline handling, and the platform differences that a cross-platform framework does not make disappear on its own.

How I approach it

The app is built against your real API from day one, not mocked data that behaves better than production ever will. Authentication uses secure storage on the device and refresh tokens handled in one place, because token bugs scattered across screens are the most common way mobile apps rot. Lists are virtualised and paginated; images are cached and sized for the device rather than downloaded at full resolution.

Platform work is treated as work, not as a footnote: iOS needs its own permission strings and provisioning, Android needs its notification channels and back-button behaviour, and both need deep links that survive a cold start.

Deliverables

• React Native project in TypeScript, with the native modules you need and no others.
• TestFlight and Play internal-track builds so you can hold it in your hand early.
• Push notifications wired end to end, including the backend trigger.
• Release builds, store listing text and screenshots, and the notes needed to submit.
• A short guide to running, building and releasing it yourself.

What I need

An API or a specification for one, the three screens that matter most, and Apple and Google developer accounts if you already have them. If you do not, I will tell you exactly what to create and when.

Scope note

One app, one audience. If the product needs two very different experiences — for example a customer app and a driver app — those are two builds and I will say so before quoting rather than after.

Turnaround and communication

First TestFlight or internal-track build usually inside two weeks, so you are holding the app and giving feedback on the thing itself rather than on screenshots. I keep the release checklist explicit — permissions, deep links, offline behaviour, store metadata — because those are the items that turn a working app into a rejected submission. Every build you receive is a build you could ship.