Detect simulated location on iOS without mistaking a signal for a verdict

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.

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.

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.

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.

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.