SERVICE

Mobile app development

iOS and Android apps that survive review, bad networks and the next OS release.

What this actually is

A mobile app ships into an environment you do not control: a review process with its own opinions, a fragmented device population, networks that vanish in lifts and basements, and an operating system that changes every year whether or not you are ready.

The first real decision is cross-platform versus native, and it should be made on what the app does rather than on preference. A content, commerce or forms application rarely justifies two native codebases. Something leaning on camera pipelines, background execution or sustained graphics performance frequently does.

What we do

  1. Platform decision

    Cross-platform or native, argued from your requirements, with the trade-off written down rather than assumed.

  2. Offline-first data

    Local persistence, sync and conflict resolution — the part that decides whether the app is trusted in the field.

  3. Platform integration

    Push, deep links, biometrics, in-app purchase, permissions and the native modules that cross-platform frameworks do not cover.

  4. Release engineering

    Signing, provisioning, staged rollout, crash reporting and the review rejections, which are routine rather than exceptional.

The stack

React NativeFlutterSwiftKotlinTypeScriptFirebaseFastlaneSentry

What it connects to

Integration surface is the honest driver of effort — ten systems is not ten times one system.

How a project runs

Scoping

1 week

Platform decision, offline requirements and the store constraints that will apply.

Foundation

2 weeks

Navigation, auth, data layer and a build running on real devices.

Build

6–14 weeks

Features on TestFlight and internal testing tracks as they land.

Submission

1–3 weeks

Store listings, review, and the resubmissions review usually requires.

Post-launch

ongoing

Crash monitoring, OS-version updates and staged releases.

Where teams use it

Consumer apps

Accounts, payments and notifications, with offline behaviour that never loses the user's work.

Field operations

Apps for people working where connectivity is unreliable and sync correctness matters more than animation.

Healthcare

Patient and clinician apps where data handling and audit are constraints before features are.

Logistics

Driver and warehouse apps with scanning, routing and proof of delivery.

Companion apps

A mobile surface onto an existing platform, sharing its API rather than forking its logic.

When this is the wrong answer

If your users would be equally served by a responsive web application, that is cheaper to build, cheaper to change and has no review process. A surprising number of app projects should be web projects.

Two native codebases cost close to twice as much to build and considerably more than twice as much to maintain. That is worth paying only where the platform APIs genuinely require it.

App Store review is a dependency you cannot schedule around. Plan for rejection cycles rather than treating them as a failure.

An app nobody opens is worse than no app. Distribution and retention are product problems, and building the thing is the smaller half.

Frequently asked questions

React Native, Flutter or native?

Cross-platform for most content, commerce and forms applications — one codebase, both stores. Native where you depend on platform SDKs, background execution or sustained graphics. We recommend on requirements and explain the trade-off rather than defaulting to what we prefer.

Do you handle App Store and Play Store submission?

Yes, including signing, provisioning, listings, staged rollout and the review rejections. Treat those as part of the schedule rather than a surprise.

Can you add a mobile app to our existing platform?

Usually the cleanest version of this work — the app consumes the API you already have, rather than duplicating business logic that will then drift.

Who owns the code?

You do, from the first commit — work happens in your repository under your licence, and the contract assigns IP outright. We keep no rights and build no dependency that makes leaving expensive.

What does it cost?

We do not publish a number, because the honest one depends on scope, integrations and the accuracy bar. Tell us the budget you are working with and we will say what it buys — or say plainly if it does not buy enough.

How long does an app take?

A focused app reaches the stores in three to four months including review; something depending on hardware, offline sync or heavy integration runs longer. Store review is a dependency you cannot schedule around.

Do we need both iOS and Android?

Usually, eventually. Launching on one first is a reasonable way to learn cheaply, and cross-platform makes the second one nearly free — which is the main argument for it.

What happens when the OS updates?

Annual OS releases break things. Ongoing maintenance is a real line item rather than an optional extra, and an app left unmaintained for two years is normally a rebuild.

Can you take over an existing app?

Yes. The first task is usually getting a reliable build and release pipeline running, because inherited mobile projects are more often broken there than in the code.

How do we start?

A scoping call, then a short written proposal with scope, sequence and the assumptions it rests on. If we think you should not do this, or should do a smaller version first, that is what the proposal says.

Can our team take it over afterwards?

That is the intended end state. Standard technology, decisions documented as they are made, and handover sessions with your engineers. If a system can only be maintained by us, we built it wrong.

Related

Before you choose anyone

Written to be useful whether or not you hire us — including the parts that argue against hiring an agency at all.

Mobile App Development — tell us the scope

Tell us what you are building. We reply within one business day.