NEXSUM_LABS
  1. Home
  2. Work
  3. An equipment dealer network replaced paper inspection sheets with a shared-iPad app its technicians kept using
Book a call

[ Case study ]

Agricultural equipmentSwiftUIKitCore DataSwift Concurrency

An equipment dealer network replaced paper inspection sheets with a shared-iPad app its technicians kept using

Pre-delivery and warranty inspections lived on paper forms that were photographed, emailed, and retyped — warranty claims waited on office transcription, and disputed inspections had no authoritative record.

CLIENT a four-branch agricultural equipment dealer — FOCUS Design for the shared device

iOS DevelopmentMobile AppsiOS DevelopmentAgricultural equipmentRepresentative example
Client
a four-branch agricultural equipment dealer
Industry
Agricultural equipment
Engagement
9 weeks — systems pod — engineer + mobile engineer
Service
Mobile Apps / iOS Development
Headline outcome
All four branches on the app, with warranty claims supported by machine-readable inspection records: Paper forms → structured inspections, read from Warranty-claim processing log

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Four branches of an agricultural equipment dealer spread across two hundred kilometres, selling and servicing tractors, harvesters, and implements. Every machine delivered or claimed under warranty generates an inspection, and inspections were paper: a multi-page checklist completed at the machine, photographed, and emailed to the office, where a service administrator retyped the findings into the dealer management system. Technicians move between branches in peak season, and warranty processing is the difference between being paid by the manufacturer and absorbing the cost.

What it was costing

Pre-delivery and warranty inspections lived on paper forms that were photographed, emailed, and retyped — warranty claims waited on office transcription, and disputed inspections had no authoritative record.

What they could see

  • Warranty claims sat for days waiting on office transcription of photographed paper forms.
  • Disputed inspections had no authoritative record, so manufacturer pushback routinely ended with the dealer absorbing the repair.
  • The service administrator's week disappeared into retyping checklists, and photocopies of machine serials were routinely misread.
  • Inspectors could not tell which version of a checklist they were filling in after model-year updates.

The constraints we worked inside

  • Inspection iPads are shared across technicians and branches; per-technician attribution had to survive a shift handover without logging the next person out mid-form.
  • Sheds are metal; connectivity exists in the office, not necessarily at the machine.
  • The dealer management system is on-premise and exposes a nightly import, not an API.

What had been tried before

The parts manager licensed a generic mobile-forms product and rebuilt the two most common checklists in it.
Per-user pricing assumed one user per device; on shared iPads every inspection came out anonymous, and its exports still needed retyping to fit the DMS.
The office tried a photograph-and-retype discipline with a shared mailbox and a naming convention for machine serials.
The mailbox became a second queue; during harvest, forms waited days for transcription, and serials transposed by hand meant claims occasionally described the wrong machine.

What we proposed

We proposed an inspection app for the branch iPads that models the inspection as structured data — checks, measurements, photos, and signatures as records, not fields on paper. A fast user-switch pattern keeps every inspection attributed through shift handovers, everything queues locally with visible sync state for the metal sheds, and a scheduled export produces exactly the import format the on-premise DMS expects each night. Disputes become reconstructable, and transcription disappears instead of moving to a new screen.

Just as important is what we ruled out, and why:

  • Replacing the on-premise DMS with a cloud platformThe DMS anchors parts, service, and accounting across four branches; replacing it to fix inspections would have multiplied the budget and the risk dramatically for one workflow's benefit.
  • Stationary scan stations that digitize completed paper formsScanning arrives after the inspection, so attribution and legibility problems survive intact, and disputed claims would still rest on a photocopy rather than a record.
  • Web forms served from the office networkInspections happen at machines in metal sheds where the office Wi-Fi does not reach; a browser app that dies offline would push technicians straight back to paper.

How the work ran

01Design for the shared device

A fast user-switch pattern with a branch-selected profile keeps each inspection attributed, and the app queues everything locally with a visible sync state.

02Model the inspection as data, not a form

Checks, photos, and measurements are structured records, so the DMS import is deterministic and a disputed claim can be reconstructed exactly.

03Generate the nightly bridge

A scheduled export produces the DMS's expected import format, making the on-premise constraint a timing detail rather than a blocker.

Delivered by the systems pod — engineer + mobile engineer over 9 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Swift
Head office standardizes on iPads and wanted one platform to support; native iOS also gave the best camera and offline behavior for the money.
UIKit
The shared-device user-switch pattern needs precise control over view lifecycles and first-responder behavior that SwiftUI of the era made awkward; UIKit's maturity fits a form-heavy app.
Core Data
The local queue must survive force-quits, battery deaths, and OS updates on devices that live in trucks; Core Data's migrations keep the store upgradeable across app versions.
Swift Concurrency
Background sync, image compression, and export batching are the structured-concurrency cases; task cancellation keeps a shed's worth of queued uploads from fighting each other.
Nightly SFTP bridge
The on-premise DMS exposes a nightly import window and nothing else; meeting its file format on its schedule was cheaper and safer than any bespoke integration.

What went wrong

Obstacle

Within the first fortnight of the pilot, full-resolution machine photos filled the shared iPads — technicians photograph serial plates and hydraulic hoses, and nobody was deleting anything.

Handled: We shipped an emergency release with HEIF capture and automatic purge after successful sync, then set a storage alert per device so the next fill would warn before it happened.

Obstacle

The DMS vendor's import spec turned out to be versioned — the on-premise install's schema revision was undocumented, and records written against the wrong revision were rejected silently at the nightly import; the office learned of it only when warranty claims went missing.

Handled: We negotiated a versioned schema agreement with the vendor, so each export declares the schema revision it targets, and added a pre-import validator plus a morning exception report — the service administrator clears flagged records before the warranty run instead of discovering gaps in it.

How we worked together

Cadence
A Wednesday demo call with the warranty administrator, plus a branch visit every second week to watch inspections happen at actual machines in actual light.
Client side
The service manager sponsored the work; the warranty administrator owned the DMS mapping; two technicians, one per branch pair, ran pilot inspections and fed back weekly.
Decisions
Checklist content belonged to the service manager; technical calls were settled in the demo, and contested items joined the owner's branch-round agenda, where he ruled with the flagged warranty claims in front of him.
They provided
The DMS import specification from the vendor, the four branch iPads, technician time during service gaps, and two seasons of archived paper inspections as test data.

What changed

The headline: all four branches on the app, with warranty claims supported by machine-readable inspection recordsPaper forms → structured inspections, read from Warranty-claim processing log. A second check: inspection-to-claim-submission time at 3 days → same day.

The warranty administrator's job stopped being transcription and became adjudication: she reviews machine-readable inspections with photos attached and prepares claims the same day they are inspected. Technicians stopped defending paper against memory — the record is the record, and manufacturer disputes end with a shared inspection file instead of a standoff. Branch managers can see inspection volume by technician, and checklist updates propagate to all four branches the day a model-year change lands.

The result was read from Warranty-claim processing log against the pre-engagement baseline over the stated window, with a guardrail check on inspection-to-claim-submission time. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

  • App Store Connect access, signing certificates, and provisioning profiles held by head office
  • The SFTP bridge scripts, import validation rules, and morning exception report
  • A per-branch device kit: configured iPads, mounts, and a reset procedure
  • Checklist-authoring documentation so the service team adds model-year checklists without a developer
  • A technician training session recorded for seasonal new hires

What we would do differently

We would have specified photo compression before the pilot — full-resolution machine photos filled the shared iPads within the first fortnight and forced an emergency release.

Mobile AppsiOS DevelopmentAgricultural equipmentSwift

Next case study

A regional wildlife park moved 22,000 members from plastic cards to iPhone Wallet passes