- Client
- Trackforce, maker of Tracktik, a workforce management platform for physical security operations
- Engagement
- Embedded in Trackforce's mobile team: led three Trackforce developers on stability work and owned the architecture for a new version of the app
- Product
- The Tracktik mobile app: shifts, patrols, incident reports and communication with dispatch
- Platform
- Native Android (Kotlin)
| Before | After |
|---|---|
| Freezes (ANRs) on guards' devices | ANRs down by more than 90% |
| Report submission had to hold up on poor connections | Reliable incident report delivery |
| A new version planned while designs were still changing | Development kept moving while designs settled |
| Guards offline for long periods | An offline-first architecture built for months without a connection |
ANRs measured in Firebase Crashlytics, before and after the stability work.
90%+fewer ANRs, measured in Firebase Crashlytics
Reliableincident report delivery
Monthsof offline operation the new architecture is built for
The brief
Guards work in parking garages, basements and remote sites with weak or no signal, sometimes for months. They still clock shifts, log patrols and file incident reports, and none of it can be lost.
Trackforce needed two things at once: a stability push on the app guards use every shift, and the architecture for a new version of the app.
What was at stake
- An app that freezes on a guard's phone means a missed check-in, or an incident report that never reaches dispatch.
- Guards can be offline for months, so the new version had to treat the device, not the server, as the place work happens.
Our approach
Decision 01Fix freezes at the source, not the symptom
- Context
- Freezes on guards' devices came from slow work running where the user interface waits on it.
- Decision
- Move that work off the main thread across the critical paths, one path at a time, in code guards depend on during a shift.
- Tradeoff
- Slower than patching individual crashes, in exchange for removing the cause rather than its symptoms.
Decision 02Conflict rules per type of data
- Context
- Guards can be offline for months, so device and server data regularly both change before a sync.
- Decision
- A conflict rule for each type of data instead of one global rule.
- Tradeoff
- More rules to define and test, in exchange for never letting one kind of data overwrite another that must not be lost.
Decision 03Build the lower layers before the UI
- Context
- The designs for the new version were still changing.
- Decision
- Build and test the business logic, API calls and storage first, separately from the screens.
- Tradeoff
- Interfaces had to be settled before the screens existed. In return, each screen plugged into working code as its design was ready.
How we worked with the team
- Inside Trackforce's process. Their repository, code review and sprints.
- Led three Trackforce developers on maintenance and stability: root-cause analysis, implementation, review and following each fix through to release.
- Kept the team moving on the new version by building the lower layers first, so changing designs didn't block development.
- A structured handover to Trackforce's team at the end of the engagement.
For your tech lead
The technical patterns behind this work are written up in our own engineering notes, without client detail:
Next step
Need a field app that keeps working when the network doesn't? Tell us where it breaks today.
Book a 30-minute technical callor email info@devsflow.ca