01
Offline-first capture
The application assumes no network. Work is captured, stored and queued on the device, and the user is never held up waiting for a connection.
Capability / Mobile
Mobile applications that work where the connection does not.
Field applications built offline-first, delivered from one codebase across iOS and Android, and reconciled against the back-office system that holds the record.
Coverage
What the discipline covers.
A field application is judged on the day the network is not there. Everything below exists to make that day uneventful.
02
Synchronisation
A sync engine with ordering, retries and conflict rules that are written down rather than implied, so the device and the back office end up agreeing.
03
Cross-platform delivery
One codebase across iOS and Android, with native modules only where the platform genuinely requires them.
04
Back-office integration
Records reconciled against the system that owns them, whether that is Salesforce, an ERP or a service of your own.
05
Field usability
Interfaces built for gloves, glare and one hand, tested on the devices the work is actually done on rather than the newest handset in the office.
06
Release and support
Store submission, staged rollout, crash reporting and the ongoing queue that a live field application generates.
Depth
The kinds of mobile work we take on.
From a first build through to the sync problems that only appear once an application has been in the field for a few years.
| Type of work | What it involves | How it is engaged |
|---|---|---|
| A field application from nothing | Capture model, offline store, sync design and the back-office contract, designed as one system rather than an app plus an integration. | Project delivery or managed pod |
| Offline behaviour on an existing app | An audit of the current sync path, then the queueing, ordering and conflict rules needed to make it dependable. | Project delivery |
| Cross-platform consolidation | Two native codebases reduced to one, without losing the platform behaviour users rely on. | Dedicated people |
| Back-office reconciliation | The integration itself, and the rules that decide which side wins when both changed the same record. | Dedicated people |
| Running a live application | Store releases, operating system upgrades, crash triage and faults reported from the field. | Dedicated people, business as usual |
Technology and people
What we work with, and who does the work.
Sync design and conflict handling are senior work. The rest of the application does not need to be. Teams are staffed to that split.
Application
- React Native
- TypeScript
- Native modules
- On-device storage
Synchronisation
- Queued writes
- Conflict resolution
- Background sync
- Retry and backoff
Back office
- Salesforce
- REST APIs
- Media and attachment upload
- Authentication and session handling
Release
- App Store and Play Console
- Staged rollout
- Crash and error reporting
- Physical device testing
Roles and seniority available
Mobile engineer
- Application, offline store and sync client
- Lead, senior and mid-level
- Builds against your back-office contract
Integration engineer
- The service the device talks to
- Senior and mid-level
- Conflict and reconciliation rules
Mobile QA engineer
- Device testing across the fleet you support
- Senior, mid-level and associate
- Offline and poor-coverage scenarios
Technical lead
- Sync design and release strategy
- Answers for the quality of the team
- Direct with your stakeholders
Inside your team
How the work runs when the app is yours.
The store listing, the developer accounts and the relationship with the field stay with you. We work behind them.
Your release pipeline
We submit under your developer accounts and your signing identities, or hand a signed build to the team that does. Store presence stays yours.
- Your developer accounts
- Your signing and provisioning
- Release notes in your format
A real field feedback loop
A fault reported from the field is reproduced against the conditions it happened in, poor coverage included, before anyone writes a fix.
- Reproduced before it is fixed
- Offline scenarios tested deliberately
- Field observation where you can arrange it
Data on the device
Encryption at rest, session lifetime and a remote wipe path are decided against the sensitivity of what is being captured, not left to defaults.
- Encryption at rest on the device
- Session and token lifetime agreed
- A defined path to wipe a lost device
Related work
State that has to stay correct across three parties.
We describe the work, not the client.
What it evidences
Transactional state across a workflow
- A two-sided product where order state moves between customer, merchant and delivery
- Detail captured at the point of order and carried intact through routing and fulfilment
- Order state visible from acceptance through to delivery
- Consumer-grade experience held to a transactional standard
CurryDash: our curry-first ordering and delivery marketplace
CurryDash was our own food ordering and delivery marketplace for local curry shops, built around dish-level customisation rather than a fixed menu.
Read the case studyNext step
Tell us what the field team has to do offline.
Describe the work, the devices and the system that holds the record. We will come back with a team shape and a start date.