Software & Platforms
The full domain, and the other capabilities within it.
Mobile Applications
iOS and Android applications where offline behaviour, sync and the release process are designed before the first screen.
What this is
A mobile application is three things at once: the client on the device, the backend that serves it, and the release process that gets both into users' hands. We build native and cross-platform apps for iOS and Android together with the backend for frontend they depend on, the identity flows they authenticate through, and the pipeline that builds, signs, releases and monitors them.
The failure mode we see most often is offline support treated as a caching feature. Caching makes reads work without a network; it does nothing about two devices editing the same record while both are offline. Without a conflict-resolution rule decided up front, the app quietly discards one user's edits, and that surfaces months later as data nobody can explain.
When you need it
If more than one of these is true, this is usually the right place to start.
- Field staff lose work when they walk out of coverage, and the app gives them no way to know whether their last change was saved.
- A release takes days of manual steps and store-review anxiety, so fixes wait for the next batch instead of going out.
- Crash reports reach you from users rather than from instrumentation, and you cannot reproduce them on a device you own.
- The mobile client calls the same APIs as the web app and pays for it in round trips, payload size and battery.
What the scope covers
- Platform choice — native Swift and Kotlin, or a shared codebase — argued from your feature set, team and release cadence rather than from a default.
- Offline and sync design: what is available offline, how changes queue, and the explicit rule that resolves a conflict.
- A backend for frontend shaped for mobile round trips, payload size and battery, rather than reusing the web API unchanged.
- Identity, session and device trust, including biometric unlock, token refresh, and remote sign-out for a lost device.
- Build pipeline, signing, store release and staged rollout, with crash and performance reporting wired in before launch.
What you receive
| Deliverable | What it contains |
|---|---|
| Signed app builds | iOS and Android builds produced and signed through your own developer accounts, with internal test tracks configured for your reviewers. |
| Sync and conflict spec | A written specification of offline scope, queueing behaviour and conflict resolution, separating the cases that resolve automatically from the cases that ask the user. |
| Backend for frontend | The mobile-facing API layer, its contract and its tests, deployed into your environments alongside the app rather than bolted on afterwards. |
| Release pipeline | Automated build, signing, store submission and staged rollout, with crash reporting, symbol upload and a documented route back to the previous version. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Crash-free sessions and crash-free users per release, read from your own crash reporting rather than from store summaries alone.
- Cold start time and time to interactive on the mid-range devices your users actually carry, sampled every release.
- Sync queue depth, retry counts and conflict occurrences, so offline behaviour is observed rather than assumed.
Questions we are asked
Native or cross-platform?
It depends on how much of your value sits in platform-specific capability. Heavy camera, background location, Bluetooth or widget work argues for native Swift and Kotlin. Form-heavy, content-heavy and workflow apps are often better served by a shared codebase, which halves the surface you maintain. We make the argument in writing against your feature list, and we do not pretend one answer fits every app.
How do you handle offline conflicts?
By deciding the rule before writing the sync code. Common choices are field-level last-write-wins, a server-authoritative merge, or explicit user resolution for records where either side may be right. Each has consequences your business users have to accept, so this is a product decision recorded in the specification, not an implementation detail we settle quietly.
Can you publish under our developer accounts?
Yes, and we prefer it. Apps live in your Apple and Google accounts with your signing identity from the beginning, so ownership, certificates and the store relationship never depend on us. We work as members of your teams with whatever access level you grant.
How long does app store review take?
Review time is set by Apple and Google and we cannot promise a number. What we can reduce are the rejections you control: privacy declarations, permission usage strings, account deletion routes and sign-in requirements are the recurring causes. We prepare those before the first submission rather than after the first rejection.
Do we need a separate backend for the app?
Not always a separate system, but usually a separate layer. A mobile client on a slow network benefits from endpoints shaped to its screens rather than to your domain model. A backend for frontend sits over your existing services and does that shaping without forking your business logic into a second implementation.
How do you approach mobile application security?
We build against the OWASP Mobile Application Security Verification Standard as a working checklist: certificate handling, secure storage of tokens and keys, obfuscation where it is worth its cost, and a rooted or jailbroken device policy agreed with you. If you need an independent penetration test we will support it and fix what it finds; we do not review our own work and call that assurance.
Continue reading
Enterprise Software
Custom enterprise systems designed around the data model and the integration surface, with role-based access, an audit trail and a reconciled data migration.
API & Integration
API and integration engineering: contract-first design, gateway and broker configuration, idempotency and retry handling, tracing and per-consumer analytics.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.