CMBatchedSensorManager: high-frequency motion batches during workouts

This is the class for swing analysis, punch detection and other movements that happen faster than ordinary motion updates capture. It is also one of the thinnest pages in Apple's Core Motion documentation. Here is what Apple says, read on 2026-10-03, and where it stops.

What Apple says it is for#

The CMBatchedSensorManager page has no overview. The purpose is stated on the Core Motion updates page, under June 2023: "Use the CMBatchedSensorManager class to access batches of high-frequency accelerometer and device motion data during workouts, such as a golf swing or a baseball bat swing." Apple's processed device-motion article also lists it as one of three device-motion providers, next to CMMotionManager and CMHeadphoneMotionManager. On the Core Motion index the class sits alone under a topic named "Historical data".

The API surface#

Apple's member list, none of which carries a description:

The handler forms take arrays: ([CMAccelerometerData]?, (any Error)?) -> Void and ([CMDeviceMotion]?, (any Error)?) -> Void. A batch is many samples per callback, which is the point of the class.

Platforms, and a misleading number#

Apple's page lists watchOS 10.0. It also lists iOS and iPadOS 4.0, Mac Catalyst 13.0 and visionOS 1.0. The iOS figure is the same 4.0 Apple gives the whole Core Motion framework, while Apple's update notes announce the class in June 2023. We read that stamp as inherited from the framework rather than as the class's history, and we could not find an Apple page that states an iPhone introduction version. The async-sequence accessors accelerometerUpdates() and deviceMotionUpdates() list watchOS 10.0 and nothing else.

A minimal sketch#

import CoreMotion

let batched = CMBatchedSensorManager()

func startSwingCapture(onBatch: @escaping ([CMAccelerometerData]) -> Void) {
    guard CMBatchedSensorManager.isAccelerometerSupported else { return }
    // accelerometerDataFrequency reports the rate; Apple does not document its value.
    batched.startAccelerometerUpdates { samples, error in
        guard let samples, error == nil else { return }
        onBatch(samples)            // many samples per callback; each carries a timestamp
    }
}

func stopSwingCapture() { batched.stopAccelerometerUpdates() }

Each CMAccelerometerData inherits a timestamp from CMLogItem, which Apple describes as recording "when the acceleration measurement was taken". Order and window your analysis on those timestamps, not on callback arrival.

We do not show the async-sequence form. Apple documents that AccelerometerUpdates conforms to AsyncSequence, but its element type and iterator carry no description we could read, and a sketch that guesses the element type is a sketch that may not compile.

What we could not verify#

• The sample rate. accelerometerDataFrequency and deviceMotionDataFrequency exist; their values are not documented. Read them at runtime.
• Whether a workout session is required. Apple's note says "during workouts". The class page does not say whether an HKWorkoutSession must be active, and we will not claim it either way. How a watch workout session works is on the anatomy of a watchOS workout app.
• Battery cost and batch size. Not documented.
• Permission specifics. authorizationStatus returns a CMAuthorizationStatus. Apple's Core Motion overview says an iOS app needs NSMotionUsageDescription "To access motion and fitness data"; the batched page itself says nothing about permissions.

Pitfalls#

• Treating the iOS 4.0 stamp as the class's history. It matches the framework's number.
• Expecting one sample per callback. Handlers receive arrays.
• Hard-coding a frequency. Read the frequency properties; no value is published.
• Leaving capture running. Start for the swing window, stop after. The power cost of high-rate motion is real even where Apple does not quantify it; see watch app battery.
• Assuming the class counts anything. It hands you samples. Turning them into swings or reps is your model; how rep counting works covers the patterns.