Mobile Applications

The hard part of a mobile app is the network being absent

Android and iOS from one codebase where that genuinely serves the product, native where it does not — with offline behaviour and sync conflicts specified before any screens.

Why this comes up

Mobile briefs tend to arrive as a list of screens. Screens are the visible part and the cheap part. What determines whether the app is usable is what happens when the connection drops mid-action — in a basement, on a train, in a school corridor with two bars — and that question is almost never in the brief.

If it goes unanswered, the app answers it by accident: a spinner that never resolves, a form that loses its contents, two devices that each believe they hold the correct version of the same record. By the time this surfaces it is not a bug but an architecture, because offline behaviour is a property of how data is stored and synchronised, not something added at the edges.

We specify it first. What is readable offline, what is writable offline, what happens when two people edited the same thing, and who wins. Then the release machinery — store review, staged rollout, crash triage, forced upgrades for a breaking API change — because unlike the web, you cannot fix a mobile release by redeploying.

What you get

Deliverables, not adjectives

A written offline and sync specification

Per data type: cached, queued, or online-only. Conflict resolution stated explicitly — last write wins, merge, or ask the user — and agreed before implementation, because these are product decisions wearing technical clothing.

A platform choice with reasoning attached

React Native or Flutter where one codebase genuinely serves both platforms, native where the product depends on platform capability or sustained graphics performance. Including the honest case for a mobile web app, which sometimes wins.

Notifications, deep links and background behaviour

Push delivery that survives both platforms' background restrictions, deep links that open the right screen from a cold start, and background refresh that respects battery. This is where most cross-platform projects lose time, so we scope it as real work rather than a finishing touch.

A release process, not just a build

Signing, store metadata, review submission, staged rollout, crash and ANR triage, and a forced-upgrade path for the day the API changes incompatibly. Handed over as something your team can run without us.

Scope at a glance

React Native and Flutter, with native modules where needed
Offline-first storage and conflict resolution on sync
Push delivery, deep linking and background refresh
Store submission, staged rollout and crash triage

What we reach for

Defaults rather than rules. Each one gets argued against on a project where it does not fit — the reasoning matters more than the tool.

Cross-platform: React Native or Flutter, with native modules written where the bridge is the bottleneck.
Native: Swift and Kotlin where the product genuinely requires platform-specific capability.
Local data: SQLite or a local-first store, with sync treated as a first-class subsystem.
Operations: Crash reporting and staged rollout wired up before the first public release, not after.

How it runs

Durations are ranges because a single confident number this early is a guess in a suit.

Engagement shape

Fixed scope to a first store release, then a retainer for the release cadence after it.

Typical duration

Ten to eighteen weeks to both stores, review time included.

Starts with

A data-flow session that produces the offline specification, before a single screen is designed.

When this is the wrong thing to buy

We would rather lose the enquiry here than three months in. If you recognise your situation below, say so on the first call and we will tell you what we would do instead.

An app that is a wrapper around a website with no offline use, no notifications and no device capability. A good mobile web experience would cost less and reach more people.
Shipping to both stores in six weeks with a complex sync model. We would rather cut the scope than agree to a date we can only meet by skipping the part that matters.
Games and sustained real-time graphics. That is a different discipline and we would point you elsewhere.

Questions we get asked

React Native or Flutter?

Either is a sound choice, and the deciding factor is usually your team rather than the framework. If you have React developers, React Native keeps the codebase legible to people already there. Flutter gives more consistent rendering across platforms and a stronger story for custom UI. We will recommend one and explain the trade-off rather than pretend the answer is universal.

Do we need separate native apps?

Sometimes. If the product depends on platform-specific capability, tight hardware integration or sustained graphics performance, native is the honest answer. For most business applications — forms, lists, sync, notifications — one cross-platform codebase serves both stores well and halves the maintenance.

Who handles store submission?

We do, including the metadata, privacy declarations and the first review round, which is where rejections usually happen. Then we hand over a documented process so your team can release without us, because a release process only you can operate is a dependency we do not want to sell.

What happens when a user is offline for a day?

Whatever we specified together — which is the point of specifying it. Typically: cached data stays readable, actions queue locally with clear pending state, and on reconnect the queue drains with conflicts resolved by the rule agreed up front. The failure we design against is the app appearing to accept work it silently loses.

Talk to us about mobile applications

Send the problem rather than a feature list. You will get an approach, a range and an honest view of what it takes — including whether you need this at all.

Book a 15-min strategy call