02Mobile Applications
Mobile products that hold up in the field.
Applications used by field engineers, drivers, inspectors and customers — where the network is unreliable, the device is managed, and the data on it matters.
01Where it starts
What we usually walk into.
Mobile projects are often scoped as a smaller version of the web product, then fail on the things that are specific to mobile: offline behaviour, background sync, device management, store review and long-term OS churn.
The app breaks when connectivity drops, and field staff go back to paper.
Sync conflicts silently lose data, and nobody trusts the numbers.
Each OS release costs weeks of firefighting.
Store review keeps rejecting releases and nobody owns the process.
Security review blocked the launch because credentials and cached data were not handled correctly.
02Approach
How we do the work.
We design the synchronisation and security model first, then build against real device and network conditions, with release engineering set up from the first build.
- 01
Offline is a design decision
We decide explicitly what works offline, what is queued, and how conflicts resolve — before writing UI. Retrofitting offline support into an online-first app is close to a rewrite.
- 02
One platform choice, argued
Native or cross-platform is a trade-off between hardware access, team skills and release cadence. We make the recommendation explicit with its consequences rather than defaulting to a preferred stack.
- 03
Device-realistic testing
We test on constrained hardware, throttled networks and managed device profiles, because that is where enterprise mobile applications actually fail.
- 04
Release engineering from day one
Signed builds, staged rollouts, crash reporting and store metadata are automated in the first weeks, so releasing is routine rather than an event.
Capabilities and deliverables
Capabilities
- Native iOS and Android development
- Cross-platform delivery where it is the right trade-off
- Offline-first data architecture and conflict resolution
- Background processing and push notification design
- Biometric and certificate-based authentication
- MDM and enterprise distribution
- Store submission and release management
What you receive
- Application source, delivered into your repositories
- Offline and synchronisation design with documented conflict rules
- Automated build, signing and distribution pipeline
- Crash reporting, analytics and release health dashboards
- Store listing preparation and submission support
- Accessibility review against platform guidance
Common use cases
- Field service and workforce management applications
- Inspection, audit and compliance capture
- Logistics and proof-of-delivery applications
- Secure customer applications with strong authentication
- Companion applications for an existing enterprise platform
Technologies typically involved
- Swift
- Kotlin
- TypeScript
- Go
- SQLite
- PostgreSQL
- Redis
- Firebase
- OpenTelemetry
- Kubernetes
03Engagement
How it runs.
- 01
Discovery
1–2 weeks
Field observation where possible, user and device inventory, connectivity and security constraints.
- 02
Design & architecture
2–4 weeks
Interaction design, synchronisation model, platform recommendation and release strategy.
- 03
Build
Ongoing
Iterative delivery with internal test builds available from the first sprint.
- 04
Launch & support
4+ weeks
Staged rollout, store submission, crash triage and post-launch iteration.
04Security
Security considerations.
These apply to this service specifically. They are engagement conditions, not aspirations, and we will put them in the contract.
- Credential storage in platform keychain and keystore, never in shared preferences
- Certificate pinning and transport policy for sensitive endpoints
- Local data encryption and remote wipe behaviour agreed with your security team
- Jailbreak and root detection where the threat model justifies it
- Third-party SDK review — every SDK is a data-processing decision
05Outcomes
What changes afterwards.
An application people can actually use where the work happens, and a release process your team can run without us.
- 01
Field staff complete work in the application instead of working around it
- 02
Releases ship on a schedule rather than when someone has time
- 03
The application is built to pass enterprise security review before launch, not patched after it
- 04
OS upgrades become routine maintenance instead of emergencies
06Questions
Asked before every engagement.
It depends on hardware access, performance requirements and who maintains the app afterwards. If your team is already strong in one ecosystem, or the app needs deep platform integration, native usually wins. For form-heavy internal applications with a shared team, a cross-platform stack is often the better economic choice. We make the recommendation with the trade-offs written down.
Yes. We start with a technical assessment: dependency health, build reproducibility, test coverage, crash rate and security posture. You get a written view of what is worth keeping and what should be replaced before any code changes.
We prepare and submit releases under your organisation accounts. The accounts, signing identities and store presence stay yours, which matters if the engagement ends.
Frequently runs alongside
Ready to scopemobile applications?
Bring the problem, the constraints and the deadline. We will tell you what is achievable, what it costs and what we would do first.