Mobile app development

The mobile work we are asked for is rarely a consumer app. It is the driver confirming a delivery in a basement car park with no signal, the engineer photographing a meter, the shop-floor supervisor booking a batch off. That shapes everything: offline-first data, conflict resolution that a non-technical user can understand, device management, and a release process that does not depend on someone remembering to upload a build. Kanto Manufacturing’s shop-floor app holds a full shift of work offline and reconciles on reconnect; scrap attributed to mis-keyed batch numbers fell by two thirds in the first quarter.

• 01

  Offline-first where the work is offline. Local storage, a sync queue and an explicit conflict-resolution rule agreed with the business rather than invented by a developer.

• 02

  One codebase across platforms unless there is a reason not to. Where the app needs deep platform integration we build native and say why in writing.

• 03

  Store submission handled, including the parts that surprise people: privacy declarations, enterprise distribution, and the review rejection that costs a week if nobody planned for it.

• 04

  Crash and performance monitoring from the first release, with alerts that reach someone rather than a dashboard nobody opens.

• 05

  The same APIs the web application uses, so the two surfaces cannot drift into different truths about the same record.

1. 01

   Field study

   We watch the job being done, in the place it is done. Gloves, sunlight, one-handed use, a dead battery at 3pm and no signal are requirements, and none of them appear in a specification written in an office.

2. 02

   Platform and distribution decision

   Native or cross-platform, public store or managed enterprise distribution, and which devices are actually in the field. This decision is cheap now and expensive in month four.

3. 03

   Build with real devices

   Two-week increments tested on the hardware your people carry, not only a simulator. Offline behaviour is tested by turning the network off, repeatedly, at awkward moments.

4. 04

   Pilot with one team

   A single depot, site or region runs it for a fortnight while the rest continue as they were. That comparison is the only honest way to find out whether it helps.

5. 05

   Rollout and release process

   Staged rollout, a rollback plan, and a release pipeline your own team can run — including the signing certificates, which is the thing that strands an app two years later.

• The application on its target platforms, with source and signing configuration in your repository.
• Offline and sync design note, including the conflict-resolution rule in business language.
• Store listings, privacy declarations and enterprise distribution setup as applicable.
• Automated build and release pipeline, with a documented certificate renewal procedure.
• Crash reporting and performance monitoring, wired to alert a named person.
• Pilot report comparing the piloted team against the control group.

• 01Native or cross-platform?

  Cross-platform for the large majority of business applications: one codebase, one set of business rules, and a team that does not have to be two teams. Native when the app depends on hardware or platform capability that the abstraction handles badly — sustained background location, specialised Bluetooth peripherals, heavy on-device processing. We decide it in week one and write down the reason.

• 02Do we need to publish to the app stores?

  Only if the public should install it. For internal workforce apps, managed enterprise distribution through Intune or the equivalent is faster to release, avoids the review cycle entirely, and lets you push a fix the same afternoon.

• 03What happens to the app when you leave?

  It builds and releases from your pipeline with your certificates, and the certificate renewal procedure is written down and dated. The most common way an internal app dies is an expired signing certificate nobody knew was in one person’s name.

• API

  API and system integration

  Making the systems you already own talk to each other — payments, CRM, ERP, messaging and the third-party APIs in between.

  /services/api-system-integration
• UXD

  UI/UX and product design

  Interface and product design for software people use all day — websites, applications, dashboards and mobile.

  /services/ui-ux-product-design
• CLD

  Cloud and Azure solutions

  Cloud-native applications, migrations and the infrastructure underneath them — with the bill and the recovery plan designed in.

  /services/cloud-azure-solutions