Mobile apps users keep, not delete.
iOS and Android — native or cross-platform, chosen for your product, not our convenience. Store submission, release trains and crash discipline included.
- Platform & architecture
- Core experience
- Hardening
- Launch & release trains
Native versus cross-platform is a product decision, not a technology preference.
Mobile punishes sloppiness in public. Reviews are visible to every future customer, uninstalling is one gesture, and every release passes a gatekeeper who can hold it back over a detail you did not read. On the web a bad deployment is reverted in minutes; on a phone it sits on users’ devices until a new build is approved and adopted. So we engineer for that reality from the start: start-up time, offline behaviour, crash rates and release automation are first-class requirements, not the polish phase.
The consequence is that most of the difficult decisions are made before the interface is designed. Which platform and why, how data behaves when the network does not, how a release reaches users gradually rather than all at once, and what stops a bad build automatically. Teams that skip those decisions ship a demo that works on the office wifi and then spend a long time discovering what a lift, a warehouse basement and a two-year-old mid-range Android do to it.
We will recommend in writing — with the trade-offs, the device matrix and the maintenance cost of each — before a line is written, and we will say plainly when the answer is that you do not need an app at all.
Four things a mobile product has to get right.
Everything below is decided in the first phase, because each one is structural: changing your mind later is a rewrite, not a refactor.
Platform strategy
React Native or Flutter where one team should ship both stores; Swift or Kotlin where the product demands the metal — sustained camera work, tight hardware integration, platform-first interaction. The recommendation is reasoned and in writing, based on your device matrix, the depth of platform features you need and who will maintain the app in two years. Most business applications ship faster and just as well cross-platform; we say so when that is true, and we say the opposite when it is not.
Offline-first data
Sync engines and conflict handling for the moments your users have no signal — which is exactly when field applications matter most. Writes are queued locally and reconciled when the connection returns, conflicts resolve by an explicit rule rather than by whichever request arrived last, and the interface tells the user what has been saved and what is still pending. Designing this in from the start costs a fraction of retrofitting it after the first complaint from a depot.
Release-train automation
Commit-to-store pipelines: signed builds, versioning, changelogs, phased rollouts, and crash gates that halt a bad release automatically before it reaches the rest of your users. Certificates and signing keys live in your accounts and in the pipeline, not on a laptop, so a release does not depend on one person being available. The train runs on a regular cadence agreed with you, which makes shipping ordinary rather than an event.
Store & review readiness
Submission handling, review-guideline compliance, privacy declarations and data-safety forms, and the store-listing assets — the last mile most teams underestimate and the one that decides whether launch week happens on schedule. We prepare the metadata and the review notes with the build rather than after it, and when a rejection does arrive we own the response and the resubmission cycle.
How the work runs, day to day.
The platform decision, made on evidence.
Native or cross-platform is the first question we are asked and the one most often answered by habit. We answer it against your product: what the app must do with the device, how much of the interface is genuinely platform-specific, what your audience is carrying, and who maintains it after handover. A single team shipping one codebase to two stores is a real economic advantage, and it is the wrong choice when the product lives in the camera, the sensors or a background service the operating system treats as privileged. The decision goes in the architecture note with the reasoning, so it can be revisited on facts rather than reopened as an opinion.
- A written recommendation with trade-offs, device matrix and two-year maintenance cost
- Shared business logic in TypeScript where a cross-platform client is the answer
- Native modules where a specific capability needs them, without rewriting the whole app
The network is not a given.
Field users work in the places where connectivity fails: basements, warehouses, lifts, rural routes, an aircraft on stand. An application that treats the network as a precondition simply stops being useful at the moment it was bought for. We design the data layer the other way around — the device holds the working set, writes queue locally with an idempotency key, and reconciliation happens when the connection returns without duplicating what already landed. Conflicts resolve by a rule agreed with your operations team, and anything the rule cannot settle is surfaced to a person instead of resolved silently in favour of whoever synced last.
- Local-first writes with idempotency keys, so a retry corrects rather than duplicates
- Explicit conflict rules agreed with the business, not last-write-wins by accident
- Sync state visible in the interface: saved, pending, failed — never ambiguous
A release train, and a gate that stops it.
The difference between teams that ship monthly and teams that ship when they dare is automation. Every commit on the release branch produces a signed build; the build goes to internal testers, then to TestFlight or the closed track, then to a phased rollout that starts at a small percentage of users. The gate is what makes the rollout safe: crash-free sessions and error rates are watched automatically, and a breach halts the rollout before the majority of your users ever receive the build. Rolling forward with a fix is then a normal day rather than an incident, because the pipeline that would ship it has already run many times.
- Signing keys and certificates in the pipeline and your accounts, never on a laptop
- Phased rollout by percentage, with crash and error thresholds agreed in advance
- Automatic halt on a breach, and a rehearsed path to a corrective release
- 01Commit
- 02Signed build
- 03Internal track
- 04Phased rollout
- 05Full release
Release train
One app, three sets of consequences.
The rating is the retention metric.
For a consumer application the store page is a public scoreboard, and the two things that move it most are start-up time and crashes. We budget cold start on mid-range devices, keep the first screen useful without waiting on the network, and treat crash-free sessions as a release gate rather than a monthly report. Review mining feeds the backlog directly, because the uninstall reasons are usually written down by the people who left.
- Cold-start budget measured on mid-range hardware, not on a flagship
- Crash-free sessions gating every rollout
- Store reviews mined and mapped to backlog items each cycle
Built for the depot, not the demo.
Operational apps live on shared devices, in gloves, in bad light and out of signal. That changes the interface as much as the architecture: large targets, few taps per task, work that survives a dead battery, and a device matrix that includes the rugged handsets your teams actually carry. Data flows back into your systems of record through the patterns described on our integration page, so operations sees one truth rather than two.
- Offline working set with queued writes and a supervisor path for conflicts
- Device matrix agreed from your fleet, including older and rugged hardware
- Barcode, NFC, camera and location handled as first-class inputs
A release you can run without us.
Everything is code: the app, the pipeline, the signing configuration, the crash dashboards and the runbooks. Your engineers review pull requests from the first sprint if they want to, and the handover is a rehearsal of the release train rather than a slide deck. The same delivery standards apply as on our DevOps & Cloud engagements.
- Commit-to-store pipeline defined as code, reproducible on a fresh machine
- Test strategy set with QA & Testing: unit, integration, device lab and release smoke
- Runbooks for rejection, rollback and a hotfix release, rehearsed before handover
What is standard, and what is shaped per product.
Four phases, on real devices from early on.
Platform & architecture
Audience, device matrix and the native-versus-cross-platform decision — then navigation, data and offline architecture. We take the device and operating-system spread from your analytics or your fleet inventory rather than from an industry average, agree the start-up and crash targets, and write the recommendation down with its trade-offs. Store accounts, signing and the skeleton pipeline are set up in this phase, so the first build can reach a tester early.
Core experience
The flows your rating depends on, built and demoed on real devices regularly — TestFlight or the internal track from early on. We build one journey end to end before spreading sideways, including its offline and error states, because those are the states that decide whether people keep the app. Every demo happens on hardware from the agreed matrix, so performance feedback arrives while it is still cheap to act on.
Hardening
Performance passes, crash-free targets, accessibility, and the device-lab matrix. We profile cold start and the heaviest screens on mid-range hardware, exercise the failure paths deliberately — no signal, expired session, denied permission, full storage, interrupted payment — and run the accessibility pass with the platform screen readers. Anything that could hold a store review is found here rather than by a reviewer.
Launch & release trains
Store submission, phased rollout, monitoring — and a repeating release train your team can run. We handle the submission and any review correspondence, start the rollout small with crash gates armed, and watch the first cohorts with you. The phase ends with the train rehearsed by your engineers: a full cycle from commit to store, including a deliberate halt and a corrective release.
What is on the table at launch.
- Store-published apps on iOS and Android
- Commit-to-store CI/CD with signing and phased rollout
- Device/OS support matrix with test coverage
- Crash and performance monitoring with alert thresholds
- The written platform recommendation and architecture note
- Offline and sync design, including the conflict rules agreed with your operations team
- Runbooks for store rejection, rollback and hotfix releases, rehearsed with your team
When this is the right call.
Choose a mobile build when the product needs the device — a camera, a scanner, location in the background, notifications people act on, or work that has to continue without a network. It fits consumer products where retention depends on start-up time and stability, field and depot applications where the phone replaces paper, and companion apps to a platform you already run. It is also the right call when an existing app has poor reviews and no release discipline: crash data and review mining name the top uninstall drivers before any code changes.
Look elsewhere when the same job is done as well in a browser — forms, dashboards, occasional use, anything shared by a link. A web application ships faster, updates without a gatekeeper and costs less to keep alive, and an installed icon is not by itself a reason to build one. Look elsewhere when the business claim has not been tested yet: an MVP, sometimes on the web first, answers that more cheaply. And be cautious when nobody will own releases after handover — an app that stops shipping starts breaking on the next operating-system version.
Frequently asked questions
What this connects to.
What has to work when the signal drops?
Tell us who carries the device and what they are doing with it. An engineer who has shipped to both stores reads it and replies with a written recommendation.