Get in Touch
Mobility Solutions Scope Method Coverage Offline FAQ
Scope Method Coverage Offline FAQ
About Us
AI Solutions overview AI Consulting Services AI Strategy and Readiness Enterprise AI Implementation Generative AI Consulting Agentic AI Consulting AI Automation AI Integration
Oracle Services overview Oracle Fusion Cloud Oracle Fusion Financials Oracle Fusion HCM Oracle Fusion SCM Oracle Fusion Project Oracle Sales Cloud Oracle EPM Planning and Budgeting Oracle Hyperion Financial Accounting Hub Oracle BI Integration Oracle Technology Oracle SOA Suite Oracle DBA Oracle APEX Oracle OIC Oracle VBCS Oracle E-Business Suite EBS Upgrade and Support EBS Migration to Cloud Oracle NetSuite NetSuite SuiteScript NetSuite CRM NetSuite Supply Chain, Inventory & Manufacturing NetSuite HCM NetSuite Analytics & AI
Salesforce overview Salesforce Implementation Salesforce Integration Salesforce Managed Services Agentforce and Salesforce AI Salesforce Migration
Microsoft Enterprise Services overview Microsoft Dynamics 365 F&O Microsoft Business Central Microsoft Power BI The .NET Framework
Application Management overview Java Development Mobility Solutions Android App Development React Native Xamarin Universal Windows Platform Automation Testing Services Katalon Selenium DevOps Web Development LAMP Stack MEAN Stack E-commerce Solutions Enterprise E-commerce
Managed IT Services overview Infrastructure Monitoring Network Support End User Support System Support Managed Cloud Services Managed Security Services
Managed Business Services overview Logistics BPO Services Finance and Accounting Services Healthcare BPO Services Mortgage Loan Processing Order Processing
AtomicRoute Enterprise AI Atomic HR
Manufacturing Government and Non-profit IT Services and Networks Education Real Estate Media Logistics Pharmaceutical
Insights Newsroom Gallery Why AtomicNorth Get in Touch

Apps that work where
the signal does not

Native and cross-platform mobile applications for field teams and customers, designed around offline behaviour, real devices and the store review process that stands between you and a release.

Offline is designed at the data model, not bolted on with a cache once the screens are finished.

Get in touch See the delivery method
PlatformsiOS, Android, cross-platform

Swift and Kotlin where the platform matters, React Native or Flutter where one codebase serves better.

Design pointOffline first

The application assumes no connection and treats connectivity as an event rather than a precondition.

ReleasesManaged end to end

Store accounts, signing, phased rollout and the rejection that arrives at the worst moment.

DevicesYour actual estate

Tested on the models and operating system versions your people carry, not only on the current flagship.

What we build

Mobile applications for work and for customers

Field applications and customer applications fail differently. One is judged on whether a job can be completed in a basement; the other on whether a stranger can finish a task without help. Neither is served by the same design.

Field and workforce applications

Job dispatch, inspections, asset capture, signatures, photographs and forms, built for gloved hands, bright sunlight and no connection.

Data capture is designed so a partly completed job survives a dead battery, an app kill and a shift change without the engineer retyping anything.

A job that can be finished without a bar of signal.

Customer-facing applications

Accounts, ordering, bookings, self-service and notifications, with the onboarding path treated as the part most users will judge you on.

Accessibility and larger text sizes are handled in the layouts from the start, because retrofitting them into finished screens means rebuilding them.

An application a first-time user can finish a task in.

Offline and synchronisation

Local storage, queued writes, conflict resolution rules agreed with the business, and a sync state the user can actually see.

Conflict rules are a business decision rather than a technical default. Last write wins is a choice, and someone senior should make it knowingly.

Sync behaviour that is explainable when it surprises someone.

Cross-platform delivery

React Native and Flutter where one codebase is the right economics, with native modules written where the platform APIs demand it.

We will recommend native when the application leans on hardware, background behaviour or platform integration, and say why rather than defaulting either way.

A platform choice with the reasoning written down.

Backend and integration

The APIs behind the application: authentication, push notifications, sync endpoints, and integration into the systems already holding the data.

Mobile clients cannot be force-updated in the field, so interfaces are versioned and older clients keep working through a release.

A backend that tolerates old app versions in the wild.

Store release management

Signing and certificate lifecycle, provisioning, review submissions, phased rollout, crash monitoring and the fix release that follows.

Certificate and provisioning expiry is inventoried and alerted, because that is the release-day outage almost every mobile team has had once.

Releases that are a process rather than an event.

How a mobile engagement runs

StepOneScope

The task the application exists to complete, watched where it happens: the depot, the van, the ward, the customer's own kitchen.

Field applications designed from a meeting room get the workflow wrong in ways nobody notices until adoption stalls.

You receive:

A scoped brief

The tasks in priority order, the device estate and operating system spread, the connectivity reality, and the integrations required.

Where an off-the-shelf product covers the need, the brief says so, including when that means we build less.

StepTwoPrototype

A working prototype on real devices in the real setting, covering the primary task and the offline path rather than a full feature set.

Screens on a laptop are a poor test. A prototype in a gloved hand in a loading bay tells you within a day what needs to change.

You receive:

A tested prototype

The main task working end to end on the devices your people carry, with the data model and sync approach validated against it.

Feedback captured from the people who will use it, not only from the team commissioning it.

StepThreeBuild

Iterative delivery with a build on your testers' devices throughout, automated tests on the logic, and device testing across the estate spread.

Offline and interrupted states are tested deliberately: connection dropped mid-write, application killed, device rebooted, clock wrong.

You receive:

Releasable builds

Distributed builds each iteration, crash and performance instrumentation from the first one, and store submission rehearsed before it is needed.

No launch date is fixed until a submission has passed review and a phased rollout has run clean on a small share of the estate.

StepFourRelease

Phased rollout, crash and adoption monitoring, then the ongoing operating system releases that arrive on Apple's and Google's calendars.

Mobile maintenance is not optional. Two annual platform releases will break something whether or not the application is being changed.

You receive:

A release and support cadence

Crash-free rate and adoption by version reported, store feedback triaged, and platform release readiness handled ahead of each cycle.

Old app versions in the field are tracked, because they decide when a backend interface can finally be retired.

01
Coverage

What sits in the mobility practice

Delivered as a project, or as a project that converts into a maintenance retainer covering platform releases and store operations.

Mobility Solutions coverage
AreaPlatformsScopeModel
Native iOS Swift, SwiftUIDesign, build, hardware and background integration, submissionProject or retainer
Native Android Kotlin, JetpackDesign, build, device fragmentation handling, submissionProject or retainer
Cross-platform React Native, FlutterShared codebase build with native modules where requiredProject or retainer
Offline and sync Local stores, queued writes, conflict rulesData model design, sync engine, conflict policy, recoveryProject
Backend APIs, push, authenticationInterface build, versioning for old clients, integrationProject or retainer
Device management Managed and bring-your-own estatesDistribution, policy and enrolment alongside our end user supportRetainer
Store operations App Store, Google PlaySigning, certificates, submissions, phased rollout, crash triageRetainer
Offline

Offline is a data model problem, not a caching problem

Almost every field application is specified as offline capable and then built online first, with local storage added late as a cache. It works in testing, because testing happens on a desk with good signal. It fails in a lift shaft, where a partly completed job disappears and the engineer starts typing it again.

Designing for offline from the start means deciding earlier and harder: what the device owns, what the server owns, what happens when both have changed the same record, and how the user sees which of their work has actually left the device. Those are business decisions with technical consequences, so they get made with the business in the room.

Ask for a mobility review
  • Device owns the workIn-progress capture survives an app kill, a reboot and a flat battery. Nothing is lost because the network was absent.
  • Conflicts have rulesSimultaneous edits resolve by a policy the business has agreed and can explain, rather than by whichever write arrived last.
  • Sync is visibleThe user can see what has been sent and what is still queued, so trust in the application does not depend on faith.

Indicative practice. Conflict policy and storage approach are agreed per application during scoping.

Questions we get asked

Before starting a mobile build

Native or cross-platform?

It depends on what the application does rather than on which we prefer. Cross-platform is good economics for form-driven applications with conventional interfaces, and the tooling is mature enough for serious work. Native earns its extra cost when the application leans on hardware, background processing, tight platform integration or demanding graphics. We will put the reasoning in writing so the choice can be challenged.

Can you take over an app we already have?

Yes, and the first questions are unglamorous: can it be built from a clean checkout, who holds the store accounts, and where are the signing certificates. Those three block more mobile takeovers than the code does. Once they are resolved, the codebase assessment is straightforward.

Who holds the App Store and Google Play accounts?

You do, always. The developer accounts, the certificates and the app listings stay in your organisation's name and we operate inside them. An agency holding your store accounts makes leaving them expensive, and that is not a lever worth handing anyone.

How do we handle users who never update the app?

By assuming they exist, because they do. Interfaces are versioned so older clients keep working, the application can prompt or force an update when a change genuinely requires it, and installed versions are tracked so a retirement date for an old interface is based on data rather than hope.

Do we need to support every device our staff carry?

Not every one, but you need to know what the spread actually is before deciding. Most estates contain a long tail of older models on operating system versions nobody remembers approving. We take the inventory first, then agree a supported baseline in writing, and we say plainly which devices fall outside it.

Mobile thatworks on site.

Start with a mobility review. It covers the task, the device estate and the offline reality, and it produces a scoped brief you keep either way.

Get in touch Book a scoping call