Mobile App Development

Apps that still work in a basement

Most of the apps we build are for people who are not sitting at a desk — drivers, field engineers, warehouse staff, customers on a train. So we start from the question everyone else leaves until testing: what happens when the signal drops? What can you still read, what can you still do, and who wins when two people changed the same thing while offline. We answer that first, then build one React Native codebase for iOS and Android.

One product, two surfaces

Most apps we build are the mobile surface of an existing system. Sharing the API, the auth model and the design tokens keeps the two in step and cuts the cost of every future feature roughly in half.

Offline behaviour

Field teams lose signal. We decide up front what is readable offline, what is writable offline, and how conflicts resolve — then build the sync layer around that decision rather than discovering it in testing.

Cross-platform, honestly

One React Native codebase covers iOS and Android for the great majority of product work, and we say so plainly when it does not — heavy background processing, deep OS integration or sustained real-time graphics are the cases where a native module, or a native app, is the right call. That decision is made in discovery with the cost written down, not discovered at submission.

Continuous with the web product

Design tokens, component behaviour and the API contract are shared with your web or 3D surface, so a user moving between them is not learning a second product. Where the web experience is spatial, the app reuses the same models and materials at a mobile-appropriate level of detail rather than shipping a separate art pipeline.

Release discipline

Staged rollouts, over-the-air updates for JavaScript-level fixes, and crash reporting wired to the same alerting as the backend.

Native or cross-platform?

Cross-platform (React Native) for almost all business apps — one codebase, two stores, half the cost of every future feature. Native when the app is the hardware: heavy graphics, background processing, deep OS integration. We tell you which at the brief, with the cost written down.

Do you handle the App Store and Play Store submissions?

Yes, including the rejections. Store review is part of the schedule, not a surprise at the end.

Can the app use 3D?

Yes, where it earns its place — a product viewer, a site plan you can rotate. It reuses the models from your 3D website at a mobile-appropriate detail level, so there isn't a second art pipeline to pay for.