Every ride I import into HealthKit from a Chinese bike computer renders wrong at the start in the Fitness and Health apps, and the same record is wrong on iOS 26 as well as on iOS 27.2 (iPhone 15 Pro, mainland China, AutoNavi base map). Filed as FB25306175. WHAT HAPPENS The first ~49 samples of an HKWorkoutRoute are drawn about 415 m east and 222 m south of the coordinates actually stored, and a straight line joins that piece back to the rest of the track. The green start marker is on the displaced piece. Every remaining sample, and the red end marker, are drawn exactly where stored. On this record (2794 points, 1 Hz, 17649 m drawn) the displaced block is the first 209 m of riding — about 53 seconds The displacement is one more application of the local WGS-84 → GCJ-02 transform, which these coordinates already contain: measured from screenshots at native 1179×2556, 417 m E / 219 m S on the full-screen map and 418 m E / 220 m S on the summary map, against a true local offset of 415.2 m E / 222.4 m S. THE STORED DATA IS CORRECT HKWorkoutRouteQuery returns all 2794 CLLocation values unchanged; the descriptor query returns the same count and the same first/last values. One workout, one route. The same coordinates drawn with SwiftUI Map + MapPolyline on the same phone render correctly end to end, including the start. The same unchanged workout, opened twice with no write in between, was correct the first time and offset after leaving and re-entering. So the data is not the variable. THE WRITE PATH The head unit writes GCJ-02 into record.position_lat / position_long. That is what makes the track land on the road here: MKMapSnapshotter on the mainland base map puts the GCJ-02 values exactly on two known intersections, and the WGS-84 values about 470 m north-west of them, and MapKit does no conversion for us. So they are written verbatim: let config = HKWorkoutConfiguration() config.activityType = .cycling config.locationType = .outdoor let builder = HKWorkoutBuilder(healthStore: store, configuration: config, device: nil) try await builder.beginCollection(at: firstPoint.timestamp.addingTimeInterval(-1)) // CLLocation per record, coordinates as recorded, horizontalAccuracy 10, // verticalAccuracy 10 (or -1 where the record has no altitude), recorded altitude // and speed, course computed from the previous point. let routeBuilder = builder.seriesBuilder(for: HKSeriesType.workoutRoute()) as? HKWorkoutRouteBuilder for batch in locations.chunked(into: 1000) { try await routeBuilder?.insertRouteData(batch) } try await builder.endCollection(at: lastPoint.timestamp.addingTimeInterval(10)) let workout = await builder.finishWorkout()WHAT IS NOT THE CAUSE Established with controlled synthetic routes written from the same start point: probe sample interval m per point displaced length displaced time samples E 1 s 10 ~480 m ~48 s ~49 F 2 s 10 ~480 m ~96 s ~49 G 1 s 20 ~950 m ~48 s ~49 The block follows SAMPLE COUNT, not time and not distance. Also ruled out, each by writing a variant: lap and pause/resume events (present, absent, and a 206-point probe carrying all three); the first point's metadata (altitude 0 / course -1 / verticalAccuracy -1); valid versus -1 values for horizontalAccuracy, verticalAccuracy, speed and course; dropping an isolated leading point; back-dating the first timestamp to the workout start; trimming the leading 200 m (the offset simply re-appears at the new start, which still begins with 49 samples). Writing WGS-84 instead inverts the symptom — the leading block then looks right and everything else goes ~470 m north-west — which is what you would expect if only the leading block is converted a second time. SCOPE This is not my one file. Three separate real rides, two cities, two head units, plus synthetic routes, all behave identically: MAGENE C706_54634 Suzhou 2026-10-23 17.61 km 2797 records / 2794 stored points MAGENE C706_54634 Suzhou 2026-10-22 12.66 km 2076 records MAGENE C606P_33206 Chengdu 2026-10-20 63.30 km 12069 records Apple Watch recordings made in mainland China render correctly, and a Garmin Edge 1050 file recorded in the US imported through the same code path renders correctly. The common factor is coordinates that are already GCJ-02 when they reach HKWorkoutRouteBuilder — which is every Chinese bike computer, every Chinese running app, and every GPX export from a Chinese service. So any third-party importer here hits this. WHAT I AM ASKING Does the workout map apply a datum conversion to a leading block of route samples, and is that block size fixed? What is the official coordinate contract for HKWorkoutRoute locations for apps working with GCJ-02 data in mainland China? Is there a supported way to opt out, and what decides whether a given route enters this state? Which component owns the conversion — Health/Fitness route rendering or MapKit? I am deliberately not pre-converting the first ~49 points: that would store mixed datums in HealthKit, wrong for the Health app itself, for exports, for every third-party reader, and wrong for all of them the moment this is fixed. Happy to share the one-tap sample project, the exported JSON with all 2794 stored CLLocation values, the original .fit, and the probe E/F/G screenshots — reply here and I'll attach them.

Every ride I import into HealthKit from a Chinese bike computer renders wrong at the start in the Fitness and Health apps, and the same record is wrong on iOS 26 as well as on iOS 27.2 (iPhone 15 Pro, mainland China, AutoNavi base map). Filed as FB25306175. WHAT HAPPENS The first ~49 samples of an HKWorkoutRoute are drawn about 415 m east and 222 m south of the coordinates actually stored, and a straight line joins that piece back to the rest of the track. The green start marker is on the displaced piece. Every remaining sample, and the red end marker, are drawn exactly where stored. On this record (2794 points, 1 Hz, 17649 m drawn) the displaced block is the first 209 m of riding — about 53 seconds The displacement is one more application of the local WGS-84 → GCJ-02 transform, which these coordinates already contain: measured from screenshots at native 1179×2556, 417 m E / 219 m S on the full-screen map and 418 m E / 220 m S on the summary map, against a true local offset of 415.2 m E / 222.4 m S. THE STORED DATA IS CORRECT HKWorkoutRouteQuery returns all 2794 CLLocation values unchanged; the descriptor query returns the same count and the same first/last values. One workout, one route. The same coordinates drawn with SwiftUI Map + MapPolyline on the same phone render correctly end to end, including the start. The same unchanged workout, opened twice with no write in between, was correct the first time and offset after leaving and re-entering. So the data is not the variable. THE WRITE PATH The head unit writes GCJ-02 into record.position_lat / position_long. That is what makes the track land on the road here: MKMapSnapshotter on the mainland base map puts the GCJ-02 values exactly on two known intersections, and the WGS-84 values about 470 m north-west of them, and MapKit does no conversion for us. So they are written verbatim: let config = HKWorkoutConfiguration() config.activityType = .cycling config.locationType = .outdoor let builder = HKWorkoutBuilder(healthStore: store, configuration: config, device: nil) try await builder.beginCollection(at: firstPoint.timestamp.addingTimeInterval(-1)) // CLLocation per record, coordinates as recorded, horizontalAccuracy 10, // verticalAccuracy 10 (or -1 where the record has no altitude), recorded altitude // and speed, course computed from the previous point. let routeBuilder = builder.seriesBuilder(for: HKSeriesType.workoutRoute()) as? HKWorkoutRouteBuilder for batch in locations.chunked(into: 1000) { try await routeBuilder?.insertRouteData(batch) } try await builder.endCollection(at: lastPoint.timestamp.addingTimeInterval(10)) let workout = await builder.finishWorkout()WHAT IS NOT THE CAUSE Established with controlled synthetic routes written from the same start point: probe sample interval m per point displaced length displaced time samples E 1 s 10 ~480 m ~48 s ~49 F 2 s 10 ~480 m ~96 s ~49 G 1 s 20 ~950 m ~48 s ~49 The block follows SAMPLE COUNT, not time and not distance. Also ruled out, each by writing a variant: lap and pause/resume events (present, absent, and a 206-point probe carrying all three); the first point's metadata (altitude 0 / course -1 / verticalAccuracy -1); valid versus -1 values for horizontalAccuracy, verticalAccuracy, speed and course; dropping an isolated leading point; back-dating the first timestamp to the workout start; trimming the leading 200 m (the offset simply re-appears at the new start, which still begins with 49 samples). Writing WGS-84 instead inverts the symptom — the leading block then looks right and everything else goes ~470 m north-west — which is what you would expect if only the leading block is converted a second time. SCOPE This is not my one file. Three separate real rides, two cities, two head units, plus synthetic routes, all behave identically: MAGENE C706_54634 Suzhou 2026-10-23 17.61 km 2797 records / 2794 stored points MAGENE C706_54634 Suzhou 2026-10-22 12.66 km 2076 records MAGENE C606P_33206 Chengdu 2026-10-20 63.30 km 12069 records Apple Watch recordings made in mainland China render correctly, and a Garmin Edge 1050 file recorded in the US imported through the same code path renders correctly. The common factor is coordinates that are already GCJ-02 when they reach HKWorkoutRouteBuilder — which is every Chinese bike computer, every Chinese running app, and every GPX export from a Chinese service. So any third-party importer here hits this. WHAT I AM ASKING Does the workout map apply a datum conversion to a leading block of route samples, and is that block size fixed? What is the official coordinate contract for HKWorkoutRoute locations for apps working with GCJ-02 data in mainland China? Is there a supported way to opt out, and what decides whether a given route enters this state? Which component owns the conversion — Health/Fitness route rendering or MapKit? I am deliberately not pre-converting the first ~49 points: that would store mixed datums in HealthKit, wrong for the Health app itself, for exports, for every third-party reader, and wrong for all of them the moment this is fixed. Happy to share the one-tap sample project, the exported JSON with all 2794 stored CLLocation values, the original .fit, and the probe E/F/G screenshots — reply here and I'll attach them.