Core Location · geofence QA
Test the behavior around a geofence edge, not a perfect line
iPhone geofence testing should prove how an owned app responds before, during, and after a boundary transition. Real location estimates have accuracy and timing, while system monitoring has authorization and lifecycle rules. A strong case therefore uses control points, an ordered crossing, a registered identifier, an expected event window, and a relaunch or recovery check—not a single pin placed exactly on a circle.
How do you test an iPhone geofence boundary?
Register a named condition in a controlled build, begin at a clearly outside point, establish the initial state, cross into a clearly inside point, then exit. Record the condition identifier, accuracy authorization, event state, timestamp, app lifecycle, and resulting product action. Repeat the critical path after backgrounding or relaunch, and remove the condition and simulated movement at teardown.
Build controls on both sides of the boundary
A geofence boundary is a product rule applied to location data, not an infinitely precise tripwire. Start with a point safely outside and a point safely inside, each farther from the edge than the expected uncertainty of the test. Only after those controls work should you add near-edge points. This sequence separates a registration or permission defect from a tolerance decision at the boundary.
Record the center, radius, coordinate precision, and backend ruleset that define the expected result. If the product uses a delivery polygon while Core Location monitors a circular condition, document both shapes and which event is merely a wake-up signal. A system entry event may tell the app to refresh; the backend can still make the final service-area decision using a different geometry.
- Use a far-outside control to prove the initial unsatisfied state.
- Use a far-inside control before testing a narrow edge pair.
- Preserve full coordinates and meters from the defined boundary.
- Name whether iOS or the backend owns the final decision.
Verify registration, limits, and initial state before movement
Apple documents condition monitoring as a shared resource and limits an app to 20 monitored conditions at one time. Test prioritization when the product can have more candidates than the platform limit. The app should select the most relevant set, remove obsolete entries, and expose enough diagnostics to show which identifiers are active without leaking a person's full history.
Do not begin the route until the condition exists and the event stream is being consumed. Capture the monitor name, condition identifier, registration time, and initial state. If the product recreates monitors from saved definitions, test duplicate identifiers and configuration changes deliberately. An enter event with no proof of registration can be a leftover from a prior run rather than evidence for the current build.
- Assert the intended identifier is registered exactly once.
- Test selection and eviction when more than 20 conditions are eligible.
- Remove stale conditions when an account, facility, or ruleset changes.
- Begin consuming events before the controlled crossing.
Exercise lifecycle, relaunch, and post-reboot expectations
Apple says iOS can wake an app when a monitored condition changes. If the app is relaunched, it must recreate the monitor with the same identifier, and monitoring becomes available after the user unlocks following a reboot. Test foreground, background, terminated, and relaunch flows separately because a successful foreground callback does not prove restoration code works.
Keep the expected event window realistic and avoid fixed-second promises that the platform does not make. On relaunch, assert that startup reconstructs the monitor, begins iterating events, processes the event idempotently, and does not present the same notification or business action twice. Store an event ID or transition record in the test backend so UI state is not the only evidence.
- Test a transition while the app is active and while it is backgrounded.
- Verify monitor recreation with the stable identifier after launch.
- Make event processing idempotent across delivery and retry.
- Document the unlock requirement when a reboot is part of the device case.
Cross permission and accuracy states with the route
An allowed location prompt does not guarantee that region monitoring is available. Apple's accuracyAuthorization reference states that reduced accuracy prevents region monitoring and beacon ranging. Include full-accuracy success, reduced-accuracy fallback, denied, restricted, and revocation cases that match the product. Explain the limitation and offer a foreground or manual alternative when the feature can support one.
A developer location can make an authorized edge test repeatable, but it does not override permissions or prove real-world radio behavior. Use Xcode GPX for deterministic ordered crossings in source-controlled tests. Add a physical-device route when notification delivery, suspension, actual accuracy, or customer recovery is important. Never describe either result as proof that every production environment will trigger on an exact meter.
- Assert authorization and accuracy authorization beside every event.
- Keep permission-denied and reduced-accuracy copy actionable and honest.
- Use deterministic simulation for regression order and a device for lifecycle realism.
- Avoid claims of an exact universal trigger distance.
Observe the business action and remove the test condition
The transition is often an input to a larger workflow: refresh availability, schedule a reminder, start a facility check-in, or notify an owned backend. Verify that action once, with the correct account and condition version. Also test suppression when the location estimate oscillates near the edge. Duplicate events must not create duplicate orders, messages, credits, or audit records.
Teardown is part of the acceptance result. Stop the GPX journey or other approved input, remove the test condition, clear queued test actions, and confirm the active-condition inventory no longer contains it. WLOC can retain public targets and recovery notes for a compatible device workflow, but the app's own diagnostic and backend records remain the evidence that Core Location and the product handled the test correctly.
- Correlate the Core Location event with one owned product action.
- Test duplicate suppression near the edge.
- Remove the condition and verify the monitored inventory.
- Return the app, account, and backend to a neutral state.
Geofence edge and lifecycle cases
Use the same named condition while varying one dimension at a time so an event can be traced to its cause.
| Case | Expected observation | Failure it isolates |
|---|---|---|
| Far outside control | Condition is unsatisfied with no business action | Wrong geometry or stale prior event |
| Far inside control | Satisfied state and one expected action | Registration, permission, or event consumption |
| Outside-to-inside crossing | Ordered entry with a fresh timestamp | Route order and boundary handling |
| Inside-to-outside crossing | Ordered exit and correct cleanup action | Missing exit path or stale state |
| Background or relaunch crossing | Monitor recreated and event processed once | Lifecycle restoration and duplicate handling |
| Reduced accuracy | Explained fallback rather than a false success | Accuracy capability and product messaging |
Create a defensible geofence regression case
Tie a small route to one named condition, one product outcome, and a complete cleanup record.
Freeze the definition
Record center, radius, backend shape, identifier, ruleset version, and the owner of the final decision.
Register and inspect
Confirm the intended condition is active, the event stream is consumed, and the app remains within the platform's monitored-condition limit.
Cross in order
Start well outside, move clearly inside, dwell if required, and exit while retaining timestamps and accuracy state.
Repeat the lifecycle case
Run the critical transition in background or relaunch state and verify monitor reconstruction plus idempotent handling.
Remove and neutralize
Stop simulated movement, unregister the test condition, clear the business fixture, and confirm no later event is attributed to it.
Frequently asked questions
Why not place the test point exactly on the geofence line?
Location estimates and tolerances make the exact edge ambiguous. First prove far-outside and far-inside controls, then use a documented edge pair with full precision and expected uncertainty.
How many geographic conditions can an iPhone app monitor?
Apple documents a limit of 20 monitored conditions of any type per app. Test how the product prioritizes and removes candidates when it can exceed that inventory.
Will iOS relaunch my app for a geofence event?
Yes, for documented conditions — Apple describes relaunch behavior for condition changes on iOS, with responsibilities to recreate the monitor and continue consuming events. Test your supported OS and lifecycle path rather than assuming foreground behavior is enough.
Can a location changer prove a production geofence works?
It can be an approved input in a controlled workflow, but it cannot prove permission, accuracy, lifecycle, backend geometry, or another service's behavior by itself. Use owned app and backend evidence.
Sources
- Apple geofencing sourceMonitoring proximity to geographic regionsCondition monitoring, circular boundaries, the 20-condition limit, event iteration, relaunch, and unlock behavior.
- Apple API referenceCLMonitor CircularGeographicConditionThe center-and-radius structure used for a circular geographic condition.
- Apple accuracy sourceCLLocationManager accuracyAuthorizationThe effect of reduced accuracy on region monitoring and beacon ranging.
- Apple analytics sourceCore Location Geofencing analytics reportFirst-party geofencing event and fence-radius fields available in opted-in aggregate analytics.