Swimming Data API: Strokes, Laps and Swim Distance by Platform

A swim is a sequence of lengths, and each platform keeps a different slice of it: per-length detail, a running total, or nothing outside the workout. Which slice you can read decides whether your app can show strokes by type, count lengths, or only report a number of strokes.

What each platform has#

Read from Google's documentation on 2026-10-17, its Health Services reference on 2026-10-04 and its Health Connect reference on 2026-10-03, and from Apple's identifier documentation on 2026-10-02 and metadata-key documentation on 2026-10-04. General distance on every platform is covered by the distance tracking API guide.

Google: per-length detail, totals by rollup#

swim-lengths-data is an Interval type. Each data point carries its observed interval, a strokeCount that Google describes as the "Number of strokes in the lap," and a swimStrokeType of FREESTYLE, BACKSTROKE, BREASTSTROKE, BUTTERFLY or SWIM_STROKE_TYPE_UNSPECIFIED. You can list and reconcile the data points or call rollUp and dailyRollUp, whose result has one field: strokeCountSum, "Total number of swim strokes in the interval." A rollup keeps no stroke types and no count of data points, so strokes by type, or a count of lengths, means listing the data points.

Google's table gives the type no webhook support and no true-zeros support, lists 23 compatible devices, all Fitbit devices or Pixel Watch models, and maps the Fitbit Web API's swimming-strokes activity time series to it. Both activity-and-fitness scopes cover it.

The exercise type adds two swim fields: totalSwimLengths, "Number of full pool lengths completed during the exercise," and poolLengthMillimeters in exercise metadata, both present only for swimming exercises. Exercise data is otherwise outside this page's scope.

Apple: cumulative types plus workout metadata#

HealthKit has two swimming quantity types, both cumulative and both from iOS 10.0 and watchOS 3.0: swimmingStrokeCount measures "the number of strokes performed while swimming," and distanceSwimming "the distance the user has moved while swimming." A statistics query sums them over any interval, but a stroke-count sample carries no stroke style.

The structure lives on the workout instead. Apple's Swimming group of workout metadata keys documents three:

• HKMetadataKeySwimmingStrokeStyle: "the predominant stroke style for a lap of swimming," set on workout lap events, with a value from the HKSwimmingStrokeStyle enumeration.
• HKMetadataKeyLapLength: "the length of a lap during a workout," an HKQuantity in length units, set on a workout, a workout segment or a distance sample.
• HKMetadataKeySwimmingLocationType: "the location for a swimming workout," a value from the HKWorkoutSwimmingLocationType enumeration.

"Predominant" is Apple's word: a lap with mixed strokes still gets one style. Google's field description does not say how a mixed length is typed. The same group lists HKMetadataKeySWOLFScore from iOS 16.0 and HKMetadataKeyWaterSalinity from iOS 17.0, both without an abstract in Apple's documentation as read, so this site cannot tell you their units or where they are set. This site's data does not list the cases of HKSwimmingStrokeStyle either; read Apple's page for that enumeration before mapping Google's four stroke names onto it.

Wear OS: counts since the last update#

Health Services has SWIMMING_STROKES, the "Number of swimming strokes taken since the last update," and SWIMMING_LAP_COUNT, the "Count of swimming laps since the last update." Both are DeltaDataType<Long, IntervalDataPoint<Long>>, with SWIMMING_STROKES_TOTAL and SWIMMING_LAP_COUNT_TOTAL counting from the start of the current active exercise, and both sit under ACTIVITY_RECOGNITION in Google's permissions table. None of the 65 data types is a stroke type or a swim distance.

Health Connect: no swimming record#

None of Health Connect's 42 record types is a stroke count, lap count or swim distance. Swimming exists there as two exercise types, EXERCISE_TYPE_SWIMMING_POOL and EXERCISE_TYPE_SWIMMING_OPEN_WATER, on ExerciseSessionRecord, whose optional laps field holds "ExerciseLaps of the session" that Google says should fall within the session and not overlap. A swim's distance goes in the general DistanceRecord, which does not name the activity that produced it. Stroke counts from a watch have no record to go into.

Traps#

• Lap, length, or both. Google's type is called swim lengths, its field counts strokes "in the lap," and its exercise summary counts "full pool lengths"; Wear OS counts laps; Apple keys a lap length. None of these descriptions says whether a lap is one length of the pool or two, so check on a device before you turn a count into distance.
• Rollups drop stroke types. Google's rollup returns strokeCountSum and nothing else.
• Per data point, cumulative, or delta. Google stores strokes per data point, Apple as cumulative samples with the style on lap events, Wear OS as deltas since the last update. Totals agree in kind; per-length detail exists only where a platform keeps it.
• Polling, not push. With no webhook support, Google's swim data has to be fetched.
• Nothing to write on Android. A Wear OS app that counts strokes has no Health Connect record to store them in; keep them in your own store.

Before you ship#

Re-read the type pages and metadata keys linked here before each release; they regenerate from Google's and Apple's documentation. Store each stroke type in the vocabulary it came from, record the pool length beside every count, and design the Android path for strokes without Health Connect.