One codebase for iOS and Android, in React Native or Flutter

When a shared interface fits

React Native uses JavaScript or TypeScript with native components; Flutter uses Dart and its widget system. We start from a workflow someone can complete on the target devices, including empty and failed states.

A shared interface can suit lists, forms, bookings and account workflows used on both phones. Native code may still be needed for device integrations, widgets or extensions. An offline SQLite dataset alone does not determine the framework: data size, query behaviour, synchronisation and device testing matter. We compare the difficult requirements before choosing native or shared-code implementation.

Typical jobs

A new app scope includes its main screens, validation, network failures and permissions. Push notifications, tablet layouts and backend work are listed explicitly when they belong in the release.

Existing-project repairs can cover release-only crashes, broken deep links, incompatible dependencies or native integrations that behave differently on each platform. We reproduce the fault before deciding whether to repair a module or change the wider architecture.

Sharing screens does not remove native integration, release or maintenance work. We confirm purchase rules for the product and storefront, then test the agreed provider’s successful, failed and recovery paths. Reading cached data and synchronising offline edits are separate requirements.

From the first email to handoff

Send the job, who uses it, both stores or one first, and a date tied to an event. Named screens are a fixed-price project. A bug we can reproduce is hourly. No screens yet, or React Native, Flutter, and native still open, means paid discovery. You keep the write-up if you stop.

Your business controls the repository and store accounts. We agree access, ownership and handoff terms, then provide test builds for the target platforms before submission. Release instructions and required settings are documented. Store approval remains a separate step.

Expo, React Native, and Flutter

React Native work can use Expo or an existing native project. The scope identifies the build workflow and any native integrations. We use a development or release build suitable for testing those integrations, rather than assuming a preview environment covers every feature.

An appropriately configured React Native update service can deliver compatible JavaScript and asset changes without a new store binary, subject to store policies. Native-code, permission and SDK changes need a compatible new build. Flutter work uses Dart and supported platform integrations. Where a package cannot cover a required device API, the scope identifies the native module and its tests.

Both stacks call your API. Building a backend, or the same account in a browser, is a separate quote. A new app gets one way to hold state and one way to navigate, written down. An existing app keeps what it has, unless that is the bug. Accessibility, when you ask, means we implement the technical side of WCAG: names on controls, type that scales, and a screen-reader path. We do not certify compliance.

Who it suits

Write if you can describe the screens and you want a React Native developer or a Flutter developer to build them, extend them, or continue a repository that stalled. An agency can send that slice under its name or with a credit. Your own developer can keep the API or a native module while we take the shared screens.

If the brief is still open, paid discovery can turn it into a defined feature list and acceptance checks. If you already have a developer or agency, we can take a bounded part of the work and agree how it joins the wider project. Share the target date so we can assess capacity and dependencies before committing.

What we have shipped, and what to send

Our nine published App Store products use native Swift and SwiftUI. Tifo includes Apple TV, Moonflower includes a Safari extension, and ICD Atlas uses offline reference data. They demonstrate native integration and release work. A React Native or Flutter project should be judged through its own prototype, repository and builds on both target platforms.

Send the version-one job, the audience, both phones or which is first, and who will maintain the app. Designs, an API note, or a repository help if you have them. Say whether a purchase is used inside the app. We can agree who owns the Apple and Google accounts before a password is shared.