Test the quality of each iPhone location, not just its latitude and longitude

Core Location gives an app a location estimate, not a statement that the device occupies an exact point. The coordinate describes the estimated center. Horizontal accuracy describes the uncertainty around that estimate. The timestamp describes when the location was determined, which can precede the moment your delegate or async sequence receives it. Source information can add context about software simulation or an external accessory. None of those fields should be silently substituted for another.

Start from the feature's tolerance. A state-level content preview can work with much more uncertainty than curbside arrival, a trail warning, or a small geofence. Define the maximum sample age and horizontal uncertainty for each decision, then define a useful fallback when the sample does not qualify. That policy belongs beside the product rule and should be reviewable by engineering, QA, privacy, and support rather than hidden inside an arbitrary global constant.

• Coordinate: the estimated center used by distance or map logic.
• Timestamp: when the system determined the sample, not when the UI rendered it.
• Horizontal accuracy: uncertainty in meters, not a quality percentage.
• Source context: useful diagnostic evidence, never the whole trust decision.

An app can receive an older cached location quickly while the system works toward a newer result. That behavior may be useful for showing provisional content, but it becomes a defect when the provisional result is treated as final or arrives after a newer accepted state and replaces it. Record both the CLLocation timestamp and the app's receipt time. Sort or gate state transitions by the acquisition timestamp rather than assuming delegate order alone proves freshness.

Test cold launch, warm resume, permission restoration, and a new request after the device has moved. In each case, assert which state is provisional, how it is labeled, how long the app waits for a qualifying sample, and what happens on timeout. If a backend request is sent, include a request identifier and sample timestamp so a response for an earlier location cannot repaint the screen after a later request has already succeeded.

• Preserve acquisition time and receipt time as different fields.
• Do not let an older sample replace a newer accepted sample.
• Tie backend responses to the location request that created them.
• Make provisional and final UI states observable in tests.

A hard-coded requirement such as ten meters is rarely correct for every screen. A weather region, nearby-store list, turn instruction, and controlled access workflow have different costs when the estimate is uncertain. Express the threshold in terms of the smallest decision boundary that matters, then leave margin for normal variation. When the reported horizontal accuracy is negative, Apple's API documentation treats the coordinate as invalid; the app should not display it as a verified result.

Test values well inside the acceptable band, exactly at the chosen threshold, just outside it, and far beyond it. Also test a good coordinate with poor accuracy and a slightly different coordinate with good accuracy. Those pairs expose code that accidentally compares latitude digits instead of the uncertainty field. For sensitive decisions, use another authorized signal or require user confirmation rather than presenting the radius as proof of identity or presence.

• Name the feature-specific tolerance and why it is sufficient.
• Cover invalid, boundary, acceptable, and highly uncertain samples.
• Keep UI copy honest when a result is approximate or provisional.
• Avoid converting accuracy into a confidence percentage without a validated model.

Route tests should include more than a smooth sequence of perfect points. Add a repeated sample, a gap, an older point delivered late, a sudden change in uncertainty, and a stop near the relevant boundary. The expected result may be to hold the last accepted state, show a temporary quality warning, or wait for confirmation. What matters is that the behavior is specified before the run and does not depend on the tester's interpretation of a moving map dot.

Keep raw test inputs separate from derived application state. Store the sample sequence, the policy decision for each sample, the business result, and the visible response. This makes a failure explainable: the source fixture may be wrong, the quality gate may have rejected a valid case, the state reducer may have processed events out of order, or the backend may have returned stale regional data.

• Include duplicate and out-of-order samples in a unit fixture.
• Vary uncertainty independently from distance traveled.
• Assert event order, final state, and user-visible explanation.
• Keep server cache and app cache visible during diagnosis.

A successful test does not end when the controlled city or route appears. Stop the simulation or authorized device workflow, request a new location through the same application path, and verify that its timestamp is later than the final fixture. Clear any manual market selection, route state, saved coordinate, or backend test override that could preserve the scenario. The return observation should meet the same age and accuracy policy used during the test.

Capture a compact evidence record: build identifier, device and OS, authorization and precise-location state, fixture name, every accepted sample's timestamp and accuracy, the final product assertion, and the recovery result. Avoid collecting a tester's continuous real-world trail when one public return point or a redacted diagnostic is enough. Good data-quality testing is both reproducible and proportionate.

• End static and route controls explicitly.
• Require a newer normal sample instead of trusting a cleared toggle.
• Remove app, account, and backend test state.
• Retain only the evidence needed to reproduce the decision.