Atmora Tech

Engineering

Apps for people
wearing gloves

Most enterprise mobile work happens one-handed, outdoors, on a handset at fourteen per cent battery with no signal. We design for that condition first, with offline writes, agreed conflict rules and large targets, then make the interface handsome.

Overview

Native and cross-platform apps built for field conditions, not conference demos.

The decision that shapes everything else is offline behaviour. An app that assumes connectivity fails the moment a driver enters a basement loading bay, so we treat the local store as authoritative for the working session and reconcile on reconnect using conflict rules the business has explicitly signed off.

Platform choice comes second and is a real trade-off. React Native and Flutter share roughly 85 per cent of the code and cut ongoing release effort; Swift and Kotlin win when you need tight camera control, background location that survives aggressive power management, or Bluetooth peripherals that behave differently per manufacturer.

Release engineering is where mobile projects quietly lose weeks. Signing, provisioning, staged rollout percentages and forced-upgrade handling all go in during the first fortnight rather than the week before launch, because a two-day store review cycle is tolerable and a broken release you cannot recall is not.

99.4%
crash-free sessions across the fleet on the last release
6 hours
of continuous offline operation covered before sync is needed
38 s
average yard inspection completion, down from 96 seconds

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Offline-first data layer

    A local store treated as authoritative for the working session, with queued mutations, deterministic conflict resolution and a sync log an operations lead can read when two depots disagree.

  • Native iOS and Android

    Swift and Kotlin where the hardware matters: camera pipelines, barcode capture at speed, background location under Doze and manufacturer battery managers, and Bluetooth peripherals with awkward firmware.

  • Cross-platform delivery

    React Native and Flutter builds sharing most business logic across both stores, with native modules written only where the shared layer cannot reach the platform capability you actually need.

  • Device fleet and enrolment

    Distribution through Intune, Jamf or managed Google Play, kiosk and single-app modes for shared handsets, and certificate handling that does not need a technician standing at each site.

  • Field-condition interface design

    Targets sized for gloved hands, contrast tested in direct sunlight, and flows that survive interruption, so a scan half-finished at a gatehouse resumes where it stopped instead of restarting.

  • Release engineering and rollout

    Signing, provisioning, phased rollout percentages, forced-upgrade gates and crash-rate halt triggers configured before the first store submission rather than during launch week.

Deliverables

What you get

  • iOS and Android builds signed under your own developer accounts
  • Offline sync design with written, business-approved conflict rules
  • Store listings, screenshots and review submissions handled for you
  • Crash and performance dashboards segmented by device model
  • MDM distribution package with enrolment instructions for sites
  • Forced-upgrade gate and remote configuration mechanism

Stack

What we build it with

  • Swift
  • Kotlin
  • React Native
  • Flutter
  • SQLite
  • WatermelonDB
  • Firebase Cloud Messaging
  • Fastlane
  • Detox
  • Bitrise
  • Sentry
  • Microsoft Intune

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Field observation

    We spend shifts with drivers, technicians or nurses. Ten hours of watching produces requirements that ten workshops do not, particularly around interruption and one-handed use.

  2. Platform decision

    A short written comparison of native against cross-platform for your specific hardware and release needs, with the cost consequence of each option named rather than implied.

  3. Sync design first

    Offline behaviour, conflict rules and merge outcomes are agreed with the business before feature work begins, because retrofitting sync means rewriting the data layer.

  4. Build and device testing

    Two-week increments tested on a physical fleet matching your real device mix, including the low-end handsets procurement bought three thousand of last year.

  5. Staged store rollout

    One per cent, then ten, then fifty, with crash-free session rate gating each step and a halt trigger that fires without needing anyone to be awake.

When this is the wrong engagement

If your users sit at desks on reliable connectivity, an app is a second codebase and two store review cycles bought for nothing a responsive web application could not already do.

FAQ

Questions we get asked

Native or cross-platform for our case?

If the app is forms, lists, scanning and push notifications, cross-platform saves roughly a third of the build and most of the ongoing release effort. If it depends on precise camera control, sustained background location or unusual Bluetooth hardware, native repays itself in the debugging you avoid.

How long does app store review actually take?

One to three working days on both stores in normal conditions, longer for a first submission and for anything touching payments, health data or account deletion. We plan release trains around that and keep a rollback build ready, because a live release cannot be recalled instantly.

Our staff share handsets. Does that change anything?

Considerably. Shared devices need fast session handover, no personal data persisted between shifts, and kiosk mode so nobody wanders into the browser. We also treat battery as contested and cut background work, since a flat handset at hour six becomes a support call.

Can the app work with our existing backend?

Usually, though mobile exposes assumptions server teams never had to make. We commonly add a small aggregation layer so a screen costs one round trip instead of six, plus idempotency keys, because a retried request over a flaky connection must not create a second delivery note.

Related

More in Engineering

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project