--- title: "Apple Vision Framework Body Pose: The Native iOS Option" canonical: "https://aifitnessapi.com/motion/apple-vision-body-pose" cluster: "AI Motion" primary_query: "apple vision framework body pose" last_reviewed: "2026-08-02" description: "VNDetectHumanBodyPoseRequest (2D, 19 joints) and the 3D request (17 joints): when Apple's native path beats bundling MediaPipe or MoveNet." publisher: "AIFitnessAPI — independent, not sponsored" cite_as: "\"Apple Vision Framework Body Pose: The Native iOS Option\", AIFitnessAPI, https://aifitnessapi.com/motion/apple-vision-body-pose" --- # Apple Vision Framework Body Pose: The Native iOS Option > Apple's Vision framework gives you two body pose requests with no model file to ship: VNDetectHumanBodyPoseRequest (2D, 19 named joints, iOS 14+) and VNDetectHumanBodyPose3DRequest (3D, 17 named joints with camera-relative positions and a metric body-height estimate, iOS 17+). Choose Vision for an iOS-only app that wants zero model bytes, OS-maintained inference, and built-in offline video via VNVideoProcessor; choose a bundled model like MediaPipe or MoveNet when an Android sibling app exists or you need to pin a model version for regression testing. The catch to weigh honestly: Apple publishes no model card and no accuracy numbers, so any accuracy claim about Vision is unverifiable — measure it on your own footage, not from a spec sheet. - Canonical: https://aifitnessapi.com/motion/apple-vision-body-pose - Last reviewed: 2026-08-02 - Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored - Cite as: "Apple Vision Framework Body Pose: The Native iOS Option", AIFitnessAPI, https://aifitnessapi.com/motion/apple-vision-body-pose --- 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](/motion/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](/motion/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](/test/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. | Dimension | Vision (native) | Bundled model (MediaPipe / MoveNet) | | --- | --- | --- | | Distribution | Ships inside the OS; zero model bytes in your app | You ship the file — MediaPipe's `.task` bundles download at roughly 5.5 to 29.2 MiB depending on variant | | Model updates | Arrive with OS updates, on Apple's schedule | You decide when to swap the file; old versions stay reproducible | | Version pinning | No model artifact to pin; the 2D request documents a revision constant, but the implementation lives in the OS | Pin the exact file in your repo; regression tests stay stable | | Platform reach | Apple platforms only (iOS, iPadOS, macOS, tvOS, visionOS) | Android, iOS, and web from one model | | Documentation | API reference only — no model card, no accuracy figures, no distance guidance | Published model cards with accuracy numbers, speed figures, and stated limits | | Topology | 19 named 2D joints; 17 named 3D joints; no hand or foot detail | MediaPipe: 33 landmarks incl. heels and foot tips; MoveNet: 17 COCO keypoints | | 3D output | Separate iOS 17+ request; camera-relative joints, metric `bodyHeight` | MediaPipe: hip-relative world landmarks (z estimated); MoveNet: 2D only | | Offline video | `VNVideoProcessor` built in | You write the frame-extraction loop | | Fitness positioning | None documented by Apple | Both vendors explicitly target fitness in their model cards | | License to track | None — OS framework, not a distributed model | Apache-2.0 (verify bundled asset terms) | ## 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](/motion/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](/guides/ai-workout-tracking-ios-swift). ## FAQ ### Why do Apple's 2D and 3D body pose requests return different joint counts? They use different skeletons. VNDetectHumanBodyPoseRequest exposes 19 named joint constants including face detail (nose, eyes, ears) plus neck, shoulders, elbows, wrists, root, hips, knees, and ankles. VNDetectHumanBodyPose3DRequest exposes 17 named joints that drop the eyes and ears in favor of structural points: topHead, centerHead, centerShoulder, spine, and root, plus the arm and leg joints. Neither includes hand or foot detail, so code written against one skeleton does not map one-to-one onto the other. [Permalink](https://aifitnessapi.com/motion/apple-vision-body-pose#faq-1) ### Does Apple publish a model card or accuracy numbers for Vision body pose? No. Apple's documentation is an API reference: it contains no model card, no accuracy figures, no evaluation dataset, no distance-from-camera guidance, and no stated intended use cases. That contrasts with MediaPipe BlazePose and MoveNet, whose model cards publish accuracy numbers and working-distance limits. The only published figures naming Apple Vision come from Google's own MediaPipe comparison table, which is a competitor's benchmark and should be treated with that caveat. If you need a citable accuracy basis, measure Vision yourself on labeled footage. [Permalink](https://aifitnessapi.com/motion/apple-vision-body-pose#faq-2) ### What OS versions do the Vision body pose requests require? Apple documents VNDetectHumanBodyPoseRequest (2D) as available from iOS 14.0, iPadOS 14.0, macOS 11.0, Mac Catalyst 14.0, tvOS 14.0, and visionOS 1.0. VNDetectHumanBodyPose3DRequest (3D) requires iOS 17.0, iPadOS 17.0, macOS 14.0, Mac Catalyst 17.0, tvOS 17.0, or visionOS 1.0. VNVideoProcessor for offline video matches the 2D floor at iOS 14.0 and macOS 11.0. The three-version gap between the 2D and 3D floors matters if your feature depends on 3D output. [Permalink](https://aifitnessapi.com/motion/apple-vision-body-pose#faq-3) ### Can Vision run body pose on recorded video instead of a live camera? Yes. VNVideoProcessor is Apple's documented object for offline analysis of video content: create it with init(url:) pointing at a video asset, attach requests with addRequest(_:processingOptions:), and run analyze(_:) over a time range, with cancel() to stop. The older analyze(with:) and VNVideoProcessingOption are deprecated. This is useful for fitness work because a library of recorded workout clips becomes a pose regression suite that needs no capture session or physical device camera. [Permalink](https://aifitnessapi.com/motion/apple-vision-body-pose#faq-4) ### Should a cross-platform fitness app use Apple Vision for pose estimation? Usually not as its only pose layer. Vision runs on Apple platforms only, so an Android sibling app needs a second implementation with a different skeleton, different coordinates, and different failure modes, all validated separately. Cross-platform teams therefore usually bundle one model, such as MediaPipe Pose Landmarker or MoveNet, and run the same artifact on both platforms. Vision still earns a place in an iOS-only product, or as a deliberate per-platform choice made with eyes open about maintaining two pipelines. [Permalink](https://aifitnessapi.com/motion/apple-vision-body-pose#faq-5)