iOS & Android

Mobile App Development Without Paying for Two Builds

Cross-platform mobile app development in React Native and Flutter: one codebase, both stores, native performance where it matters. You get an iOS and an Android app from a single project rather than two teams building the same product twice.

The expensive part of an app is not the first version

Two native codebases means every feature is specified once, built twice, tested twice and fixed twice. Every bug report arrives with a question attached: is this on both platforms or just one? That overhead does not end at launch — it is the permanent cost of the decision.

Then there are the parts nobody budgets for. Store review, which rejects first submissions for reasons that are rarely about your code. Push notifications, which need certificates on one platform and a different service on the other. Forced-update handling, because users on a six-month-old build will still be hitting your API. Crash reporting, or you find out about failures from one-star reviews.

We use one codebase for both platforms and treat store submission, notifications and release handling as part of the build rather than as an afterthought at the end.

What we build

Cross-platform apps

React Native or Flutter, sharing effectively all product code between iOS and Android. Platform-specific code where the platforms genuinely differ — navigation feel, permissions, share sheets — rather than one lowest-common-denominator interface.

Companion apps for existing products

A mobile front end on the API you already run. Often the fastest route to an app, because the hard work — data model, business logic, authentication — already exists and is already tested.

Offline-capable apps

Local storage and a sync layer for apps used on job sites, in warehouses or in transit, so a dropped connection queues work instead of losing it.

Payments and subscriptions

In-app purchases and subscriptions through the App Store and Play Billing, or card payments where the stores permit it. Including receipt validation and restore-purchases, which reviewers check.

Push notifications

Firebase Cloud Messaging and APNs set up properly: certificates, deep links into the right screen, permission prompts asked at a moment the user understands, and segmentation so you are not messaging everyone.

Store submission and release

App Store Connect and Play Console setup, listings, privacy declarations, screenshots, TestFlight and internal testing builds, and the first submission handled by us — including replying to review if they push back.

How we work

  1. Scope

    We work out which screens the app genuinely needs and which are a website in a shell. If your idea does not need the camera, location, offline access or notifications, we will say so before you spend money.

  2. Fixed quote

    A written scope and a fixed price before development starts, with store setup and submission included rather than added at the end.

  3. Build with test builds

    TestFlight and Play internal testing builds from early on, so you and your team are using the app on your own phones weeks before launch.

  4. Submit and hand over

    We submit to both stores, deal with review, and hand over the repository, signing keys and store accounts in your name.

What we build on

Cross-platform is the default because it is cheaper to build and much cheaper to maintain, not because it is always right. Apps built around heavy real-time graphics or deep platform integration are better native, and we will tell you when that is the case. If a progressive web app would do the job, that is usually cheaper still.

Cross-platform
React Native, Expo, Flutter
Native
Swift and Kotlin modules where a platform API requires them
Back end
Node.js, Laravel, Firebase
Services
Firebase Cloud Messaging, APNs, Stripe, App Store and Play Billing
Quality
Crash reporting, analytics, TestFlight and Play internal testing tracks

What an app costs to build

The question that moves the number most is whether the app has a back end already. A companion app over an API you own — sign-in, a handful of screens, push notifications — is a contained build. An app that needs its own accounts, data model and server behind it is a larger one, because you are commissioning two things rather than one.

After that it is the features that do not show up in a screen count. Offline sync, in-app subscriptions and anything real-time cost what they cost because of edge cases and testing: what happens when the device has been offline for a week, when a receipt fails to validate, when two people edit the same record. Screens are the cheap part.

Store submission and first-release support are included in the quote rather than added at the end. Apple and Google charge their own developer fees directly to you — those are theirs, not ours, and we do not mark them up.

Tell us what the app needs to do and whether there is an API behind it already, and you will get a written scope and one fixed price covering both platforms.

Why work with us

  • One codebase, and we say when that is wrong

    Cross-platform covers most business apps at close to native performance. When your requirements genuinely need native, we tell you before quoting rather than shipping something that disappoints on one platform.

  • Store submission is our problem, not yours

    First submissions get rejected, usually over privacy declarations, account deletion or metadata rather than code. We handle the process and the back-and-forth as part of the project.

  • Accounts and keys stay in your name

    Your Apple Developer and Google Play accounts, your signing keys, your repository. Apps stranded in an agency's store account are a genuinely painful thing to recover.

  • One price, both platforms

    We quote a written scope covering iOS and Android together, with store submission in it — not a per-platform figure that doubles at the end.

Frequently asked questions

Will a cross-platform app feel as good as a native one?
For the overwhelming majority of business apps, yes — React Native and Flutter render native components and run at native frame rates for normal interface work. The gap shows up in heavy real-time graphics, intensive on-device processing and brand-new platform APIs. If your app lives in that territory we will recommend native and explain why, rather than take the easier sale.
How long does a mobile app take to build?
A companion app over an existing API is typically six to ten weeks including store submission. An app needing its own back end runs three to five months. Store review itself is usually one to three days per submission, but budget for at least one rejection on a first release.
What happens if Apple or Google rejects the app?
It is common on a first submission and it is our job to resolve, not yours. Rejections are usually about privacy labels, account deletion, subscription presentation or metadata rather than the code. We fix and resubmit as part of the project; there is no extra charge for handling review.
Do we need a separate back end?
Not if you already have one. If your web application or SaaS platform has an API, the app talks to it and you avoid duplicating business logic. If there is nothing to build on, we scope a back end alongside the app and it is a material part of the cost.
Who owns the store accounts and the app?
You do. Apple Developer and Google Play accounts are created in your company's name with you as owner, and signing keys are handed over. We take temporary access to publish and give it back. Nothing about the app depends on our accounts continuing to exist.
What does maintenance actually involve?
Apple and Google both require apps to target recent OS versions to stay updatable, so an app left untouched for two years usually needs work before it can ship an update at all. Maintenance plans cover OS compatibility, dependency updates, crash monitoring and small changes, priced monthly against the app once it ships. Optional, but not doing anything for years is what makes the next change expensive.
Could this just be a website instead?
Sometimes, and it is worth asking. If the app does not need the camera, background location, offline access or push notifications, a progressive web app can deliver most of the value with no store review and no install friction. We would rather build you the cheaper thing that works than an app nobody installs.

Tell us what the app has to do

Describe the app and who uses it. We will tell you whether it should be cross-platform, native or a web app, how long it takes, and what it costs. No charge for that conversation.