Test the biometric authentication

In MagicPod's cloud environment, you can use the "Pass biometric authentication" and "Fail biometric authentication" commands. 

With these commands, you can make biometric authentication succeed or fail without using an actual fingerprint or face, which makes it easy to test how your app behaves in each case.

Table of Contents

• Prerequisites
• How to use the commands
• Additional information
  • iOS
  • Android
  • Passkey authentication

Prerequisites

How to use the commands

In the test run settings, select "Use" for "Biometric authentication."

While the biometric authentication dialog is displayed on the cloud device, run the "Pass biometric authentication" or "Fail biometric authentication" command to test the app's behavior in each case.

Note that passkey authentication can also be made to succeed or fail with these commands.

Additional information

iOS

• The biometric authentication method (Face ID or Touch ID) depends on the device model. Devices without a Home button (such as the iPhone 17) mainly use "Face ID", while devices with a Home button (such as the iPhone SE) use "Touch ID".
• Due to the behavior of the iOS Simulator, the following dialog is displayed during face authentication. 

Example: iOS 26.4, iPhone 17

• It can be used with Apple's standard libraries, such as Local Authentication.

Android

• While the authentication dialog is displayed, the UI may become completely black due to a security feature ("FLAG_SECURE") (reference). UI elements can still be retrieved, so testing itself can proceed.

A case where the UI becomes completely black when the authentication dialog is displayed

Screen of the Android Emulator itself in this situation

• Android standard libraries such as the fingerprint authentication-based BiometricPrompt and BiometricManager are supported.

Passkey authentication

• To test passkey authentication, run the "Pass biometric authentication" command while the passkey dialog is displayed in the app (or browser), and then check that the screen after login is displayed.
• On iOS, the label of the button in the sign-in dialog changes depending on the number of passkeys saved on the device. To make the step work in both cases, specify the button by its accessibility ID (ASAuthorizationControllerContinueButton) instead of its label.
• On Android, to use passkeys in Chrome and other apps, you need to sign in to a Google account on the device. Passkeys you create are saved to Google Password Manager and synced to other cloud devices through the Google account. When you create a test, note the following:
  • A new cloud device is used for each run. Add the steps to sign in to the Google account to your test. Some screens may or may not appear during sign-in, so we recommend handling them with conditional branches.
  • When you use a passkey saved on another device, you are asked to enter the screen lock (PIN) of that previous device to confirm the sync. The screen lock PIN of cloud devices is "1234".
  • If your test creates a passkey with a new user on each run, the number of passkeys saved in the Google account grows with each run. This does not affect the test, but cleaning them up regularly makes them easier to manage.
  • Because the test enters the Google account password, we recommend using a Google account only for testing.