Mobitraxx

in development

From two separate apps to one foundation that works with no signal and protects what it stores.

Mobitraxx is a platform for security companies: their guards walk patrol rounds and log every checkpoint with their phone, even in a basement or out in the countryside. We are rebuilding its two Android apps on a single codebase, without guards having to switch apps.

Type
Client
Platform
Android · iOS in preparation
Scope
Architecture, apps, offline operation, encryption and migration

How it works

The start of a shift: the device is registered once, the guard signs in with a PIN and heads out on the round.

  1. 1Register the deviceThe administrator names the phone and assigns it a licence.
  2. 2Identify the guardThe guard picks their name and signs in with a PIN, even with no signal.
  3. 3Log the checkpointThe guard holds the phone to the tag and the round moves forward.
Version in development · example data

The starting point

Patrols happen where the signal does not reach: underground car parks, warehouses, rural sites. The guard carries the phone and logs every checkpoint with NFC, QR, GPS or a beacon; the company needs to know they were there and when.

There were two apps, Android only and on separate codebases, that had drifted apart. They talked to the server through a technology that is no longer supported, and when the server answered with an error, the reading was thrown away anyway.

And the apps had neither crash reporting nor analytics: when something failed, no one could tell why.

The problems and the decisions

  1. 1A guard with no signal cannot stand waiting for a record to send, or lose the round they already walked.

    What we decided
    Everything is saved on the phone first and sent from a sync queue that retries on its own when the signal comes back: readings, incidents with photos and video, checklists, time clock and the administrator's changes. The server drops duplicates.
    What we gave up
    More logic on the phone: a capped queue, retries with growing waits and rules on what is retried and what is not.

  2. 2What waits on the phone is personal data: employee photos, signatures, video, credentials.

    What we decided
    We encrypt everything sensitive that stays stored —credentials, the user list, the outgoing queue and media—, with the keys protected by the operating system. For photos and video we built an encrypted file store, so an incident with video can also be saved with no signal.
    What we gave up
    The system's encrypted storage is not made for large files: we had to design and maintain our own for media.

  3. 3If a single saved operation got damaged, it could take a whole shift's pending work down with it.

    What we decided
    Each operation in the queue is saved and encrypted on its own. If one is damaged, that one is lost and nothing else.
    What we gave up
    We chose not to add a database and solved it on the encrypted store we already had: fewer dependencies, more care in how the queue is indexed.

  4. 4Two apps drifting apart, and the need to reach iOS too.

    What we decided
    A single Kotlin Multiplatform codebase, with shared interface and logic, that produces both store apps. Crash reporting and analytics from day one.
    What we gave up
    Anything that depends on hardware —NFC, beacons— is built separately for each platform, which makes iOS take longer.

What we have achieved so far

It has not launched yet. It will ship as a gradual update of the current store apps.

  • Two store apps from one codebase, in testing with the client.
  • Patrols, incidents, checklists and time clock work with no signal.
  • Credentials, the outgoing queue, photos, signatures and video are stored encrypted.
  • Crash reporting and analytics on every screen, which the previous apps lacked.
  • Built for the shift: large buttons for gloved hands, a dark theme and a panic button.

How we built it

On a system already in use: the new version replaces the old one on the same store listing and keeps each phone's registration, so no device in the field has to be set up again.

  • 4ways to log a checkpoint: NFC, QR, GPS and beacon
  • 2store apps from one codebase
  • 3languages, with regional variants

Facing a similar challenge?

Tell us what you need to solve. We can help you define the next step.

Let's talk about your project