Why your mileage app keeps missing trips

The five specific failure modes

1. The operating system suspended the app

This is the big one. Modern iOS and Android do not let an app run indefinitely in the background just because it asked to. An app that holds a continuous, high-accuracy location session burns battery visibly, and both platforms have escalating countermeasures: iOS suspends and terminates background sessions under memory pressure, and Android's battery optimisation, Doze mode and manufacturer-specific "app killers" (particularly aggressive on some Android skins) shut down background work on a schedule you never see.

The technical answer is not to poll harder. It is to use significant-location-change and motion-activity APIs, which the operating system is designed to deliver even to a suspended app, and geofences that wake the app when the vehicle actually starts moving. This uses a fraction of the power, which is precisely why the OS lets it survive.

2. The app started late

Even a well-behaved tracker takes some distance to decide that motion is driving rather than walking, cycling or riding in someone else's car. If it needs half a mile to be sure, every trip is half a mile short. Over 400 trips a year that is 200 miles — small individually, invisible in the total, and entirely avoidable if the app back-fills the start of the trip from the location history it already has rather than beginning at the moment of certainty.

3. You forgot to press start

Any app with a manual start button will lose miles, and it will lose them non-randomly. You forget on the nights you are rushed, and the nights you are rushed are the nights you drive most. A driver who is diligent 90 percent of the time is not losing 10 percent of miles; they are losing a bigger share, because the missed shifts skew long.

4. The trip was recorded but classified wrong

This is a different failure with the same result: the miles are in the app, but they are sitting in the personal bucket and never make it into the deduction. Any app that defaults ambiguous trips to personal will quietly undercount. Any app that defaults them to business creates a different and worse problem, because now the log overstates. The correct behaviour is to leave them unclassified and make the user decide, and to make deciding take one swipe.

5. The phone was off, dead, or on the wrong device

Multi-phone drivers, drivers whose battery dies mid-shift, drivers who use a work phone for platforms and a personal phone for everything else. This is not the app's fault, but a good tracker should make the hole obvious rather than hiding it — a log that shows a five-hour gap on a day you worked is fixable; one that silently reports a total is not.

How to measure your own app's capture rate

This takes two photographs and one subtraction, and it is the single most useful thing a driver can do this month.

1. Photograph your odometer at the start of a week. The photo carries a date; that matters.
2. Drive the week normally. Do not change your habits, do not baby the app. You are measuring reality.
3. Photograph the odometer again at the end of the week.
4. Subtract. That difference is every mile the car moved — business and personal together.
5. Open your tracker and total the same seven days, including personal trips, and compare.

Why the category does not talk about this

Search any major mileage app's help centre and you will find an article about missed trips. The existence of that article across every vendor in the category is the tell: this is a known, universal problem, handled as a support issue rather than a product claim. No competitor markets against it, because no competitor wants to draw attention to a number they would then have to publish.

That is the gap MileTruth is built into. Capture rate is the app's primary engineering KPI rather than a support topic, and the design consequence is specific: motion-activity and geofence wake-ups instead of continuous polling, back-filled trip starts, unclassified-by-default trips, and a visible tracking-health indicator so a driver can see that the app is alive rather than assuming it.

What to do right now, whatever app you use

• Set location permission to "Always." "While Using the App" will not capture a trip that starts while your phone is in your pocket and the app is closed. Both platforms require a deliberate escalation to Always, and many drivers never complete it.
• Exempt the app from battery optimisation on Android. Settings → Apps → your tracker → Battery → Unrestricted. On some manufacturer skins this lives under a separate "protected apps" or "auto-launch" list, and the default is off.
• Stop swiping the app away from the recents list. On both platforms that terminates its background work.
• Turn off any aggressive battery saver during shifts. Low Power Mode on iOS and Battery Saver on Android both throttle background location.
• Run the odometer check monthly. It takes two minutes and it is the only honest audit available to you.
• Keep your platform trip histories. They are independent evidence of where you were, and they let you find and reconstruct the gaps your app missed.

The connection to 2026's two rates

There is a version of this problem that is new this year. Because 2026 has two business mileage rates split at June 30, a log with gaps is no longer just short — it can be short in a way that lands on the wrong side of the boundary. If your tracker lost a week in July and you reconstruct it from memory in April, you have to know it was July, not June, or you apply 72.5 cents to miles worth 76 cents.

Dates were always required by Publication 463. In 2026 they became load-bearing. See the two-rate explainer and what to do if you did not track your miles.

Questions and answers