Overview

Mobile apps present a distinct set of security challenges compared to browser-based Web Apps. A mobile device is personal, portable, and frequently used in unsecured environments. Users access sensitive data on untrusted networks, share devices with family members, and may install apps from untrusted sources that could intercept network traffic or read the device screen.

UnifyApps Mobile Security settings address these challenges at the app level, giving your security and compliance teams controls over the mobile data surface that are not applicable to web deployments. These settings are configured in Builder Settings → Mobile → Security, and most require a new mobile build to take effect after being changed.

Note: Mobile Security settings apply to Mobile App types only. Web Apps running in a browser do not have access to device-level security capabilities like biometric authentication or certificate pinning. Configure browser-level security for Web Apps through the Runtime & Access Control settings.

Security Hardening Checklist

Tip: Before deploying a Mobile App with sensitive data, verify the following settings are configured:

Screenshot Prevention

Screenshot prevention blocks the device's screenshot and screen recording functions while the app is in the foreground. When a user attempts to take a screenshot, the resulting image is blank (iOS) or shows a solid black frame (Android) rather than the app's content. Screen recording tools are similarly blocked from capturing the app's display.

Configuration

Setting	Location	Default
Enable Screenshot Prevention	Builder Settings → Mobile → Security → Screenshot Prevention	Off

When enabled at the app level, screenshot prevention is active on all pages in the app. For apps where most pages contain public or non-sensitive content but a few pages contain sensitive data (for example, a financial summary or a personally identifiable employee record), use page-level overrides to enable prevention only on the sensitive pages. See Per-Page Overrides.

Limitations

Screenshot prevention does not prevent an attacker from pointing a second camera at the device screen. It is a deterrent for casual sharing, not a guarantee of secrecy.
On some Android devices and OS versions, the effectiveness of screenshot blocking depends on the system's rendering implementation. Test on your target device fleet.
External screen mirroring (AirPlay, Miracast) is blocked by iOS when screenshot prevention is active. Inform users who may use screen sharing in legitimate contexts such as presentations.

Biometric Lock

Biometric lock requires the device user to authenticate with Face ID, Touch ID, or Android fingerprint/face recognition before the app can be used after a period of inactivity or a return from background. This prevents an unattended device from being accessed by an unauthorised person who picks it up.

Configuration

Setting	Description	Default
Enable Biometric Lock	Toggle to require biometric authentication after background timeout.	Off
Background Timeout	Duration (in seconds) the app can be in the background before requiring re-authentication on next open. Set to 0 to require authentication every time the app is foregrounded.	300 seconds (5 minutes)
Fallback Authentication	What happens when biometrics are unavailable or fail. Options: Device PIN/passcode (default) or Deny access (blocks the app if biometrics fail — use only in high-security environments where device PIN fallback is unacceptable).	Device PIN/passcode

User Experience Considerations

A background timeout of 0 (requiring authentication every foreground) is very disruptive for apps that users switch in and out of frequently — for example, field apps where users frequently switch to a camera app and back. Calibrate the timeout to match typical usage patterns. A 5-minute timeout balances security with usability for most field-worker scenarios; increase to 2 minutes for healthcare or financial apps handling highly sensitive records.

Certificate Pinning

Certificate pinning restricts the app to accepting only a specific TLS certificate (or certificate public key) for API connections, rather than trusting any certificate issued by a recognised CA. This prevents man-in-the-middle (MITM) attacks on corporate networks where a network proxy might present a legitimate but unexpected certificate.

Configuration

Setting	Description
Enable Certificate Pinning	Toggle to enable. When on, only connections to hosts presenting the pinned certificate are allowed.
Certificate File	Upload your API server's TLS certificate (DER or PEM format). The certificate's public key is extracted and pinned.
Pinned Hosts	List of hostnames to apply pinning to (e.g., `api.yourcompany.com`). Other hosts (CDNs, analytics, etc.) are not subject to pinning.

Warning: Certificate rotation requires a new build. When your API server's TLS certificate is renewed or replaced, you must upload the new certificate in Builder Settings and submit a new mobile build before the old certificate expires. If the pinned certificate expires and a new build is not deployed in time, all users of the published app will lose API connectivity. Plan certificate renewals well in advance and coordinate with your DevOps team.

Root/Jailbreak Detection

Rooted (Android) or jailbroken (iOS) devices have bypassed the operating system's security model, potentially allowing malicious apps to access data from other apps, including UnifyApps app data and tokens. Root/jailbreak detection checks for common indicators of a compromised device at app launch.

Configuration

Setting	Description	Default
Enable Detection	Toggle to check for root/jailbreak indicators at app launch.	Off
Action on Detection	Warn: displays a warning dialog but allows the user to continue. Block: shows an error and prevents the app from launching on the device.	Warn
Custom Warning Message	Optional message shown to users when a compromised device is detected. Include guidance such as a link to your IT helpdesk.	Platform default message

For apps handling regulated data (healthcare records, financial transactions, payment data), set the action to Block. For internal productivity apps where rooted devices are used by power users with legitimate reasons (developers, IT staff), Warn is a less disruptive choice that still informs users of the security risk.

Secure Storage

Secure storage ensures that sensitive data cached locally on the device — including authentication tokens, session credentials, and any personally identifiable information stored by offline-capable data sources — is encrypted using the platform's hardware-backed key store.

Platform	Storage Mechanism
iOS	iOS Keychain — hardware-backed encrypted storage with access control policies. Data is inaccessible to other apps and survives app reinstallation but is cleared on device wipe.
Android	Android Keystore System — uses the device's hardware security module (when available) or software emulation to encrypt key material. Data is bound to the app's signing key.

Secure storage is enabled by default and cannot be disabled for authentication tokens. For offline cached data, the default is to encrypt all cached values using a key stored in the device keystore. This setting is not configurable at the page or data source level — all local storage by the UnifyApps shell uses the secure store.

Note: Secure storage and app backup. By default, keys in the iOS Keychain and Android Keystore are marked as non-exportable and not included in cloud backup snapshots. This means authentication tokens do not carry over to a new device restore from backup — users must re-authenticate on a new or reset device. This is a deliberate security property, not a bug.

Remote Wipe

Remote wipe allows an administrator to clear all local app data from a user's device remotely — including cached data, stored credentials, and the offline write queue. The device does not need to be online at the time the wipe is issued; the wipe command is queued and executed the next time the device connects and the app opens.

Triggering a Remote Wipe

Navigate to Admin Console → Users → [user] → Devices.
Locate the device registered to the user.
Click Remote Wipe.
Confirm the action in the confirmation dialog. The wipe command is queued immediately.

When the device next opens the app with connectivity, the wipe executes automatically. The user is signed out and the app returns to its initial unauthenticated state. They must sign in again and, if offline mode was in use, the local cache is rebuilt from the server on their next session.

Scope of Remote Wipe

Remote wipe clears data created by the UnifyApps app on the device. It does not:

Wipe other apps on the device.
Delete files the user downloaded through the app to the device's general storage (Photos library, Downloads folder).
Uninstall the app from the device — the app remains installed but is reset to a logged-out state.

For full device wipe in a device loss or theft scenario, use your organisation's MDM (Mobile Device Management) solution, not this feature.

Clipboard Protection

Clipboard protection blocks copy-and-paste operations on designated sensitive form fields. When enabled on a field, users cannot select text in that field and copy it to the device clipboard. This prevents sensitive data — such as PII, account numbers, or temporary passwords — from being accidentally or deliberately pasted into other apps or shared via messaging.

Configuration

Clipboard protection is configured at the component level, not at the app level. To enable it on a form field:

Select the Input, Text Area, or Password field component in the Builder.
Open the Properties panel → Security section.
Toggle Clipboard Protection on.

Apply clipboard protection to fields that display or accept: National ID numbers, passport numbers, social security numbers, credit card numbers, bank account numbers, passwords and PINs (though Password fields typically disable copy by default), and any other regulated personal identifiers.

Per-Page Security Overrides

Some security settings that are configured at the app level can be overridden at the page level. This allows you to apply a stricter or more lenient policy on specific pages without changing the app-wide default.

Setting	App-Level Default	Per-Page Override Available
Screenshot Prevention	On or Off	Yes — override in Page Settings → Security → Screenshot Prevention
Biometric Lock	On or Off, with timeout	No — applied uniformly across the app
Certificate Pinning	On or Off, per host	No — applied to all API calls regardless of page
Clipboard Protection	Not applicable (field-level only)	Configured per component, not per page

Enabling a Page-Level Screenshot Override

Select the page in the page switcher.
Click the page settings icon (gear icon next to the page name).
Select Security.
Set Screenshot Prevention to On (to enforce on this page regardless of app default) or Off (to allow screenshots on this page even if the app default is On).

The most common use case is an app with screenshot prevention off at the app level (most pages show non-sensitive data) with page-level overrides enabling prevention on specific high-sensitivity pages such as a payroll summary or a medical record detail page.

Compliance Applicability

The Mobile Security features described in this guide help address requirements from the following frameworks. Your compliance and legal team should confirm applicability to your specific context — UnifyApps documentation is informational, not a compliance certification.

Framework	Relevant Mobile Security Controls
HIPAA	Secure storage (data at rest encryption), biometric lock (access control), remote wipe (device disposal and loss), screenshot prevention (safeguards against inadvertent disclosure)
PCI-DSS	Certificate pinning (secure transmission), clipboard protection (prevent cardholder data leakage), root/jailbreak detection (secure environment requirement), remote wipe (device compromise response)
SOC 2 Type II	Biometric lock (logical access controls), secure storage (data protection), root detection (system integrity)
Enterprise MDM policies	Remote wipe (complements MDM selective wipe), certificate pinning (network security), biometric lock (device access policy enforcement)

Frequently Asked Questions

Does enabling biometric lock mean users cannot access the app if their biometrics are not enrolled on their device?

It depends on the Fallback Authentication setting. If set to Device PIN/passcode (the default), users whose devices have biometrics available but no enrolled biometric data are prompted to use their device PIN or passcode instead. If biometrics are not enrolled and no device passcode is set, the app falls back to the platform's default behavior, which may allow entry without authentication — configure a device passcode requirement through your MDM policy to prevent this gap. If Fallback Authentication is set to Deny access, users without enrolled biometrics are blocked from opening the app entirely. Use this setting only when your security policy requires it and you have a process for handling enrolled-biometric-less devices.

Can users bypass screenshot prevention by using the iOS or Android accessibility features such as AssistiveTouch?

Screenshot prevention in UnifyApps uses the platform's native mechanisms — on iOS this is the UIScreen.isCaptured flag and the UIView.makeSecure() API; on Android it is the WindowManager.LayoutParams.FLAG_SECURE flag. These mechanisms block the native screenshot function and screen recording. Some accessibility-based methods, such as AssistiveTouch on iOS, also trigger the screenshot mechanism and are blocked. However, physically capturing the screen with an external device (a second camera, for example) is not preventable by any software mechanism. Screenshot prevention is a meaningful deterrent for accidental or casual leakage, not a substitute for physical access controls when handling the most sensitive data.