Mobile App Integration
Every record cached on a phone is a record that can be lost, stolen, or wrong. Integration on mobile is mostly about deciding which ones earn that.
- Typical duration
- Two to seven months
- Team shape
- Two to four senior engineers
- Starts with
- A device data review
The device is the least trusted place in your architecture
A phone gets lost, shared, rooted, or handed to a colleague. It goes offline for days and comes back with edits. It runs a version of your app you shipped two years ago. Every integration decision has to hold under all four.
So the first question is not how to connect, but how little has to live on the device — which records genuinely need to be there for the work to happen offline, and which can be fetched, shown and forgotten. After that the engineering is the familiar set: one owner per record, idempotent writes, explicit retries, and a queue that survives the app being closed mid-sync.
What usually goes wrong, and what we do instead
Mobile integration failures are almost always about what was cached and what happened to the queue.
Where mobile integrations go wrong
- A full copy of a dataset cached because it was easier than paging
- A sync queue lost when the app is closed or the OS reclaims it
- Retries that duplicate records because writes are not idempotent
- Credentials or tokens stored where another app can reach them
- A backend change that strands every installed version at once
How we build it instead
- The on-device data set justified record by record, and kept small
- A durable queue that survives a kill, a restart and a low-memory event
- Idempotency keys on every write, so a retry is never a duplicate
- Tokens in the platform keystore, with revocation that actually works
- Additive backend changes and a written deprecation policy
What we build
The parts of a mobile integration that decide whether the field team trusts it.
On-device data design
What lives on the handset, justified record by record, and what is fetched and forgotten.
Durable sync queues
Outbound work that survives an app kill, a restart and the OS reclaiming memory.
Conflict resolution
A rule per data type, agreed before it is built, and explainable to the support team afterwards.
Credentials and revocation
Tokens in the platform keystore, with a revocation path that works on a device you no longer have.
Back-office integration
ERP, CRM and the line-of-business systems the process depends on, on agreed record ownership.
Field observability
Errors by app version and device, so a problem two hundred miles away is diagnosable from here.
How the pieces fit together
The same shape whether the app talks to one system or ten: a thin client, an integration layer that owns translation, and a queue between them that assumes the network will fail.
What each part does
- The on-device store: only the records needed to work offline, justified individually and encrypted at rest.
- The outbound queue: durable across app kills and restarts, so a write survives the user closing the app mid-sync.
- The integration layer: translation and validation in one place, so a back-office field name never reaches the handset.
- Idempotency and retry: every write carries a key, so a repeated delivery is a no-op rather than a duplicate record.
- The systems of record: one owner per record, agreed with the team that owns each system before anything is built.
- Observability: errors and latency broken down by app version and device, so a field problem is diagnosable remotely.
How the work runs
The same five stages as every engagement, applied to a device that cannot be trusted.
Diagnose
What the app needs to do offline, which systems own which records, and what the network is like where the work happens.
Decide
The on-device data set, the conflict rules and the failure semantics, written down and agreed with each system's owner.
Prove
One integration end to end from a real device, including its offline case, its retry and its conflict.
Deliver
Integrations built one at a time, each monitored in the field before the next is scoped.
Hand over
Your team runs it with us watching, then without us.
What we build it with
Chosen for what an integration has to survive on a device you do not control.
On device
- Room
- SwiftData
- SQLite
- Keychain
Interfaces
- REST
- GraphQL
- Kafka
- Firebase
Services
- Node.js
- TypeScript
- Java
- Spring Boot
- PostgreSQL
Platform
- AWS
- Azure
- Datadog
- Sentry
What you get, and when
Handed over as it is produced, not assembled at the end.
- The on-device data set, justified record by record
- Record ownership agreed in writing with each system's owner
- A conflict rule per data type, decided before any build
- Source in repositories you own
- A durable queue with a monitored dead-letter path
- Contract tests per system, running on a schedule
- Dashboards broken down by app version and device
- A runbook per alert, including what must not be retried
- A device-loss procedure covering credentials and cached data
The rest of our mobile work
A mobile engagement rarely stops at one of these. These are the ones next to it.
Related work
Engagements where a handset had to agree with the systems behind it.
Questions about mobile integration
The ones we are asked most often before a first conversation.
How much data should live on the phone?
What happens when a device is lost?
Can the app talk directly to our ERP?
Who wins when the field and the office edit the same record?
Our staff can be offline for days. Is that a problem?
How do backend changes affect installed apps?
App that has to agree with your back office?
Tell us what the field team does offline. We will tell you what has to live on the device.