Best Pose Estimation Model in 2026: The Real-Time Mobile Guide

If you are adding body tracking to an app in 2026, you will spend an afternoon searching for "the best pose estimation model" and walk away with a shortlist. This guide is that afternoon, condensed, with one bias made explicit: most people asking the question are trying to run pose estimation in real time, on a phone, and often on more than one platform. That constraint decides more than any accuracy benchmark.

There is no universal best model. The right pick depends on your target device, whether you need real time, how many people are in frame, which keypoints you need to measure, and where the inference has to run (on-device or in the cloud). But once you say the words "real time on mobile", the list of serious candidates gets short quickly, and this guide is built to get you there.

We compare the eight models developers actually reach for: MoveNet, MediaPipe Pose Landmarker (BlazePose), ML Kit Pose Detection, YOLO26-pose, Apple Vision / ARKit, OpenPose, MMPose and PoseNet.

We also cover the part most comparisons skip: choosing a model is roughly 10 percent of the work. The other 90 percent starts the moment the model returns its first tensor.

The one chart that answers "which model for real-time on mobile?"

Two questions decide almost everything for a mobile app: can the model run in real time on the device, and how far does it reach across platforms (iOS, Android, web)? Plot the eight models on those two axes and the picture is stark.

The top-right corner, real time and cross-platform, is where a modern mobile app wants to live, and only MoveNet sits comfortably there. MediaPipe reaches every platform too, but it is heavier: in the browser on a Pixel 5 it runs at roughly 11-12 FPS, where MoveNet Lightning still holds 34. Everything else forces a bigger trade: ML Kit and YOLO26 are real time but narrower in reach, Apple's stack is superb but iOS-only, and OpenPose, MMPose and PoseNet are not built for real-time mobile. The FPS numbers below show exactly why each model lands where it does.

The comparison table

Read the table, then read the FPS numbers below, because "real time" is where the marketing and the phone disagree.

Real FPS numbers, by device (the honest part)

Vendors love to say "real-time on mobile". On a phone, the truth is more specific. These are measured frame rates from the TensorFlow.js pose-detection benchmarks, in the browser (WebGL backend), which is the true cross-platform path (same code on iOS, Android and web):

The Android row is the one that decides real projects. On a Pixel 5, MoveNet Lightning holds 34 FPS while BlazePose sits at 11-12 (5 for Heavy). Desktop and iPhone are comfortable for both; Android in the browser is where BlazePose stops being real time and MoveNet keeps going. That single row is why MoveNet is the safe default for a cross-platform, real-time mobile app.

One honest caveat: MediaPipe's native runtime (not the web build) is faster on Android, around 22-32 FPS for Full/Lite on a Pixel 5. So if you are native-only on Android, BlazePose is viable. For one cross-platform build that also runs on the web or in a WebView, MoveNet is the safer real-time bet.

The axes that decide your choice

1. Real time, and where the inference runs (on-device vs cloud)

This is the axis most "best model" lists bury, and it is the one that matters most for a phone app.

• On-device means the model runs on the phone itself: no round trip, no server bill, and the camera stream never leaves the device (a real privacy argument). MoveNet, MediaPipe, ML Kit, Apple Vision/ARKit and PoseNet all run on-device. YOLO26 can, once exported to CoreML or TFLite.
• Cloud / server inference (sending frames to a GPU somewhere) is an option for heavy models like MMPose or OpenPose, but it adds latency, cost and a privacy question, and it is a poor fit for smooth real-time overlay on mobile.
• Real time on mobile means comfortably holding 30+ FPS on the device. MoveNet, ML Kit and Apple's stack clear that bar comfortably, and YOLO26-nano does too; MediaPipe clears it on iOS and via its native Android runtime, but drops to about 11 FPS in the browser on Android; OpenPose and MMPose do not without serious hardware; PoseNet is borderline.

If you are drawing a live skeleton over a moving body, you want on-device real time. That single requirement already removes OpenPose and MMPose from a mobile shortlist.

2. Platform reach: iOS, Android, web

A model that is perfect on iOS and absent on Android will cost you a second implementation.

• iOS + Android + Web: MoveNet (TF.js for web, TFLite for native) and MediaPipe (Android, iOS, web, Python) reach everywhere.
• iOS + Android, native only: ML Kit ships as a mobile SDK, no web.
• iOS only: Apple Vision and ARKit are excellent and free, but Apple-locked. Ship on Android and you need a completely different stack. This is the most common cross-platform trap in pose estimation.
• Web: MoveNet and PoseNet run in the browser through TensorFlow.js, including mobile browsers.

3. Keypoint schema: 17 vs 19 vs 33 vs 133

A model can only measure what its skeleton describes.

• COCO-17 (MoveNet, YOLO26-pose, PoseNet): shoulders, elbows, wrists, hips, knees, ankles, plus eyes and ears. Enough for reps, joint angles and gross posture. No hands, no feet detail.
• Apple Vision-19 (VNDetectHumanBodyPoseRequest): 19 2D points across face, torso, arms and legs, on-device from iOS 14. ARKit's motion-capture skeleton goes much further, up to a 91-joint 3D rig.
• BlazePose-33 (MediaPipe, ML Kit): the COCO points plus finer face, hand (pinky, index, thumb) and foot (heel, foot index) landmarks. Better when wrist orientation or foot placement matters.
• WholeBody-133 (MMPose): body, feet, face and both hands in one skeleton. What you want for sign language or fine gesture work, and overkill for counting squats. OpenPose reaches a similar density (up to 135) from its 2017 lineage.

Pick the smallest schema that covers what you measure. More keypoints means more to compute and more to smooth, not automatically better results.

4. Single person vs multi-person

• Single person by design: MoveNet and ML Kit track one subject; ARKit's motion capture tracks one body. MediaPipe defaults to one but can be configured for more. Apple Vision can return several observations.
• Multi-person natively: YOLO26-pose predicts boxes and keypoints for everyone in one pass. PoseNet has a multi-pose mode. OpenPose and MMPose both handle crowds.

Personal coaching app, user alone in front of a camera? Single person is simpler and faster. Team sport, class or crowd? You need native multi-person, and YOLO26-pose is the modern default.

5. Architecture family: top-down, bottom-up, single-stage

The way a model finds people changes how it behaves under load.

• Top-down (HRNet, most of MMPose): detect people first, then estimate keypoints per crop. Accurate, but cost grows with the number of people.
• Bottom-up (OpenPose): detect all keypoints, then group them into poses. Scales better with crowd size but struggles to group densely.
• Single-stage (YOLO26-pose): predict boxes and keypoints together in one pass, no separate detection or grouping. This is what makes real-time multi-person feasible, and YOLO26 also drops non-maximum suppression for predictable edge latency.

Model by model

MoveNet

A fast, accurate single-person model detecting 17 COCO keypoints, from TensorFlow. Two variants: Lightning (latency-first, 192x192) and Thunder (accuracy-first, 256x256). Lightning is the speed champion of this list: in the browser via TF.js it runs at 51 FPS on an iPhone 12, 34 on a Pixel 5 and 104 on a 2019 MacBook (Thunder trades speed for accuracy and is slower, 12 FPS on the same Pixel 5). Output is a normalized [1, 1, 17, 3] array (y, x, score). Ships as SavedModel (server), TFLite (mobile/edge) and TF.js (web), so it is the same engine on iOS, Android and web. If you want one person tracked smoothly on-device across platforms, MoveNet is the default answer, and it is the engine PoseTracker runs on.

MediaPipe Pose Landmarker (BlazePose)

Google's Pose Landmarker detects 33 landmarks in 3D, with image and real-world coordinates plus optional segmentation masks. It runs a two-stage pipeline (detector then landmark model) built on a MobileNetV2-style CNN with the GHUM 3D body model. Three variants (Lite, Full, Heavy) trade speed for accuracy, across Android, iOS, web and Python. The catch is weight: in the browser on a Pixel 5 it runs around 11-12 FPS (Full/Lite), and 5 for Heavy, versus MoveNet Lightning's 34, so on Android web it is often not truly real time. Its native runtime is faster (~22-32 FPS on a Pixel 5). Choose it when you need 3D or richer landmarks than COCO-17 and can accept the extra cost, ideally shipping it natively rather than on the web.

ML Kit Pose Detection

Google's mobile-focused API produces a 33-point skeleton (face, hands, feet) on Android and iOS, with a Base model tuned for real time (around 30 FPS on a Pixel 4, 45 FPS on an iPhone X) and an Accurate model that trades frame rate for precision. Single person, experimental Z depth, still labelled beta (no SLA). Great when you want a turnkey native SDK and only need one subject, but there is no web target.

YOLO26-pose

The real-time multi-person workhorse. A single-stage model that predicts boxes and 17 COCO keypoints in one pass, so multi-person comes for free. Its pose head integrates Residual Log-Likelihood Estimation (RLE) for better localization on unusual or partially occluded poses, and removes NMS for predictable edge latency. Five sizes dial the tradeoff: nano (2.9M params) hits 57.2 mAP50-95 at 1.8 ms/frame on a T4 GPU, while x-large (57.6M) reaches 71.6 for offline analysis. Runs from pip install ultralytics and exports to about 20 formats (CoreML, TFLite, ONNX, TensorRT...). Its known weak spots, per LearnOpenCV, are extreme yoga poses and heavily overlapping bodies. On mobile it is real time once exported, but it is more setup than a drop-in SDK.

Apple Vision / ARKit

Apple's two native, on-device options, both excellent and both iOS-only. Vision (VNDetectHumanBodyPoseRequest) detects 19 body points in 2D from iOS 14, entirely on-device, and VNDetectHumanBodyPose3DRequest (from iOS 17) adds 3D points relative to the camera. ARKit Motion Capture (ARBodyTrackingConfiguration) goes further: a high-fidelity 91-joint 3D skeleton in real time, introduced with ARKit 3 in 2019 and requiring an A12 chip or newer. If you are iOS-only, this is a superb, free, well-integrated choice. The catch is the whole point of this guide: ship on Android or web and none of it comes with you.

OpenPose

The milestone. Released in 2017 by Carnegie Mellon, OpenPose was one of the first systems to detect full-body multi-person poses (up to 135 keypoints: body, hands, feet, face) in real time from a standard camera. It runs on Windows, Linux and macOS, CPU or GPU. Today it is heavy and slow next to modern models and a poor fit for phones, but it remains the reference for understanding how the field got here. Reach for it to learn the lineage, not to ship on mobile.

MMPose

Not a single model but a PyTorch research toolbox from OpenMMLab: 2D and 3D human pose, hands, face, whole-body 133 keypoints, animals and 3D mesh, with many SOTA algorithms (HRNet, RTMPose, RTMO) and 40+ datasets. Powerful and well documented, and a lot to deploy and maintain for a product, typically on a GPU rather than a phone. Use it when your problem is genuinely research: unusual datasets, custom keypoints, or state-of-the-art accuracy you are willing to operationalize yourself.

PoseNet

The browser original. PoseNet brought real-time pose estimation to TensorFlow.js in 2018, detecting 17 COCO keypoints in single- or multi-pose mode, client-side, on a MobileNet architecture. At around 10 FPS on a 2018 MacBook Pro it has largely been superseded by MoveNet for new web projects, but it is still a clean reference for how in-browser pose estimation works.

The 90 percent that starts after you pick a model

Here is the part the comparison table hides. Every model above gives you the same shape of output: an array of keypoints, each with an x, a y, and a confidence score. That is it. YOLO26 hands you a (N, 17, 2) tensor plus scores. MoveNet hands you [1, 1, 17, 3]. Apple hands you joints. None of them give you:

• joint angles computed and smoothed frame to frame,
• rep counting with a definition of what a "good" rep is,
• a form score or posture feedback a user can understand,
• filtering to stop keypoints jittering when confidence dips,
• comparison to a reference movement, so you can score technique and not just count.

That business layer is where the months go. And it is not written once: a native pipeline has to be rebuilt and re-stabilized on iOS, Android and web, because the camera-to-tensor path (pixel formats, orientation, resize, normalization) differs on each platform. Many "pose bugs" are really camera preprocessing bugs. Hardware acceleration (Metal/CoreML, NNAPI, WebGL/WebGPU/WASM) is fragmented and fails silently across devices. And none of it is ever "done", because the OS and libraries underneath keep moving.

So a fair way to read this guide: the model is your engine choice. The car is everything else.

A practical verdict

• One person, real time, on mobile and cross-platform, shipped fast: MoveNet.
• Cross-platform with 3D or richer landmarks: MediaPipe (BlazePose-33).
• Native mobile, single subject, turnkey SDK, no web needed: ML Kit.
• iOS-only, and you want the best native 3D: Apple ARKit / Vision.
• Multiple people, real time: YOLO26-pose.
• Research, custom datasets, state of the art: MMPose.
• Understanding the field's history: OpenPose and PoseNet.

Where PoseTracker fits

PoseTracker is not another model in this table. It runs MoveNet on-device (via TensorFlow.js inside a WebView/iframe) and adds the 90 percent on top: a stabilized camera pipeline, smoothing, and a ready business layer that returns reps, joint angles, a form score, progression and comparison to a reference movement, as structured messages. You integrate it with roughly one line, and you get the same engine and the same outputs on iOS, Android and web, instead of rebuilding that layer three times, or being locked to a single platform the way Apple's stack locks you to iOS.

If you have already picked your model and are staring down the other 90 percent, that is exactly the gap PoseTracker is built to close.

Check out the PoseTracker docs to see the outputs a WebView integration returns: https://posetracker.gitbook.io/posetracker-api

FAQ

What is the best pose estimation model in 2026? There is no universal best. For one person, real time, on mobile and cross-platform, MoveNet is the common default. For 3D or richer landmarks across platforms, MediaPipe. For a turnkey native mobile SDK, ML Kit. For real-time multi-person, YOLO26-pose. For iOS-only apps, Apple's Vision and ARKit are excellent. For research and whole-body, MMPose.

Which pose model is best for real-time on mobile? MoveNet is the safest bet: in the browser it holds about 34 FPS on a Pixel 5 and 51 on an iPhone 12. MediaPipe reaches the same platforms but is heavier (around 11-12 FPS on a Pixel 5 in the browser; its native runtime is faster). ML Kit is real time on native iOS and Android. Apple Vision/ARKit are real time but iOS-only. OpenPose and MMPose are not designed for real-time mobile.

How many keypoints do I need? COCO-17 is enough for reps, joint angles and general posture. Apple Vision gives 19 in 2D. Use BlazePose-33 for hands, feet or face detail, and WholeBody-133 only for fine gesture or sign-language work.

Does the model run on-device or in the cloud? MoveNet, MediaPipe, ML Kit, Apple Vision/ARKit and PoseNet run on-device, so the camera stream stays on the phone. Heavy models like MMPose or OpenPose usually run on a server GPU, which adds latency and cost.

Does the raw model give me rep counts and form feedback? No. Every model returns keypoints and confidence scores. Angles, reps, form scoring, filtering and reference comparison are a business layer you build and maintain yourself, or get from a service like PoseTracker.