Owned-app defense · Core Location
Detect simulated location on iOS without mistaking a signal for a verdict
Core Location can provide source information that indicates software simulation or an external accessory. Those fields help an owned app separate a test build from a production decision, protect sensitive actions, and explain diagnostics. They do not identify a person's intent, cover every source of inaccurate data, or prove that a location is genuine. A durable design combines source context with authorization, freshness, accuracy, server state, and a proportionate user response.
Can an iOS app detect a simulated location?
An app can inspect a CLLocation's optional sourceInformation and, when present, read isSimulatedBySoftware and isProducedByAccessory. Use those values as inputs to a documented policy for an app you own. Preserve an explicit test-mode path for authorized builds, handle missing source information, validate timestamps and uncertainty, and choose a response based on the risk of the action. Do not present one Boolean as universal proof, and do not use this guide to probe or defeat another app's controls.
Read what source information actually says
CLLocationSourceInformation describes context attached to a location delivered by Core Location. Apple exposes an isSimulatedBySoftware value for a location generated using on-device software simulation and an isProducedByAccessory value for a location received from an external accessory. The enclosing CLLocation sourceInformation property is optional, so production code must define what it does when the context is absent instead of force-unwrapping it or silently inventing a result.
A true simulation flag is strong evidence that the sample came through that documented source category. A false value is not a certificate of physical presence. Normal sensor error, stale readings, account settings, manual content selections, network-derived regions, compromised application state, and server mistakes remain possible. Likewise, an accessory flag can describe legitimate equipment such as an approved external receiver. Policy must interpret the source in the context of the feature.
- Read sourceInformation from the CLLocation used by the decision.
- Handle true, false, and unavailable context explicitly.
- Keep software simulation and external accessory as distinct states.
- Never translate a false flag into guaranteed real-world presence.
Choose a response that matches the action's risk
For a map preview or regional demo, accepting an authorized simulated sample may be the intended behavior. For a financial, safety, attendance, regulated, or physical-access decision, the app may need to pause the action, request another approved factor, or route the case for review. Avoid a single global rule that blocks every simulated reading across the product. It will break internal QA, App Review demonstrations, customer support reproductions, and legitimate developer workflows without necessarily improving the sensitive control.
Design the user response before implementation. Explain that the app cannot complete this particular action with the current location context, preserve non-sensitive functions where possible, and offer a safe recovery path. Do not accuse the user of fraud from one signal. Log a policy reason code rather than a sensational label, and keep support tools from exposing sensitive detection detail beyond what is necessary to resolve a legitimate case.
- Classify actions by consequence rather than applying one app-wide block.
- Allow documented test builds and approved review accounts.
- Use neutral, recoverable UI instead of an accusation.
- Add another authorized factor when the decision truly requires stronger evidence.
Preserve a first-class path for authorized testing
A defensive check that cannot be tested will eventually fail open, be disabled, or ship with accidental production exceptions. Create an explicit entitlement, signed build configuration, test account, or owned-backend fixture that permits software-simulated input only in the authorized environment. The exception should be observable in logs and impossible to activate through an ordinary remote preference. Avoid secret coordinate lists or permanent device identifiers that are hard to rotate and easy to misuse.
Build unit fixtures for every policy combination, including missing source information, true simulation, external accessory, stale timestamp, poor accuracy, denied permission, and a qualifying normal sample. Then use Xcode's documented location simulation with an owned build to prove that the UI, analytics, backend, and recovery all agree. Test production configuration separately to confirm that debug allowances are absent from the release artifact.
- Authorize the build, account, and backend together.
- Keep test exceptions explicit, signed, logged, and short-lived.
- Cover missing values and combinations instead of only true and false.
- Verify release configuration independently from a successful debug run.
Combine source context with location quality and application state
The source flag answers a different question from timestamp and horizontal accuracy. A simulated sample can be fresh and precise enough for an authorized regression test. A nonsimulated sample can be old, invalid, or too uncertain for a small boundary. Evaluate those dimensions separately, then combine them in a named server or client policy. Keep the app's manual city selection, account address, IP region, and backend market outside the Core Location judgment so disagreements remain diagnosable.
For higher-risk actions, consider transaction history, device and account security, server-side velocity, or another user-approved verification step. Each additional signal has privacy and accessibility costs, so document necessity and retention. Do not collect a continuous location trail merely because the source flag exists. The goal is to make a specific decision safer, not to accumulate data or construct a hidden profile.
- Validate freshness and uncertainty even when the source flag is false.
- Keep device location separate from IP, account, and selected-content state.
- Minimize collection and retain policy outcomes instead of unnecessary trails.
- Review false positives with accessibility, privacy, support, and security owners.
Measure the control without publishing an evasion oracle
Track aggregate outcomes such as policy branch counts, recovery success, support contacts, and confirmed false positives. Restrict raw coordinates and detailed security logs to personnel who need them. A dashboard should distinguish unavailable source information, authorized simulation, unapproved simulation, accessory-produced data, and a general quality rejection. Collapsing all failures into one metric hides both product defects and customer harm.
Review the control when iOS behavior, supported accessories, product risk, or the testing architecture changes. Run an owned red-team exercise against the whole decision flow, but keep it scoped to your application and private environment. The result should improve failure handling and evidence, not become a public catalog of what another service detects. No location-source API eliminates the need for authorization, least privilege, appeal, and human review.
- Measure false positives and successful recovery, not only blocks.
- Separate policy reasons in restricted diagnostics.
- Revalidate after platform, accessory, or risk-model changes.
- Keep security testing inside the owned application boundary.
Defensive source-information decision matrix
These outcomes illustrate policy structure. The owned product's risk assessment should decide whether to allow, step up, or defer each action.
| Location context | What it establishes | Proportionate owned-app response |
|---|---|---|
| Software simulation true, authorized test build | The sample is simulated and the signed test context permits it. | Allow the test, label diagnostics, and verify cleanup. |
| Software simulation true, production action | The documented source category conflicts with the action's policy. | Pause only the sensitive action and offer an approved recovery. |
| Software simulation false | This flag does not identify software simulation for the sample. | Continue other quality and account checks; do not call it proof. |
| Source information unavailable | The app lacks this context for the sample. | Apply the written unavailable-data policy without crashing or guessing. |
| External accessory true | Core Location reports an attached accessory source. | Check whether the accessory is approved for this feature and user. |
| Fresh source, stale or uncertain sample | Source and data quality disagree. | Reject or degrade on freshness or accuracy grounds, not source label. |
| Sensitive action after a source rejection | The user may need a legitimate recovery or appeal. | Preserve safe functions and provide a neutral next step. |
Implement a testable simulated-location policy
Write the decision model first so API fields, build controls, UX, and server evidence all serve the same bounded purpose.
Inventory protected actions
Identify the exact owned-app transactions where location source changes risk; leave unrelated browsing and support flows out of the block.
Define a three-state source model
Represent software simulation, accessory production, and unavailable context without turning false into a guarantee.
Add quality and authorization
Combine source context with timestamp, accuracy, permission, signed build, test account, and backend environment.
Exercise every policy branch
Use constructed locations and Xcode simulation in an owned build, including approved tests, production denial, missing data, and recovery.
Monitor harm and revise
Measure false positives, appeals, support outcomes, and release-configuration integrity while minimizing retained location data.
Frequently asked questions
What does isSimulatedBySoftware mean on iOS?
It means Core Location generated that location using on-device software simulation. It is useful source context for an owned app, but it does not describe the user's intent or prove what every other location-related signal is doing.
Does false mean the location is genuine?
No. It means this Boolean is not reporting software simulation for that sample. The location can still be stale, uncertain, invalid, accessory-produced, inconsistent with account state, or unsuitable for the action.
What if sourceInformation is nil?
Model unavailability as its own state and follow a documented fallback and follow a documented risk-based fallback. Do not crash, assume simulation, or assume physical presence solely because the context is absent.
Should an app block locations from an external accessory?
Only if the owned feature's risk assessment requires it. Apple describes legitimate accessory sources such as external GPS equipment and CarPlay, so an accessory flag should lead to an approval policy rather than a universal accusation.
How can QA test the production restriction?
Use a signed, owned test build and private backend to cover allowed simulation, then independently inspect and run the release configuration to confirm that debug exceptions cannot activate in production.
Is mock location detection enough for attendance or access control?
No single location signal proves identity or presence for a consequential action as proof of identity or presence for a consequential action. Add proportionate approved factors, an accessible fallback, minimal retention, and a review or appeal path.
Sources
- Apple API referenceCLLocationSourceInformationThe source context attached to locations and Apple's example of defensive interpretation.
- Apple API referenceisSimulatedBySoftwareThe Boolean for a location generated through on-device software simulation.
- Apple API referenceisProducedByAccessoryThe distinct Boolean for locations received from an external accessory.
- Apple testing sourceSimulating location in testsApple's authorized paths for fixed, GPX, unit, and UI-test location inputs.