Services
We build mobile applications for field engineers, clinicians, drivers and store staff who work with patchy connectivity, company-issued devices and no patience for a login screen that stalls on a warehouse Wi-Fi signal. The decision between native and cross-platform, and between public store and managed distribution, is made against your device fleet and your feature list, not a default.
The measure of this work is not that the app looks good on a demo phone. It is that a technician forty feet underground with no signal can still complete a job, and the record is correct once they are back in range.
When you need this
What we build
Our approach
We list every feature that touches a platform API — camera, background location, Bluetooth, biometrics, push — and score how much of it is genuinely shared behaviour versus platform-specific. That score, not a default preference, determines whether we build Swift and Kotlin or React Native/Flutter with native modules. The recommendation and its reasoning are written down before estimation.
For every entity the app can create or edit offline, we agree what happens when two versions of it collide: which field wins, which need a human decision, and how the user is told a conflict occurred. This is decided at the whiteboard, not discovered in a support ticket six months after launch.
Public App Store and Play Store distribution suits consumer-facing apps; workforce apps usually do not need or want a public listing. We set up Apple Business Manager, Android Enterprise and MDM enrolment (Intune or Jamf) early, because retrofitting managed distribution after a public release means re-signing, re-provisioning and often a support gap for existing users.
Certificate pinning, Keychain/Keystore storage, biometric gating and jailbreak/root detection are built alongside the first feature, not bolted on before a client's security audit. Retrofitting pinning after launch usually means a forced update for every existing user, which is disruptive and avoidable.
We hand over a release pipeline your IT team can run without us: staged rollouts by device cohort, crash monitoring with alert thresholds, and a documented process for pushing an emergency update through MDM without waiting on a public app store review cycle.
Technology
Native
Cross-platform
Offline and sync
Distribution and security
Applied by industry
Offline clinical capture for community and domiciliary care, syncing to EMIS Web or SystmOne once back in signal, with biometric gating and MDM distribution so devices meet NHS DSPT device standards.
Field engineer apps for meter installation and fault callouts, working underground and in basements with no signal, syncing job status and photographic evidence once reconnected.
Manager and staff apps for stock counts and shift handovers across sites with unreliable venue Wi-Fi, syncing to the EPOS and stock platform once a connection is available.
Inspection and viewing apps for agents working in properties with no signal, capturing condition reports and photos offline and syncing to the lettings CRM on return to coverage.
Secure document review and time capture apps for fee-earners working from client sites, with certificate pinning and remote wipe to satisfy client information security questionnaires.
Typical engagement
Questions
It depends on what the app does, not on which is fashionable. Camera-heavy, AR, or performance-critical apps (fleet telematics, clinical devices, POS hardware) usually justify native Swift and Kotlin. Line-of-business apps with mostly forms, lists and API calls across iOS and Android are cheaper to build and maintain in React Native or Flutter, with native modules dropped in only where a platform API demands it. We make the call against your actual feature list, not a general preference, and state the trade-off in writing before build starts.
Every offline-capable entity has an explicit conflict resolution rule agreed before code is written: last-write-wins with a vector clock, field-level merge, or a human review queue for cases that cannot be resolved automatically. Local writes go to an on-device store (SQLite via Room or Core Data, or a sync engine such as WatermelonDB) with a queue that replays against the server API on reconnect, and every queued mutation carries an idempotency key so a retried request cannot double-apply.
Yes. For workforce apps not intended for the public, we distribute via Microsoft Intune or Jamf Pro as managed apps, using Apple Business Manager or Android Enterprise enrolment so the app is pushed to enrolled devices without a public listing. This also lets IT enforce app-level policies — wipe on unenrolment, block on jailbreak or root detection, restrict copy-paste out of the app — that public store distribution cannot.
Biometric unlock (Face ID, Touch ID, Android BiometricPrompt) gates access to the app, not just the phone. Tokens and credentials sit in the iOS Keychain or Android Keystore, not in shared preferences or plain files, and are hardware-backed where the device supports it. API calls use certificate pinning so a compromised or MITM'd network cannot intercept traffic even with a rogue root certificate installed, and a remote wipe of app data is available through the MDM console independent of the OS-level device wipe.
Usually, via React Native or Flutter, with platform-specific modules where genuinely needed — background location on Android behaves differently enough from iOS that a shared abstraction is often the wrong instinct. Where the two platforms have materially different requirements (an iOS-only clinical build for a hospital that is Apple-only, for example), we say so rather than forcing parity that adds cost without adding value.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us