Native or cross-platform?

Native for iOS and Android, following each platform’s conventions, sharing one record of truth with the web and desktop clients through the same contracts.

How is a staff application distributed?

Through enterprise channels and mobile device management rather than the public store. A customer application goes through store review, planned into the release.

SOFTWARE / MOBILE APPLICATIONS

Native on the device. One record behind it.

Native iOS and Android applications for staff and customers that keep working without a connection, protect what is on the device, and share one record of truth with the rest of the organisation’s systems.

Discuss the work

Illustrative engineering modelLocal / no external action

Local task / reportingDraft

One task, two operating contexts

The work stays
on the device.

Prepare a report without making the connection a requirement for saving it.

Daily reportA local example, ready to save.

No real file is opened or uploaded.

Local stateAwaiting actionService boundary unavailable

01Inside the work

Native applications for staff and customers.

An application for staff in the field and an application for customers are different products with the same discipline. Both are built natively for iOS and Android, following each platform’s conventions for navigation, input and accessibility, so the application behaves the way the device already taught its user. Native code is used where it matters: the camera, the secure store, background work and anything the user feels as speed.

What the application must do is stated as the task before any screen is designed, and the first prototype tests the most uncertain interaction, not the most comfortable one.

02Scope / considerations

Work continues without a connection.

State lives on the device first. A visit is recorded, a form is completed and a photograph is attached whether or not there is signal, and the application syncs when a connection returns. Conflicts are handled explicitly: when two people have changed the same record, the application shows both versions and the rule that decides, rather than silently keeping the last one to arrive.

Local state that survives a closed application and a dead battery
Sync as a queue with a visible status, not a background guess
Conflicts surfaced with the rule that resolves them
The same record identifiers as the server, so nothing is duplicated

Illustrative application · five layers · not a customer system

01Interface

Screens that follow iOS and Android conventions, so the application behaves the way the device already taught its user.

One application drawn as five layers. Conceptual, not a customer system.

03Scope / considerations

Security on a device that leaves the building.

Credentials and keys are kept in the platform’s protected store, the secure enclave on iOS and the keystore on Android, and never in the application’s files or source. Biometric sign-in is offered as a policy the organisation sets, with a fallback it has chosen. Connections to the organisation’s servers pin the certificates they expect, so a hostile network cannot stand in the middle.

Nothing in the application binary is a secret. Anything that must stay private is held on the server and released to a signed-in, authorised session.

Secure enclave and keystore for credentials and keys
Biometric sign-in as a policy decision, with a chosen fallback
Certificate pinning to the organisation’s servers
No secrets in the application

04Inside the work

The same contracts as the web and the desktop.

The mobile application is one more client of the organisation’s systems, not a separate copy of them. It reads and writes under the same contracts as the web and desktop applications, so a case, a customer or an order means the same thing on every screen and is held once, with its history, in one record of truth. A change to a rule is made on the server and applies everywhere at once.

05Inside the work

Release and lifecycle.

A customer application goes through store review, with the review timeline planned into the release rather than discovered on the day. A staff application is distributed through enterprise channels and mobile device management, so installation, update and removal are controlled by the organisation. Every release rolls out in stages, can be rolled back, and has a stated support window, so the version in a user’s hand is always one the organisation still maintains.

06Inside the work

How an engagement starts.

Bring the task the application must serve, the people who will use it, the devices they carry and the systems it must reach. We review the existing systems and their contracts, propose the application and its sync and security model, and agree the release channel and the support window. Platform requirements, store policies and device fleets are confirmed for the particular organisation, not assumed.

Before an enquiry

Questions we are asked.

Short answers in the same terms as the page. Anything specific to your systems is agreed by enquiry.

Native or cross-platform?: Native for iOS and Android, following each platform’s conventions, sharing one record of truth with the web and desktop clients through the same contracts.
Does the application work without a connection?: Yes. State lives on the device first and syncs when a connection returns. Conflicts are handled explicitly rather than silently overwritten.
How is a staff application distributed?: Through enterprise channels and mobile device management rather than the public store. A customer application goes through store review, planned into the release.

A CLEARER NEXT STEP

Discuss a mobile application

From an unanswered question
to an engineered possibility.

Discuss a mobile application