Apple Vision Framework Body Pose: The Native iOS Option

Nobody benchmarks the iOS-native option, and there is a structural reason why: Apple gives you nothing to benchmark against. Vision's body pose requests ship with no model card, no accuracy figures, no distance guidance, and no fitness positioning — just an API reference. That makes them easy to skip in a model comparison and easy to underrate in an actual product decision, because the things Vision is good at (zero model bytes in your app, OS-level maintenance, built-in offline video processing) are exactly the things a benchmark table never shows. This page covers what Apple actually documents, and when the native path beats bundling a model.

What Apple actually documents#

Vision offers two separate body pose requests, and they are not the same skeleton.

The 2D request: VNDetectHumanBodyPoseRequest#

Apple documents VNDetectHumanBodyPoseRequest as "a request that detects a human body pose," returning results as VNHumanBodyPoseObservation. Availability is iOS 14.0+, iPadOS 14.0+, macOS 11.0+, Mac Catalyst 14.0+, tvOS 14.0+, and visionOS 1.0+ — so the 2D request reaches essentially any modern Apple device.

The observation exposes 19 named joint constants on VNHumanBodyPoseObservation.JointName:

• Head: nose, leftEye, rightEye, leftEar, rightEar, neck
• Arms: left and right shoulder, elbow, wrist
• Torso: root (the waist)
• Legs: left and right hip, knee, ankle

Notice what is missing: no fingers, no heels, no foot-index points. MediaPipe's 33-landmark topology includes hand knuckles, heels, and foot tips; Vision's 2D skeleton stops at the wrists and ankles. If your form logic needs foot orientation or grip cues, that difference decides the choice before anything else does — see pose estimation models compared for the full topology rundown.

The request documents one revision constant, VNDetectHumanBodyPoseRequestRevision1. Keep that in mind for the version-pinning discussion below.

The 3D request: VNDetectHumanBodyPose3DRequest#

The 3D request is newer and narrower: iOS 17.0+, iPadOS 17.0+, macOS 14.0+, Mac Catalyst 17.0+, tvOS 17.0+, visionOS 1.0+. Apple describes it as detecting "points on human bodies in 3D space, relative to the camera," and documents that "if the system allows it, the request uses AVDepthData information to improve the accuracy" — depth hardware is used opportunistically, not required.

It returns 17 named joint constants on VNHumanBodyPose3DObservation.JointName, and the skeleton is rebalanced versus the 2D one: the face detail (eyes, ears) is gone, replaced by structural points — topHead, centerHead, centerShoulder, spine, root, plus left and right shoulder, elbow, wrist, hip, knee, ankle.

The observation itself is where the 3D request gets interesting for fitness work. Apple documents:

• bodyHeight — "the estimated human body height, in meters," with a companion heightEstimation property describing the technique used
• cameraOriginMatrix — a simd_float4x4 transform "from the skeleton hip to the camera"
• cameraRelativePosition(_:) — a joint's position relative to the camera
• pointInImage(_:) — the 2D projection of a 3D joint back into the image

Camera-relative positions plus a metric height estimate is a different 3D promise than MediaPipe's hip-relative world landmarks. Whether you need 3D at all is its own decision — 2D vs 3D pose estimation covers that — but if you do, note the iOS 17 floor: three OS versions above the 2D request's iOS 14.

One honest gap: the reference pages we can verify do not document a person-count limit for either request, in either direction. Do not assume single-person or multi-person behavior from the docs — test it on your own scenes.

VNVideoProcessor: offline video is built in#

Vision ships an offline analysis path that bundled models make you build yourself. VNVideoProcessor — "an object that performs offline analysis of video content," iOS 14.0+/macOS 11.0+ — takes a video asset via init(url:), accepts requests through addRequest(_:processingOptions:), and runs them over a time range with analyze(_:), with cancel() to stop. (The older analyze(with:) and VNVideoProcessingOption are deprecated; use the current forms.)

For a fitness app this is quietly one of Vision's best arguments. Point it at recorded workout clips and you get pose output with no capture session, no camera, and no device rig — which is exactly the shape a pose regression suite wants. Since Apple gives you no accuracy numbers (next section) and no model artifact to pin, a library of golden clips you re-run per OS release is your accuracy story. Testing camera features without a device covers how to build that harness.

Vision vs a bundled model: the actual trade-offs#

These are decision dimensions, not benchmarks — nobody has published a neutral accuracy comparison, and Apple has published no numbers at all.

When the native path wins#

• You are iOS-only, by choice. No second implementation looming, so lock-in costs nothing. Vision's 2D request runs back to iOS 14 — a wider floor than most teams need.
• App size and update logistics matter. A bundled MediaPipe .task file adds megabytes to your binary and makes model updates your release problem. Vision adds zero bytes and Apple maintains the implementation.
• Your pipeline already lives in Apple's media stack. If frames come from AVFoundation capture or an ARKit session, keeping pose inference in an OS framework avoids bridging pixel buffers into a third-party runtime — in our judgement the integration friction saved here is real, though it is not something Apple quantifies.
• You want offline video analysis without building it. VNVideoProcessor is a shipping API, not a weekend project.

When it loses#

• An Android sibling app exists or is planned. Vision does not run on Android, full stop. You would write and validate a second pose implementation with different joints, different coordinates, and different failure modes — which is why cross-platform teams usually bundle one model and run it everywhere. If that is you, start at MediaPipe vs MoveNet instead.
• You need model-version pinning. With a bundled model, the artifact in your repo is the model, forever. With Vision, the implementation ships in the OS and there is no file to pin — so, in our judgement, you should assume your golden-clip outputs can shift when users update iOS, and design your regression suite to detect that rather than prevent it.
• Your feature needs feet or hands. 19 points without heel or foot-index landmarks rules out some squat-depth and stance heuristics that MediaPipe's 33-point topology supports.
• You need accuracy claims you can cite. See below.

The accuracy claim you cannot make#

Apple publishes an API reference, not a model card. Concretely, the documentation contains no accuracy figures, no evaluation dataset, no distance-from-camera guidance, and no statement of intended use cases. Compare the bundled options: MoveNet's card states fitness targeting, a 3 to 6 foot working distance, and mAP figures; the BlazePose card publishes PCK numbers and a stated degradation range. Against those, any sentence you write that ranks Vision's accuracy is unverifiable from primary sources.

The closest thing to a published number comes from Google's legacy MediaPipe docs, whose quality table lists "Apple Vision" at PCK@0.2 scores of 82.7 (yoga), 91.4 (dance), and 88.6 (HIIT) — below all three BlazePose variants. Treat that with the obvious caveat: it is a competitor benchmarking a rival on Google's own evaluation set, with no stated Vision version or configuration. It is a data point, not a verdict.

This is a real decision factor, not a technicality. If your product, your investors, or your compliance story needs a citable accuracy basis, a model with a published card gives you one and Vision does not. If you can substitute your own measurement — and VNVideoProcessor over a labeled clip library makes that cheap — the gap closes. Either way, the number that matters is the one you measure on your own footage.

Before you ship#

The decision compresses well: iOS-only product, standard joints, tolerance for Apple's update cadence — take Vision and enjoy shipping zero model bytes. Android on the roadmap, version pinning required, or hand/foot landmarks needed — bundle a model. In both cases, build the recorded-clip regression suite first, because with Vision it is your only accuracy instrument and with a bundled model it is how you validate upgrades. For wiring the capture session, request handling, and joint processing into a working iOS app, see the AI workout tracking in iOS with Swift guide.