A face tracker's blend shapes are only as complete as its own list

The setup

Full facial performance capture for a VTuber usually starts with Apple's own ARKit face-tracking framework and ends inside a receiving application's own mapping of those values onto a Live2D model. Apple's developer documentation, retrieved 16 September 2026, for ARFaceAnchor.BlendShapeLocation is a living reference for iOS software, and VTube Studio's own wiki page, VTS Model Settings, is the receiving application's living reference for what it does with tracking data once captured. Neither page is a dated release; both describe current behaviour as retrieved.

What the documents show

Apple's page states that ARKit provides many named blend shape coefficients, describing them as identifiers for specific facial features used with values describing relative movement, and it gives jawOpen, eyeBlinkLeft and eyeBlinkRight as an example of a minimal set for a simple cartoon character, while a full character rig could use the entire set. VTube Studio's own input-parameter table lists a defined set of tracking inputs, several explicitly marked iOS-only, including CheekPuff, BrowLeftY, BrowRightY, EyeOpenLeft and EyeOpenRight, each mappable to any Live2D output parameter with configurable smoothing. A third page, Android vs. iPhone vs. Webcam, states that iOS tracking uses Apple ARKit and that devices need a TrueDepth camera, or an A12 chip or newer, while Android tracking uses a separately documented method.

The craft

Building this workflow means checking two documents, not one: Apple's list tells a rigger which facial coefficients exist to potentially map, and the receiving app's own input table tells them which of those the software actually exposes for mapping to a Live2D parameter, on which device. A rig built assuming a coefficient the receiving app does not expose will simply not move; the documented input table, not the ARKit reference alone, is the real constraint on setup.

Keeping the creator in control

Because Apple's own documentation is explicit that left and right in a coefficient name refer to the face's own left and right, not the viewer's, a performer's expressions map predictably once that naming convention is understood, which is worth stating plainly as an editorial point: getting a mapping backwards is a documented naming-convention error, not a tracking failure, and is fixable without new hardware.

• Which of Apple's documented coefficients does your tracking app actually expose as an input?
• Does your device meet the documented hardware requirement for that tracking path?
• Have you verified left and right mapping against the stated face-relative naming convention?

No single company's page tells the whole story here; the workflow only makes sense read across both the platform's specification and the performance app's own documented input list.