iOS - v1.4.3: Heart Rate, Calories, Elevation & Apple Health

Trckify 1.4.3 is a broad accuracy and correctness release. A day of testing alongside the macOS edition launch surfaced a whole cluster of subtle bugs around how data flows between the Apple Watch, iPhone history, FIT/GPX exports, and Apple Health. They were mostly invisible individually but added up to heart rate going missing, calories not landing in Strava, elevation numbers that disagreed with other apps, and workouts that never actually made it to the Health app. All fixed, and then some.

Heart rate now stays where you put it

Three small but important bugs conspired to make heart rate feel unreliable on older history entries:

Imports now detect heart rate correctly. If you imported a GPX file that already contained heart rate data in its extensions, Trckify was ignoring it — you’d be offered the “Import HR from Apple Health” button even though your track already had HR right there in the file. Fixed. New imports now look for heart rate in the parsed points and set the flag accordingly.

Reloading a trimmed or HR-merged track preserves its state. If you imported HR into a track from Apple Health, then closed and re-opened the entry, the heart rate could appear missing — even though the flag said it was there. The culprit was that reload was reading the original source file (which never had HR) instead of the re-exported version with HR merged in. Trckify now prefers the up-to-date export file, so whatever state you last saved is exactly what you see when you come back.

The HR import button no longer fails silently. Previously, if Apple Health had no samples for the track’s time range — because the Apple Watch wasn’t worn that day, or because the track is older than your HR history — tapping the button just did nothing. Now you get a clear message telling you what happened (no samples found, HR already present, HealthKit not available, or success), so you’re never left wondering.

Active calories now ride along in exports

When you export a recording with an active calorie count from your Apple Watch, those calories now travel with the file:

FIT exports include the total_calories field in the Session message — Strava, Garmin Connect and DJI Mimo all read this automatically. Your kcal show up natively in whatever platform you’re sharing to, no extra step.

GPX exports include a private Trckify extension element at the track level (trckify:activeCalories) inside a namespaced block. Other GPX tools ignore what they don’t recognize, so round-tripping through third-party apps stays safe — and if you re-import the file into Trckify later, we read the calories back.

Combined with the Mac edition launching today: a workout you record on Apple Watch now survives the full path — Watch to iPhone to history to re-export to AirDrop to Mac to re-import — with heart rate and calories intact throughout.

Apple Watch workouts actually save to Apple Health now

If you had the “Save workouts to Apple Health” setting turned on and recorded an activity on your Apple Watch, the expectation was that the finished workout — with heart rate and active calories — would land in the Health app automatically. In practice, nothing showed up.

The root cause was a race inside the HealthKit session shutdown sequence on the Watch. Apple’s documentation is clear: end the workout session first, then end the data collection, then finish the workout. Trckify was doing those three calls in the wrong order, which meant the data collection was being finalized against a session that was simultaneously being torn down. HealthKit silently declined to persist the workout and the save never happened.

The three calls are now in the correct order, plus we added diagnostic logging along the whole save path so any future regression shows up in the Watch console rather than as silent nothing.

This affects every combination of start/stop device — start on Watch and stop on Watch, start on iPhone and stop on Watch, start on Watch and stop on iPhone, any order works now. If you record phone-only with no Watch involved, nothing writes to Apple Health (that’s a separate feature planned for 1.5).

Elevation numbers match Strava and Garmin now

Back in 1.4.2 we added a 3-meter GPS noise filter to the elevation calculation so that imported tracks no longer showed hundreds of meters of fake climb from sub-meter altitude drift. That fix landed in the stats view correctly, but it never made it into the FIT export code. So Trckify’s own UI showed the correct filtered number while the exported .fit file — the one you upload to Strava, Garmin Connect, or DJI Mimo — still carried the raw unfiltered numbers. A 24 m ski track could show 266 m of “elevation gain” on Strava while Trckify itself showed 24. Confusing.

Fixed: the elevation calculation in FITEncoder now applies the exact same 3 m accumulator filter as the UI. Fresh exports and re-exports from history both come out consistent with what Trckify shows.

Slopes files trust their own metadata

When you import a Slopes ski file, the .slopes archive contains Slopes’ own authoritative lift/run classification — precise start and end times for every chairlift, gondola, and ski run Slopes detected. Trckify was correctly reading those intervals, but then running its own heuristic lift detection on top as a second pass. The heuristic’s short-segment cleanup occasionally cleared correctly metadata-tagged lift samples in the middle of the activity, reclassifying them as “runs” — which then inflated the run-only elevation gain by hundreds of meters, because now the phone saw the skier going uphill on what the app thought was a downhill run.

Concrete example from testing: a Zell am See — Schmittenhöhe day that Slopes’ own metadata says is 6249 m of vertical. Trckify was showing 1605 m of run-only gain on top of the correct loss — impossible unless the skier was walking up groomers. After the fix, the run-only gain drops to ~90 m (which is real, from catwalk traverses and transition samples at lift boundaries), and the vertical loss matches Slopes to within 10 meters.

The metadata is now authoritative for the body of the activity, and the heuristic is only allowed to touch the edges (the very start and very end of the recording, where Slopes occasionally misses a warm-up gondola).

GPX round-trips preserve lift classification

Related: when you export a Trckify ski track to GPX and re-import it — on the same device, on another iPhone, or on the Mac edition — the lift classification was lost, because GPX has no standard way to mark “this point is on a chairlift, not a ski run”. The heuristic re-ran from scratch and the phantom gain came back.

GPX exports now include a small Trckify-specific element in each track-point’s extensions block (<trckify:isLift>true</trckify:isLift>) that other GPX readers safely ignore. On re-import we read the tags back and derive the original lift intervals, so the re-imported file behaves identically to the original. A ski day shared from iPhone to Mac now shows the same elevation numbers on both sides.

Lift segments read cleanly everywhere

If you exported a map screenshot with lift segments over a bright satellite map or snow-covered terrain, the dashed grey lift lines could disappear into the background. The interactive 3D map had this right already — lifts rendered with a wider opaque white base under a narrower grey dashed top, so they always pop against any terrain.

The PNG export pipeline now does the same thing. Screenshot exports and shared map images show lift segments with the exact same contrast treatment as what you see on screen, which matters most for ski and snowboard tracks taken over powder days.

Small things

Two quality-of-life improvements behind the scenes:

The color mode label “Heatmap” is now properly localized — it still reads as “Heatmap” in English and in German (both languages happen to use the same word), but the string now goes through the localization catalog instead of being hardcoded, which lets future languages translate it properly.

Some SwiftUI view-update batching quirks that caused stale stats and stale history thumbnails right after a fresh recording or an HR merge have been flattened out. You’ll notice it most in the recording flow: when you finish a Watch ride, the history list now immediately shows the correct thumbnail and correct numbers instead of borrowing the previous track’s data until you navigate away and back.

The iOS Info.plist’s NSHealthUpdateUsageDescription — the text Apple shows when HealthKit asks for write permission — used to say “Trckify does not write any health data.” That was true when it was first written, but hasn’t been since the 1.4.2 Apple Health save feature. It now accurately describes what Trckify actually does with your workouts.

What’s next

This release closes the loop on heart rate, calories, elevation, and Apple Health integration. Next up on the roadmap: iPhone-only recordings saving to Apple Health (for when you leave the Watch at home), Strava direct upload, season statistics rolling up all your tracks in one view, and the beginnings of a video-telemetry overlay. See you in 1.5.