iOS 虚拟定位工具：从 RSD 隧道到 DVT 注入

This tool does something simple: move an iPhone / iPad's location anywhere on the map, or make the device follow a drawn route at realistic speeds. It supports iOS 17 – iOS 27.2, with desktop builds for both macOS and Windows.

What looks like a native desktop app is actually a local web app: Python's standard library runs an HTTP server, the browser opens 127.0.0.1:8787 in a Chrome / Edge app window, and the map, routing, playback engine and device communication all run locally.

1. Why iOS 17+ requires a tunnel first

Before iOS 16, usbmux was enough for location simulation. Starting with iOS 17, Apple switched to an RSD (Remote Service Discovery) tunnel: the device exposes a single tunnel, and the DVT session for location simulation must run over it.

The project reuses Apple's own remoted tunnel — calling pymobiledevice3 remote start-tunnel --native --script-mode, then connecting DVT with the returned HOST PORT. Since the packaged app has no external Python, it uses self-invocation: the app binary launches itself again with a tunnel-helper argument to establish the tunnel.

The tunnel must stay alive: once the DVT session drops, the virtual location stops working immediately. That is also why the playback engine cannot reconnect for every point.

2. The actual injection point: DVT's LocationSimulation

Once the tunnel is up, connect to com.apple.instruments.dtservicehub and call LocationSimulation.set(lat, lon) to write coordinates, and clear() to restore the real location. This is exactly the channel Xcode's own location simulation uses, so no jailbreak or device modification is needed.

The cost: DVT can only set two parameters — latitude and longitude. horizontalAccuracy, altitude, floor, barometer and pedometer data cannot be injected through this channel; they are synthesized by iOS or produced directly by hardware. This is a shared boundary of every tool in this category.

3. Route playback engine

The playback engine advances by arc-length integration: the polyline route is parameterized by cumulative distance, the engine moves forward by the current speed each frame, then inverts back to coordinates. Speed is not constant — a speed profile is generated from turn angles (slow down in sharp corners, accelerate on straights) and then smoothed, so acceleration looks continuous.

The sending side keeps exactly one request in flight on a dedicated thread: the next point is sent only after the previous one is acknowledged, guaranteeing strict ordering without async callback reordering. The playback multiplier only affects progress rate, not the actual send frequency.

4. Making the track “look real”

Real GPS error doesn't jump randomly; it drifts smoothly with inertia. The tool uses multi-octave value noise for drift: three correlation lengths (120 m slow, 30 m medium, 15 m fast) are stacked to approximate the power spectrum of real GPS error, normalized to the configured radius and clipped at 1.8x, keeping it continuous without random jumps.

5. Coordinate systems: WGS84 and GCJ-02

All coordinates internally use WGS84. But AMap tiles are in GCJ-02; if you convert only the tiles and not the marker, the map point and the device's actual position will be about 500 metres apart. So the frontend applies the same conversion both when requesting tiles and when placing markers, keeping the two aligned.

6. Maps and tile caching

Tiles are proxied by the local server and cached to disk (default cap 1 GB, LRU eviction), so already-viewed areas still render offline. Some tile providers return fully transparent “empty tiles” when they have no data; the code detects and discards them so the cache doesn't fill with garbage. Routing prefers OSRM's real road network and falls back to a straight line offline, labelling the engine type on the map.

7. Windows port: no admin rights, no Wintun

The focus of this Windows release (v1.1.1) was replacing the macOS tunnel logic with a pure-Python userspace implementation:

• No administrator rights required, and no dependency on virtual network adapter drivers such as Wintun;
• On first launch it detects and installs Apple Mobile Device Support automatically, guiding the install when a dependency is missing;
• Runs an environment self-check at startup (driver, service, library versions) and explains problems directly in the window;
• Packaged with PyInstaller onedir plus an ad-hoc signature; the tunnel is established via the <app> tunnel-helper self-invocation, so the target machine doesn't need Python installed.

Build outputs are dist\iOSLocationTrack\iOSLocationTrack.exe and the installer iOSLocationTrack-1.1.1_win-setup.exe, plus an optional portable ZIP.

8. Known boundaries

• DVT can only inject latitude / longitude; altitude, barometer and pedometer data cannot be faked;
• An iOS 17+ device has only one RSD connection at a time; tools like i4Tools and Xcode will compete with it;
• Some apps use their own location channel or server-side trajectory validation, so the virtual location may be ignored or detected.

This tool is intended only for testing location features of your own app, route regression and demos. Do not use it to fake attendance or deceive others.

Repository: git.jbjflab.top/admin/ios-location-track (Python / JavaScript, with Windows and macOS docs, tutorials and tests).