Compatible apps · WPS technical guide
Which VPN apps does WLOC need—and why?
WLOC itself is not a VPN. Coordinate management works independently. A network-location response test additionally needs one compatible iOS network client to provide the local tunnel, host-scoped HTTPS inspection, and script runtime.
The short answer: install one compatible client
Choose Shadowrocket, Surge 5, Quantumult X, Loon, Stash, or Egern; you do not need all six. WLOC manages target coordinates, setup profiles, status bridging, diagnostics, and recovery. The third-party client puts the matching rules into the iOS network path. Each client is independently supplied by its developer; WLOC does not sell, bundle, or imply endorsement by Apple or those vendors.
Core Location is multi-source fusion, not one GPS switch
Apple's current support documentation says Location Services can use cellular, Wi-Fi, GPS, and Bluetooth, and that devices augment a crowd-sourced Wi-Fi hotspot and cell-tower database. Network location is therefore only one input into a final result.
- Strong outdoor GPS, Bluetooth beacons, app permission, and Precise Location can change the final result.
- A target app may add cache, IP region, account state, and server-side risk decisions.
- A successful patch does not mean every app must display the target.
BSSIDs act as landmarks; the service returns coordinates for on-device computation
A 2024 IEEE S&P paper reports an experimental Apple WPS model in which a device submits nearby Wi-Fi access-point BSSIDs, receives coordinates for those and nearby landmarks, and computes or caches the result locally. Apple's archived 2010 letter also described devices receiving known nearby cell-tower and Wi-Fi access-point locations and combining them with GPS when available.
- A BSSID identifies a Wi-Fi access point radio interface; it is not the network name or SSID.
- The 2010 letter is historical disclosure, not a complete or immutable 2026 private-protocol specification.
- The paper also documents serious privacy and mass-collection risks around Wi-Fi location databases.
Patch compatible coordinate records when a target exists; pass through when it does not
WLOC's response script recognizes compatible Wi-Fi, cell, and location records inside an Apple WPS binary response, then replaces latitude, longitude, and accuracy fields with the current target or route node. Clearing the target stops replacement and leaves the response untouched.
- An independent experiments repository presents /clls/wloc, protobuf framing, and Wi-Fi or cell queries as reverse-engineering findings.
- That endpoint is not an Apple public API promised stable for third-party use; fields and behavior may change without notice.
- WLOC cannot change satellite signals, clear the system locationd cache, or override a target app's server decisions.
Why CA trust is required—and why it is sensitive
Apple WPS traffic uses HTTPS. To inspect and change that response on-device, the compatible client must decrypt HTTPS for the scoped hosts, which requires generating a local CA, installing its profile, and manually granting full trust in iOS. That is a high-privilege operation, not a risk-free switch.
- Use only on devices, accounts, apps, and networks you own or have explicit permission to test.
- Keep the hostname scope to gs-loc.apple.com and gs-loc-cn.apple.com; never enable catch-all decryption for convenience.
- Do not install an unknown certificate, share the CA private key, or retain it on a primary device carrying sensitive production accounts.
- After testing, clear the WLOC target, disable the profile and HTTPS inspection, revoke system trust, and remove the certificate or VPN configuration when no longer needed.
- WLOC does not install or remove a third-party client's CA and cannot audit how that client handles other traffic.
Before-you-start checklist
- Confirm that the device, network, app, and account are yours or explicitly authorized for testing.
- Choose one compatible client and obtain it from its official App Store listing.
- Use a public, low-risk point for the first static-target run in WLOC.
- Limit certificate inspection to the two Apple WPS hosts and record how to revoke it.
- Verify one active state, one passthrough state, and real location after reopening the target app.
Sources, separated by what they can prove
These sources answer different questions. Current Apple documentation defines the public boundary; the archived letter and paper explain the model's evolution; GitHub is independent experimental evidence only.
The word “VPN” here does not automatically mean changing IP
These clients commonly use the iOS VPN or Network Extension path to process local rules, so iOS may show a VPN indicator. That does not mean WLOC sends all traffic to a remote VPN server.
| Component | What it does | What it does not do |
|---|---|---|
| WLOC | Stores targets, generates matching profiles, triggers the status bridge, and presents diagnostics and recovery. | Does not create a VPN tunnel, change public IP, install a CA, or write GPS hardware. |
| Compatible network client | Creates the local network path, loads rules, and runs host-scoped HTTPS inspection and response scripts. | Is not part of WLOC; its permissions, pricing, privacy, and runtime state belong to its vendor. |
| Remote VPN or proxy service | If separately configured, may change the network exit IP or transport path. | Is not required by WLOC, and IP region is not the same switch as a coordinate target. |
Match each symptom to the layer that can cause it
Separating client, certificate, rule, WPS response, and target-app failures is more useful than repeatedly toggling everything.
| Symptom | Likely layer | Next check |
|---|---|---|
| No VPN indicator or the client is disconnected | The local network path is not running. | Check the selected client's connection, active profile, and iOS VPN permission. |
| The HTTP status bridge works but HTTPS says Not found | The profile loaded, but HTTPS decryption, CA trust, or hostname scope is inactive. | Check the client switch, full system certificate trust, and the two scoped hosts. |
| No /clls/wloc request is observed | The rule missed, a resource is stale, the host bypasses the client, or the scenario did not trigger WPS. | Refresh the profile, inspect bypass rules, then trigger a low-risk map lookup. |
| The patch succeeds but the target app stays real | GPS, permission, cache, IP, account, or server rules dominate the network-location result. | Review target-app permission and timing, reopen the app, and test IP separately from coordinates. |
| The target is cleared but an app shows the old place | The target app or iOS still has cached state. | Confirm passthrough and fully reopen the target app; WLOC cannot clear locationd for iOS. |
Sources, separated by what they can prove
These sources answer different questions. Current Apple documentation defines the public boundary; the archived letter and paper explain the model's evolution; GitHub is independent experimental evidence only.
| Symptom | Likely layer | Next check |
|---|---|---|
| Current primary source | Apple: About privacy and Location Services (May 25, 2026) | https://support.apple.com/en-us/102515 |
| Current troubleshooting source | Apple: If Maps isn't working on your Apple device (May 15, 2026) | https://support.apple.com/en-us/108924 |
| Historical primary source | Apple response to Representatives Markey and Barton (July 12, 2010, archived) | https://web.archive.org/web/20101208141602/https://markey.house.gov/docs/applemarkeybarton7-12-10.pdf |
| Peer-reviewed research | Rye and Levin: Surveilling the Masses with Wi-Fi-Based Positioning Systems (IEEE S&P 2024) | https://www.cs.umd.edu/~dml/papers/wifi-surveillance-sp24.pdf |
| Independent reverse engineering | acheong08/apple-corelocation-experiments on GitHub | https://github.com/acheong08/apple-corelocation-experiments |
Six steps from a target coordinate to a network-location result
Save target
WLOC stores a WGS84 coordinate on-device
Import profile
The client loads its matching format
Start network path
iOS may show a VPN indicator
Scope HTTPS
Inspect only the Apple WPS hosts
Handle response
Patch coordinate fields in compatible records
Verify and restore
Check the target app, then clear to passthrough
Choose one compatible client, then start with a low-risk test you can reverse
Install WLOC, choose a public point, follow the in-app steps for your selected client, and complete one save, diagnose, clear, and certificate-revocation cycle.
Frequently asked questions
Is WLOC itself a VPN?
No. WLOC manages coordinates, profiles, diagnostics, and recovery. A compatible third-party client creates the iOS network path.
Do I need Shadowrocket, Surge, Quantumult X, and every other listed app?
No. Choose one currently supported client and use its matching wloc.module, wloc.sgmodule, wloc.conf, wloc.lpx, or wloc.stoverride output.
Do I need a remote VPN or proxy subscription?
WLOC itself does not require a remote VPN subscription. The selected client may have its own purchase, feature, or service terms; WLOC needs its on-device rule loading, scoped HTTPS inspection, and script runtime.
Why does iPhone show a VPN icon?
A compatible client may process local rule traffic through the iOS VPN or Network Extension path. The icon shows that a network path is active; it does not prove that the WPS rule, certificate, or patch succeeded.
Does the VPN icon mean my public IP location changed?
Not necessarily. WLOC provides no remote network exit and does not change IP. Only a separately configured remote service might affect public IP.
Why must I trust a certificate?
The target response is HTTPS. Inspecting and changing that encrypted response for scoped hosts requires a local CA and system trust. This is sensitive access: restrict the hosts, use a test device, and revoke it after testing.
Which map links and coordinate input does WLOC support?
WLOC supports Apple Maps, Google Maps, Amap, and Baidu links plus direct latitude-longitude text. It identifies the source coordinate system and normalizes the internal target to WGS84.
Why does Maps stay unchanged on iOS 26 or iOS 27 after the log says patched?
First confirm that both the latest WLOC request and patch timestamps changed. A VPN icon or status bridge alone is not proof, and restarting cannot repair an inactive profile, certificate, or rule. If the patch is confirmed, refresh the target-app permission and reopen it; restart the authorized test device only if stale state remains. Apple does not publish a WLOC-specific iOS 26/27 cache or mandatory-restart rule, so this is troubleshooting guidance, not a version guarantee.
How do I cancel the test target and restore real location?
Stop and clear any active route, use WLOC's restore action to remove wloc_settings, and confirm passthrough. The current official profile does not use 113.94114, 22.544577 as a pass-through sentinel; a valid fallback coordinate in module arguments or a running route can keep replacement active.
Will this make every app show the same location?
No guarantee. GPS, Bluetooth, cellular, permission, cache, IP, account, and server rules still matter, and some apps may not use this network-location result at all.
How do I remove the complete setup?
Clear the WLOC target and confirm passthrough; disable or remove the client profile and HTTPS inspection; revoke and delete its CA profile; remove the VPN configuration if no longer needed; then reopen the target app and verify real location.