Battery Optimisation for Field Service Apps: Measure the Work

Battery optimisation for field service apps should start with the work the phone is doing, rather than a promise to add hours between charges. Apple's energy profiling guidance distinguishes legitimate energy use from unexpected activity, so a busy period is not automatically a defect. We recommend measuring a representative field task and checking that the same useful work still completes after any change.

Establish which activity uses energy

Apple describes profiling CPU activity, network activity and screen brightness together when investigating energy use. For a field app, we would turn that into a repeatable scenario: open an assigned inspection, enter observations, capture a photograph and submit the result. Include the quiet period after submission, because the question is also whether work stops when the task ends. Treat this as a proposed test procedure, not a claim about the behaviour of an app we have not measured.

Record the device model, operating system, app version, screen brightness and network conditions alongside the trace. Repeat the same scenario before and after the change, keeping those conditions as consistent as practicable. This follows David Farley's experimental approach in chapter 8 of Modern Software Engineering, which connects useful measurement with control over the variables being tested. Do not turn one successful run into a universal battery-life claim.

Request only the location the task needs

Apple explains that unnecessary location use can keep hardware active and prevent sleep. Its guidance also says that requesting more accuracy than necessary powers additional hardware, wasting energy on precision the app does not need. Start by specifying what location evidence the field task actually requires, rather than leaving every workflow on the most precise setting.

An arrival check and continuous route recording should be separate requirements in that specification. For a hypothetical inspection that needs a location only when the record is created, evaluate a single request rather than tracking throughout the visit. Apple documents a single-location request that stops location services after fulfilment, allowing hardware to power down if nothing else is using it.

Our acceptance test would check the required accuracy and when location collection ends, including after the user leaves the task. Do not lower accuracy simply to improve a battery chart if it no longer meets the agreed purpose of the record. That is a proposed acceptance rule, not a claim that a location fix proves attendance or compliance.

Transfer less, without concealing unfinished work

Apple's networking guidance recommends batching transactions, caching infrequently updated data and avoiding repeated downloads of unchanged content. We would first inspect whether opening each job fetches the same reference material again, then test reuse where the freshness requirement permits it. Write down when that material must be refreshed before treating a cached copy as suitable for the next inspection.

The same guide explains that smaller media files reduce the data sent and received. For photographs, our recommendation is to test a smaller upload against the detail the receiving person actually needs to inspect. Do not discard the required detail merely because the upload finishes sooner. Keep the decision tied to the evidence requirement, not an arbitrary image-size target.

Apple also advises resuming interrupted transfers, setting timeouts and avoiding network attempts when connectivity is unavailable. Test a transfer through lost signal and reconnection, checking both whether it finishes and whether the same content is sent unnecessarily again. If uploads are deferred or grouped, we recommend showing users what is still waiting rather than presenting delayed work as complete. Those are acceptance checks for the proposed optimisation, not evidence that every mobile transfer supports resumption automatically.

Allow background work to wait when the task permits

Android's background execution guidance describes operating-system limits intended to protect battery life, including restrictions while devices are idle. It explains how WorkManager can schedule deferred tasks with constraints such as charging or network availability, while respecting power-management features. A scheduled task is therefore not a promise that the work starts at the exact requested moment.

For a hypothetical maintenance upload, we would evaluate waiting for suitable connectivity or charging rather than requiring immediate execution. For a time-sensitive operational action, agree the acceptable delay before applying that policy. Keep immediate user work and deferrable maintenance distinct in the test plan, following Android's distinction between background use cases. Do not ask users to defeat battery controls as the default response to an unexplained delay.

Accept the change against the field task

Farley's chapter on being experimental supports a sequence of controlled, measured changes rather than conclusions drawn from an uncontrolled comparison. Our recommendation is to change one behaviour, repeat the representative task and retain the before-and-after evidence. Alongside the energy trace, check the agreed location quality, transfer completion and any delay introduced by deferred work. Accept the change only when those requirements still hold, rather than awarding success to a lower energy reading alone.

For the next battery investigation, we would ask for a reproducible task, a trace showing the activity under suspicion and a written limit on the behaviour that may change. That is a practical starting point for finding unnecessary work without promising a saving before the measurement exists.

Update, October 2026

Our later engineering article on workload-shaped benchmarking uses a real processing workload to examine performance rather than relying on a single isolated request. We recommend the same discipline here: assess the field task that matters, while keeping those inference results separate from any claim about mobile battery savings.

Sources

• Apple, "Measure Energy Impact with Instruments", archived guide updated 13 September 2016.
• Apple, "Reduce Location Accuracy and Duration", archived guide updated 13 September 2016.
• Apple, "Minimize Networking", archived guide updated 13 September 2016.
• Android Developers, "Modern background execution in Android", 16 October 2018.
• David Farley, "Modern Software Engineering", first edition, chapter 8, "Being Experimental", published 16 November 2021.