System model · Evidence · Recovery
Which location signal does WLOC test?
WLOC tests one bounded network-location response path on the device. It does not write to GPS hardware or globally override Core Location. Diagnostics record what the path actually observed—and what remains under iOS and the target app's control.
A test path that can be observed and restored
WLOC normalizes a map link or coordinate to WGS84, keeps the target and route state on-device, and uses a compatible client for a bounded network-location response test. Target writes, requests, response patches, and recovery each produce timestamped evidence. GPS, location permission, app cache, account logic, and server rules remain independent.
Turn real map input into structured coordinates
The parser accepts direct latitude and longitude plus common Apple Maps, Google Maps, Amap, and Baidu links. It extracts a place name and coordinates from URLs, query parameters, or a bounded page response, then returns the source, confidence, original system, and warnings.
input https://maps.google.com/.../@37.795490,-122.393700 output source=google_maps · system=WGS84 · confidence=0.94
- Input length is bounded, and coordinates must stay within latitude ±90 and longitude ±180.
- Short links follow only a limited number of redirects; local, private-network, and cloud-metadata addresses are rejected.
- Unrecognized input returns a clear error instead of inventing a plausible location.
Use one canonical WGS84 model internally
Different maps may expose WGS84, GCJ-02, or BD-09. WLOC preserves the original values and system while normalizing the internal target to WGS84, rounded to six decimal places for reusable favorites, routes, and regression baselines.
original 31.230416, 121.473701 · GCJ-02 canonical 31.xxxxxx, 121.xxxxxx · WGS84
- Amap and some mainland-China map contexts are treated as GCJ-02.
- Baidu inputs are treated as BD-09 and converted through GCJ-02 to WGS84.
- Domestic offset conversion is skipped outside mainland China, and conversion warnings disclose possible meter-level error.
Keep favorites, routes, and profiles on the iPhone by default
WLOC encodes the current target, favorites, routes, device profile, diagnostic events, and settings as JSON, then writes the snapshot atomically to the app's Application Support directory. The app restores from that snapshot without requiring a cloud account.
- Saved places and routes are not uploaded into a searchable coordinate history by default.
- Resetting or uninstalling the app removes the local snapshot; export is user initiated.
- Parsing and conversion requests serve a real-time response, while website analytics are disclosed separately.
Move the target into a supported test path
WLOC prepares official setup resources from the current target and device profile. In a compatible, explicitly authorized environment, the saved target takes priority over the default. With no target, the path remains in pass-through and keeps the real network-location result.
mode=active → saved test target mode=route → current route node mode=passthrough → real network-location result
- This is a network-location test path, not a global write to the GPS receiver or Core Location.
- A static target represents one state; a route advances through nodes, timing, pause, and resume state.
- Whether a target app adopts the result still depends on its permissions, cache, account, and server decisions.
Diagnose the complete path, not a single switch
Diagnostics first checks whether the official Worker is reachable, then checks device setup, current mode, target coordinates, route state, and recorded request and patch times. Those timestamps show what the supported path observed; compare the patch time with the target-write time before treating it as current evidence. Cache and target-app behavior still require a separate manual check.
- The health check returns environment and version so service failure is not mistaken for location failure.
- Device status distinguishes active, route, and passthrough, with timestamps for save, clear, request, and result evidence.
- A running route with no request and an observed request with no confirmed result produce different warnings.
Treat recovery as part of the test, not an afterthought
Stop and clear any active route, then clear the static target. Recovery is verified only when mode is passthrough with no current target or route and fresh pass-through evidence occurs after the clear. The team then reopens the target app and confirms that an old city, geofence, or nearby list is not still coming from cache.
- WLOC can clear its own target and route state, but it cannot force-close another app.
- It cannot clear the system locationd cache on behalf of iOS.
- Complete evidence includes both the test state and the restored real-location state.
Privacy and security boundaries
Technical transparency includes where data goes, which requests leave the device, and which capabilities are intentionally not offered.
- Favorites, routes, device profile, and diagnostic snapshot stay in the app's on-device directory by default.
- The official Worker handles parsing, conversion, health, and setup generation without building a searchable plaintext coordinate history by default.
- WLOC may separately send coarse first-party product events as described in the Privacy Policy; those events exclude exact coordinates and raw map links.
- External map-link parsing bounds redirect depth and blocks local, private-network, and metadata addresses.
- WLOC does not promise to bypass app permissions, anti-abuse controls, service terms, or legal restrictions.
Why a coordinate-system mismatch can look like a failed test
The same landmark can appear visibly offset in different coordinate systems. WLOC keeps both original and canonical values so a team can distinguish input, conversion, basemap, and target-app issues.
| System | Common source | WLOC handling |
|---|---|---|
| WGS84 | GPS, global Google coordinates, generic latitude/longitude | Stored directly as the canonical internal coordinate. |
| GCJ-02 | Amap and common mainland-China map data | Converted to WGS84 inside mainland China while preserving the original value. |
| BD-09 | Baidu Maps | Converted to GCJ-02, then to WGS84. |
Why two apps can still report different outcomes
Apple documents that iPhone location can combine GPS, Wi-Fi, cellular, and Bluetooth, while each app controls its own permission. WLOC only claims the layer it can prepare, observe, and verify.
| Influence | What you may see | How to verify |
|---|---|---|
| GPS and sensor fusion | Strong outdoor GPS can make the final location differ from a network test result. | Compare low-risk indoor and outdoor runs, with timestamps and diagnostics. |
| iOS permission and precision | Denied, one-time, or approximate access changes target-app behavior. | Confirm that app's Location Services setting, then repeat the same test. |
| Target-app cache | The screen still shows an old city, geofence, or nearby list. | Fully reopen the target app and compare request time with backend evidence. |
| Account and server rules | The same coordinate returns different content or risk state for two test accounts. | Record account, environment, and expected result; never mix with production identity. |
| IP and regional configuration | A content region follows the network exit rather than the coordinate. | Test IP region and coordinate separately instead of treating them as one switch. |
How to read diagnostic status
A recorded patch timestamp proves that a compatible network-location response was modified at that time. Compare it with the target-write timestamp; it does not automatically prove the current target was patched or that the target app accepted that signal.
| Influence | What you may see | How to verify |
|---|---|---|
| Green | Path confirmed | Service, device setup, request, and result have enough evidence. Still verify the business state inside the target app. |
| Yellow | Partially confirmed | Common while waiting for the first request, route trigger, cache refresh, or under strong GPS influence. |
| Red | Foundation failed | Fix service reachability or device setup before continuing; repeated tapping will not repair the root cause. |
Does this technical model fit your use case?
Classify the test before downloading. That reduces low-fit installs and helps real location-QA teams reach proof faster.
| Influence | What you may see | How to verify |
|---|---|---|
| Good fit | Owned apps, test accounts, staging, review demos, route QA, and regional-content validation. | Start with a public low-risk point |
| Needs validation | Third-party apps, complex cache, strong GPS, or mixed IP-and-coordinate logic. | Run diagnostics and rehearse recovery first |
| Not supported | Fake attendance, social deception, game cheating, evading controls, or universal all-app override claims. | Do not use in an unauthorized environment |
Three paths, one verifiable test
Input
Map link or coordinates
Parse
Source and original system
Normalize
Canonical WGS84
Prepare
Supported test setup
Verify
Request, result, route state
Restore
Clear route and target; verify pass-through
Understand the model, then start with a low-risk test
Open WLOC, choose one public point, save the target, run diagnostics, and complete one recovery cycle. A path is trustworthy only when both the test and the restore are repeatable.
Frequently asked questions
Does WLOC directly change the iPhone GPS hardware?
No. WLOC works with a supported network-location test path. It does not write to the GPS receiver or globally override Core Location.
Why can a map show the target while another app still shows the real place?
The target app may use strong GPS, cache, different permission, IP region, account rules, or server checks. Compare its evidence with the WLOC diagnostic timeline.
What is the difference between WGS84, GCJ-02, and BD-09?
They are different coordinate representations. WLOC preserves the original coordinate and normalizes the internal target to WGS84, with a meter-level warning for mainland-China conversions.
What data stays on the iPhone by default?
The current target, favorites, routes, device profile, diagnostic events, and settings are stored as a JSON snapshot in the app's Application Support directory.
How do I prove normal location is restored?
Stop and clear any active route, clear the static target, confirm passthrough mode with no current target or route, and wait for fresh pass-through evidence after the clear. Then reopen the target app and compare old cache with the real-location state.