The app's location keeps drifting across the street—is switching phones the only way to test it?

Conclusion: When an app's location point drifts to the other side of the street or lands in a neighboring community, it is usually not a broken phone GPS but a mismatch between the location source and the coordinate system. The raw coordinates provided by the underlying system and the coordinates expected by the map SDK are often not the same set: the former is mostly WGS84, while domestic map rendering commonly uses GCJ02. Without this conversion step, deviations commonly fall between tens of meters and hundreds of meters (experience range). Based on 2026 delivery practice, checking the coordinate system ownership first, then permissions and location accuracy mode, usually converges faster than repeatedly switching phones to test; if the offset direction is fixed and the magnitude is stable, a coordinate system issue is more likely.

1. When location drifts, first tell whether it is a coordinate error or a display error

The location an app receives is not from a single source: the system location service outputs raw coordinates, the map SDK draws the coordinates onto a layer, and the business code decides where to store the point. If any link in the chain uses an inconsistent definition, what the user sees is "I am on this side of the street, but it says I am on the opposite side." So when diagnosing, do not rush to ask whether the phone is accurate; ask whether all three use the same coordinate system.

From experience, deviations can be roughly divided into two types by shape: a whole-point shift of tens to hundreds of meters with a stable direction usually means the coordinate system was not converted; repeated jumping at the same point, sometimes good and sometimes bad, more often points to the location source, accuracy mode, and permission settings. The two types are handled differently, and troubleshooting them together easily leads to changing code back and forth and making things messier.

• Whole-shift type: The location point is offset from the real position by a fixed direction and fixed magnitude, mostly pointing to coordinate system definitions.
• Random-jump type: Repeated drifting at the same location, mostly pointing to location source accuracy and hybrid Wi-Fi/cell tower positioning.
• Regular deviation: Appears only indoors, underground, or in tunnels; it is a signal condition limitation, not necessarily a code problem.

2. Four-stage check: from location source to business endpoint

A relatively stable delivery practice is to split location into four stages and check them in order. Whichever stage has inconsistent definitions is where you converge, avoiding changing the whole chain at once. The benefit of this division is that each stage has clear inputs and outputs, so discussions and acceptance evidence can point to a specific place.

1. Location source and permissions: Confirm whether it uses system location, a third-party location SDK, or hybrid location; whether precise location permission is granted; and whether the accuracy mode is high accuracy or battery saving.
2. Coordinate system ownership: Clarify which coordinate system the underlying layer provides, which one the map SDK requires, and whether conversion happens on the client or server.
3. Map layers and offset: Confirm whether the base map, overlays, and custom markers use the same coordinate system, and whether an additional offset is applied on the layer.
4. Business endpoint and storage: Confirm whether reporting, storage, and backend display use raw coordinates or converted coordinates, to avoid correct display but wrong database records.

Each stage should leave verifiable evidence, such as the raw coordinates returned by the API, the location of the conversion function, and the actual value after database insertion. Judging only by "it looks right" makes it easy for the next person to change it back, and retesting costs become higher.

3. How the three coordinate systems line up: WGS84, GCJ02, BD09

Domestic projects commonly involve three coordinate systems. Understanding their roles is more important than memorizing conversion code. Each has a clear intended use, and mixing them once typically costs a deviation of tens of meters or more. That deviation looks plausible and is easily misjudged as poor signal.

• WGS84: Raw coordinates output by GPS chips and most system location APIs; internationally standard. Placed directly on domestic base maps, it shows a whole-point offset.
• GCJ02: Encrypted coordinates used by most domestic map services, commonly seen in Amap, Tencent, and similar base maps. The offset from WGS84 is non-linear and cannot be handled by simply adding or subtracting a constant.
• BD09: Coordinates used by Baidu Maps, generally offset one more layer on top of GCJ02; reusing across maps requires additional conversion.

To judge whether definitions are consistent, use a known point for cross-validation: on the same phone at the same location, take coordinates once via the system location API and once via the map SDK, and compare the magnitude of the difference. If the difference is more than tens of meters and the direction is fixed, it is basically a coordinate system issue, not a signal issue. This takes about ten minutes during integration and often saves several rounds of rework later.

4. Delivery reality: permissions, accuracy, and battery-saving policy stacked together

A common project situation: the client wants check-in and inspection features to be accurate enough, but the budget and timeline only allow one round of location module work, and testing uses only two or three people clicking inside the same building. Given these constraints, the usual approach is to write precise location permission, accuracy mode, and timeout fallback into the requirements together: request precise location, use high-accuracy mode, and give an understandable prompt when location cannot be obtained, rather than leaving a blank map. The result usually shows up at acceptance: outdoor points fall reliably within a reasonable range, while indoor points are supplemented by manual correction or QR code scanning, reducing post-launch disputes.

The trade-offs should also be stated upfront: high-accuracy location lengthens first-screen waiting, and when users deny precise location, the system may only provide an approximate position, so a fallback path is required. A common rework case is discovering after launch that indoor points deviate greatly, then going back to add manual correction and backend entry. Most such rewrites stem from not writing fallback rules during the requirements stage, not from the technology being impossible. Based on delivery experience ranges, if location integration is patched only after launch, rework time is commonly several times that of doing it once earlier.

5. Approximate vs. precise location: where the effort differs

Whether location capability is worth the investment depends on whether the business truly relies on knowing where the person is. A verifiable comparison is the workload difference between approximate and precise location; the figures here are experience ranges, not fixed quotes.

• Approximate location: Only needs city, district, or nearby content; low permission requirements; development and integration commonly take 0.5–1 person-day; acceptance checks whether fallback is usable.
• Precise location: Needed for check-in, delivery, and on-site services; requires requesting precise location, handling coordinate system conversion, and weak-signal fallback; development and integration commonly take 2–5 person-days; acceptance checks the error range and consistency of coordinates in three places.
• Boundary note: If the business only shows the city or recommends nearby content, approximate location or letting users select a city manually is enough; insisting on precise location actually increases the chance of permission denial.

The person-days here are only typical ranges; actual effort is affected by factors such as the map provider, whether backend geofencing is needed, and whether tracks must be stored. Confirm first whether the business needs precise location, then decide whether to schedule this work. That is more stable than writing code first and adding fallback later.

6. What counts as acceptable location quality

There is no unconditional promise of accurate location, but there can be clear acceptance criteria. A more pragmatic approach is to set error ranges by scenario rather than requiring devices to perform identically in every environment; otherwise acceptance discussions never reach a conclusion.

• Outdoor open scenarios: Deviation from the real position stays within tens of meters (experience range), and repeated readings at the same location are stable.
• Indoor and underground: Larger deviation is allowed, but there must be an accuracy prompt or manual correction entry point so users are not stuck and unable to submit.
• Permission denied or only approximate location: The app does not crash or show a blank screen; it provides next-step guidance, and the business side has an alternative flow.
• Coordinate consistency: Map display, reported data, and backend display show the same point; one cannot be at the roadside and another across the street.

Meeting these points basically means the location module is usable. Conversely, if the map opens and a point can be placed but no one has checked whether the three coordinates are consistent, another round of rework is likely after launch—and by then, incorrect data has often accumulated.

7. Applicable scenarios and boundaries

Whether location capability is worth the investment depends on whether the business truly relies on knowing where the person is, not on whether it is technically possible. A first criterion: would a wrong location directly change the business outcome?

• Suitable for fine-grained location: Attendance check-in, field check-in, same-city delivery, on-site services, and nearby store navigation—in these scenarios, inaccurate location directly causes disputes or dispatch errors.
• Not worth forcing: If a content, news, or utility app only shows the city or recommends nearby content, approximate location or manual city selection is enough; insisting on precise location increases the chance of permission denial.
• Boundaries must be clear: Location accuracy is affected by device, environment, and system policy together; no solution can promise a fixed error in all environments. For indoor scenarios, prioritize alternatives such as manual correction, QR code scanning, or human confirmation rather than forcing error metrics down.

Frequently asked questions

Is a location deviation of tens of meters normal?

In outdoor open environments, a deviation within tens of meters is a typical range; in urban high-rise areas and indoors, deviations are larger. If the offset direction is fixed and the magnitude is stable, it is more likely a coordinate system mismatch than poor signal.

The user has already allowed location, but the position still drifts. What should I check first?

First confirm whether the app gets precise or approximate location, then check whether the coordinate system and map SDK match. Approximate location commonly has deviations on the order of hundreds of meters; this is system policy, not a code defect.

Indoor location keeps jumping—is it because the developer did a poor job?

Not entirely. Indoors lacks GPS signal and relies more on Wi-Fi and cell tower estimation, so jumping is common. The acceptable practice is to indicate limited accuracy and provide a manual correction entry point.

After switching map providers, can the previous coordinates still be used directly?

Not necessarily. Different base maps use different coordinate systems. After switching, confirm whether a conversion layer must be added; otherwise the same point shows a whole-point offset on the new base map, commonly more than tens of meters.

If location issues already affect core flows such as check-in, delivery, and on-site services, it is advisable to write the coordinate system, accuracy mode, and fallback interactions into the acceptance checklist during the requirements stage, and verify them item by item against official documentation and map platform specifications. If the business only shows the city or recommends nearby content, approximate location or manual user selection is sufficient; there is no need to add extra development and compliance costs for precise location. In mobile delivery, we usually list the four-stage location chain check as an acceptance item to facilitate handover and retesting.