Mobile Apps

Mobile apps for iOS and Android, built from a single codebase

We build cross-platform apps in React Native and Flutter — one team, one codebase, both stores — and we are candid about the cases where native is the better call.

The app that shipped and then stopped

Mobile projects fail after launch more often than during it. The build completes, the app reaches both stores, and then the operating systems move. Apple and Google each ship a major release every year, deprecate APIs on a schedule, and periodically change what the review process will accept. An app nobody maintains becomes an app that will not compile within about eighteen months, and a rejected update at that point is a rebuild rather than a fix.

The second recurring problem is treating the network as reliable. Phones lose signal in lifts, on trains and inside the buildings where field staff actually work. An app that assumes connectivity produces spinners, lost form entries and support calls. Offline behaviour is a design decision taken early, not a feature added later.

Both are budget questions as much as technical ones. We would rather set the expectation before the project starts than deliver something that quietly expires.

What the engagement covers

One codebase, both platforms

React Native or Flutter, depending on what the app needs and what your team can maintain. Platform-specific code where the difference genuinely matters, shared code everywhere else — which is most places.

Offline and poor-connectivity behaviour

Local persistence, queued writes and conflict handling designed against your actual usage, not assumed away. If your users work in warehouses, basements or moving vehicles, this is the difference between an app they use and one they abandon.

Store submission, handled

App Store and Play Console setup, signing, privacy declarations, store listings and the review cycle. First submissions are rejected often enough that experience here saves real calendar time.

Push notifications with a purpose

Segmented, permissioned, and tied to events people actually want to hear about. Notification permission is granted once and revoked permanently, so the first prompt should be earned rather than fired on launch.

A backend that fits a mobile client

Mobile clients need different API shapes than browsers — fewer round trips, smaller payloads, and versioning, because you cannot force everyone to update at once. We build the API with that in mind or adapt an existing one.

Release pipeline and crash visibility

Automated builds, staged rollout and crash reporting configured from day one, so a bad release is caught from the dashboard rather than from a review.

Technologies we use for this

Cross-platform

React Native
Flutter
TypeScript

Backend

Node.js
Express
Laravel
REST
GraphQL

Data

MongoDB
MySQL
Local persistence

Delivery

App Store Connect
Google Play Console
GitHub Actions
Docker

We choose from these based on what the project needs and what your team can maintain after we hand over — not on what we most enjoy working with. Where an existing stack is already in place and sound, we work within it.

Where a mobile app is the right answer

Field and frontline teams

Engineers, drivers and inspectors capturing work away from a desk. The requirements are usually offline capture, camera, location and a sync model that survives a lost signal mid-form.

Customer apps for repeat use

Booking, ordering and account management where the interaction is frequent enough to justify an install. When it is not frequent, we will usually recommend a well-built responsive site instead and save you the budget.

Companion apps to an existing platform

A mobile surface over a system you already run. The work is frequently more about API design and authentication than about the interface itself.

Internal apps distributed privately

Staff tools delivered through managed distribution rather than the public stores, which removes the review cycle from your release path entirely.

Questions we are asked about this

Should we build cross-platform or native?

Cross-platform suits the large majority of business apps and costs meaningfully less to build and maintain, because one team maintains one codebase. Native becomes the better choice when the app depends heavily on platform-specific hardware, needs sustained high-frame-rate graphics, or is itself the product and must feel exactly like the platform. We will give you a straight recommendation for your case rather than a default.

Do we need an app at all?

Often not. If people would use it a few times a year, the install is a barrier and a responsive website will serve them better for a fraction of the cost. Apps justify themselves through frequency of use, genuine device capabilities — camera, location, offline, background sync — or the need for a presence on a phone's home screen.

How long does an app take?

A focused first release is typically 8–14 weeks including store submission. Apps with substantial offline behaviour, payments or complex integrations run longer. Store review adds days rather than weeks once the account setup is correct, though a first submission can take longer.

What does maintenance involve?

Realistically, two to four releases a year: OS updates, dependency and SDK upgrades, and periodic changes to store requirements. This is ongoing rather than optional — an unmaintained app eventually stops building. We would rather you budgeted for it from the start.

Can you publish under our developer accounts?

Yes, and we recommend it. Your company should own the App Store and Play Console accounts and the signing credentials. We will set them up with you if you do not have them yet.

Thinking about mobile apps?

Send us the problem and any constraints you already know about. We will come back with what we think it needs, an approach, and a realistic range — or tell you it is not work we are right for.

Start a conversation