TypingDNA on Mobile Phones: Best Practices for Browser and Native Integrations

Typing biometrics behave differently on phones than on laptops/desktops, mainly because users grip the device in many ways and mobile operating systems protect motion sensors.

This article explains how to build a reliable mobile experience for both browser-based and native integrations.

1. Major differences between Mobile Browser and Native integrations

Our latest recorders are linked in the API documentation with sources available on our GitHub page. TypingDNA captures typing events using an overlay approach (draw-over-apps), which may be restricted on some devices, blocking access to keyboard data. For this reason, browser-based integration tends to offer broader compatibility. As long as telemetry permission is granted, we recommend using the browser approach whenever possible.

2. Posture first: lock to position 3

The API recognises six mobile typing positions (see API docs). Typing patterns collected in one position will not match those typed in another. We recommend guiding users to Position 3—holding the phone with both hands and typing with thumbs—because it is the most common grip, produces consistent motion data, and delivers the highest match accuracy.

Recommended flow

1. Show a short text and image asking the user to hold the phone with both hands and type with thumbs.
2. Call /verify with post param position_only=1 ; the response returns "positions":[3] when the user complies.
3. If the first value is not 3, prompt the user to try again. After several retries, if the user consistently types in another position (e.g. position 2), you may allow it—but you must ensure they always use that position, including at verification. This adds implementation complexity. In most cases, enforcing and sticking to position 3 is simpler and more robust.

3. Capture settings that work

4. Why motion sensors matter

Accelerometer and gyroscope data add fine-grained timing cues that improve model accuracy and allow posture detection. Each keystroke produces subtle motion, helping distinguish between typing positions.

• If motion is present: The engine can identify typing position and extract enhanced timing signals. This improves accuracy, especially on shorter texts.
• If motion is absent: Authentication still works, but posture cannot be detected and scoring accuracy may decrease. False accepts or rejects may become more likely depending on conditions.

In mobile browsers:

• On iOS, you must call DeviceMotionEvent.requestPermission() before motion data becomes available, and you can only call it on a user gesture (which includes click), otherwise Apple will not enable motion sensor data until next browser restart. Prompt the user before typing starts and cache the response (e.g., in sessionStorage).
• On Android, motion access is usually granted by default, but can be disabled manually in browser settings (rare). You can add a brief motion listener or check the pattern string for motion segments to confirm access.

In native apps:

• Motion access is typically granted silently after install. You can launch a background listener to confirm telemetry is working and notify the user if not. At launch, initiate a short-lived motion listener—about five seconds using SensorManager on Android or CMDeviceMotion on iOS.

For both browser-based and native apps, in the rare case when no motion sensor data arrives, you have 4 options:

1. Ask the user to enable “Motion & Fitness” access in system settings.
2. Proceed with TypingDNA authentication anyway at reduced accuracy.
3. Proceed with TypingDNA but use a stronger prompt (desktop-like, 35-50 chars of strength 8+), at reduced accuracy (but better than option 2).
4. Fall back to another authentication factor until sensors are available.

Note that IF integrated correctly there should be no issues getting motion data.

5. Separate desktop and mobile logic

Desktop patterns are never compared with mobile ones. However, we propose that you separate the desktop/mobile logic if you plan to have users joining your login-based area from both environments:

A single user ID can hold both count (desktop) and mobilecount (phone) values. Always check the right counter before verifying. If you want to verify a user on mobile and their mobilecount == 0, you must first enroll that user (same applies to desktop). Since multiple mobile typing positions can be saved, a mobilecount greater than 0 doesn’t necessarily mean the user was enrolled in the same position you want to verify. That’s why we strongly recommend:

1. Only enroll and verify position 3 mobile patterns, and/or
2. Track position data or context on your end so you can manage consistency across sessions

If you only store position 3 patterns, the mobilecount will directly reflect the number of usable patterns, making verification simpler and more predictable.

6. End-to-end checklist

1. Pick and hard-code a 14–40 character sentence
2. Embed the JavaScript recorder in your mobile web page or the Android/iOS recorder in your app
3. Show the position 3 image and posture prompt
4. Call /verify with post param position_only=1 until posture 3 is detected
5. Enroll/save two initial patterns with /save
6. Switch to /verify with Auto-enroll ON, and quality=2 (Optimized for Balanced)
7. Optionally, watch the device_similarity value to catch device switches

7. Wrap-up

TypingDNA works very well on mobile if you guide posture and capture motion. Use SameText with type: 2, balanced quality, and a strong, fixed phrase. Always enforce position 3 and let auto-enroll silently build a strong profile. Keep mobile and desktop logic separate, and mobile pass rates will match your desktop benchmarks with minimal effort.

If you’re interested to see a mobile demo integration please contact us and we’ll show you a working browser-based demo that works according to the suggestions in this article.

For any related questions, feel free to contact us.