Skip to main content
The Vitals SDK measures heart rate, HRV, and breathing rate using photoplethysmography (PPG) — the same optical technique used inside wrist-worn fitness trackers and pulse oximeters. The key difference is the measurement site: rather than a wrist or finger clip, the user simply places their fingertip directly over the phone’s rear camera and flash. This single design decision produces pulse signals that are dramatically cleaner and more accurate than any face-camera approach, and requires no hardware beyond the phone the user already owns.

​
The Physics of a Finger Scan

Every heartbeat pumps a small surge of blood into the capillaries of the fingertip. When a bright LED flash shines directly into the skin, that rhythmic change in blood volume alters how much light is absorbed and reflected back to the camera sensor. The SDK reads these light-intensity changes frame by frame and reconstructs the full pulse waveform with sub-millisecond timing resolution.

​
Why a Fingertip Beats a Face

Face-based camera HRV (rPPG) is an active research area, but it carries a fundamental physics disadvantage that no algorithm fully overcomes.

Face Scan

The pulse signal comes from faint color shifts in reflected ambient or screen light across a large area of skin. Room light fluctuations and even small head movements can easily exceed the pulse signal itself, forcing heavy filtering that smears beat timing and inflates HRV error.

Finger Scan

The fingertip is pressed directly against a bright, steady flash LED — the brightest light source on the phone — with no air gap. The resulting pulse amplitude is approximately 6× larger than a face signal, representing over 30× the signal power. High-frequency noise that corrupts beat timing on a face scan is buried far below the pulse in a finger scan.
The accuracy difference is measurable in published literature. The best reported face-scan HRV (RMSSD) error is 10.5 ms (Bioengineering, 2023, UBFC-rPPG dataset). The Vitals SDK achieves 3.4 ms measured against a Polar H10 chest strap — nearly three times more accurate. This is a physics outcome, not just an algorithm one.
The face-scan and finger-scan figures come from different studies with different participants, cameras, and reference devices and are therefore not a direct head-to-head comparison. They illustrate the order-of-magnitude difference in the underlying signal quality.

​
The 60-Second Scan, Step by Step

The SDK is built around five public types: VitalsScan (start/stop the session), ScanDelegate on iOS and ScanCallback on Android (live progress and completion events), VitalsResult (the completed metric values), QualityTier (accepted or withheld), and ScanDiagnostics (per-scan signal detail). The steps below map to these types.
1

User Places Finger Over Camera

Your app prompts the user to cover the rear camera lens and flash completely with their fingertip, applying light, steady pressure. Call VitalsScan.start() to begin the session. The SDK immediately begins receiving camera frames and evaluating signal quality.
2

Real-Time Signal Quality Check

During the first few seconds, the SDK evaluates whether the finger is correctly positioned and whether the signal-to-noise ratio is sufficient to produce reliable results. If the finger is not covering the flash or the signal is too noisy, the SDK emits live guidance events through ScanDelegate (iOS) or ScanCallback (Android) — for example, prompting the user to reposition or reduce movement.
3

PPG Waveform Capture

Once a quality signal is established, the SDK captures the full 60-second photoplethysmography waveform. Each heartbeat appears as a distinct peak in the light-intensity trace. The SDK timestamps each peak with sub-millisecond precision to build the sequence of RR intervals (the gaps between beats) that all HRV metrics are derived from.
4

On-Device Signal Processing

At the end of the 60 seconds, the SDK runs its full deterministic signal-processing pipeline entirely on the device. No frames are saved. No data leaves the phone. The pipeline extracts beat-to-beat intervals, applies artifact rejection, and computes all six metrics from the cleaned RR interval series.
5

Quality Gating

Before returning a result, the SDK evaluates the overall reading quality. Readings that fall below the acceptance threshold are withheld rather than returned with a misleading value — your ScanDelegate or ScanCallback receives a QualityTier of withheld in this case. In the validation study, 3.3% of readings were withheld for this reason.
6

Result Delivered to Your App

Your ScanDelegate or ScanCallback completion method receives a VitalsResult containing all six metric values, a QualityTier, and a ScanDiagnostics object with per-scan signal detail. Your app can display results immediately — no network round-trip required.

​
On-Device Processing in Detail

The SDK’s signal-processing engine is written entirely in native Swift (iOS) and Kotlin (Android). It uses no machine learning models, no neural networks, and no cloud inference. Every computation is deterministic: the same input frames always produce the same output metrics, on every device, every time.
Machine learning models introduce several challenges for SDK developers:
  • Non-determinism. Model outputs can vary across hardware, OS versions, and runtime conditions even with identical inputs, making bugs difficult to reproduce.
  • Model drift. Model updates can silently change metric values between SDK versions, making longitudinal user data inconsistent.
  • Size and latency. On-device inference models add tens to hundreds of megabytes and introduce variable latency depending on device capability.
  • Auditability. A deterministic algorithm can be validated mathematically; a model’s behavior must be characterized empirically across every target population.
The Vitals SDK avoids all of these issues. The processing chain from raw camera frames to metric values is a fixed, auditable sequence of signal-processing operations with no stochastic components.
The SDK does not store or transmit:
  • Raw camera frames
  • PPG waveform samples
  • RR interval sequences
  • Any personally identifiable information
The SDK returns to your app:
  • Computed metric values (heart rate, RMSSD, SDNN, Baevsky stress index, Poincaré SD2:SD1, breathing rate)
  • A quality tier for the reading
  • Diagnostic flags used to explain withheld or low-confidence readings
What you do with these values — whether you store them, display them, or discard them — is entirely under your control.

​
Live Guidance During the Scan

The SDK emits real-time status events throughout the 60 seconds that your UI can subscribe to. These events describe the current signal quality state in terms your app can display directly to the user, such as asking them to keep their finger still, apply more pressure, or ensure the flash is fully covered. This guidance loop is the primary mechanism by which the SDK achieves consistent results across the wide range of users and lighting conditions found in real-world use.
Showing the live guidance feedback prominently in your scan UI — rather than hiding it — is the single most effective step you can take to improve your users’ success rate on the first attempt.

​
Supported Hardware

The SDK runs on hardware available on virtually every modern smartphone, requiring only the rear camera and rear flash LED that ship on every flagship and mid-range device. Coverage figures from Statcounter, August 2026.