Mobile SDK Testing Guide

Overview

This page explains how to validate a Utiq Mobile SDK integration before moving to production.

The goal of testing is to confirm that:

• consent handling works as expected

• Utiq identifiers are only requested when the user has the correct consent status

• consent changes are reflected correctly in the app

• the integration continues to behave correctly across normal app usage, including app close and reopen

Before You Start

Before testing, please make sure that:

• the Utiq Mobile SDK has been integrated into the app

• the app is connected to a Consent Management Platform (CMP), where applicable

• you have access to a suitable test build

• you can observe app behavior, logs, and network traffic if needed

What Should Be Validated

The following areas should be covered during integration testing:

• SDK initialization

• consent-enabled behavior

• consent-disabled behavior

• consent changes made outside the app

• repeat usage and app relaunch behavior

• cached and refreshed identifier handling

Recommended Test Scenarios

• The exact test steps may differ depending on the app’s consent flow and UI.

• If the app has a custom consent experience, the scenarios below should still be validated in the equivalent user journey.

1. First launch and SDK initialization

How to test

1. Install the app on a test device.

2. Open the app for the first time.

3. Let the SDK initialize.

4. Close and reopen the app.

Expected result

• the app starts normally

• the SDK initializes successfully

• reopening the app does not cause errors or unexpected behavior

2. Consent granted -> identifiers can be requested

How to test

1. Open the app in a clean state.

2. Grant the relevant Utiq consent in the CMP.

3. Trigger the app flow that uses the Utiq SDK.

Expected result

• the app is able to request Utiq identifiers successfully

• the expected Utiq-enabled app behavior becomes available

• no errors are shown to the user

3. Consent not granted -> identifiers are not requested

How to test

1. Open the app in a clean state.

2. Do not grant Utiq consent, or explicitly reject it.

3. Trigger the same app flow that would normally use the Utiq SDK.

Expected result

• the app does not continue with Utiq identifier usage as if consent had been granted

• the app behaves correctly for a non-consented user

• no Utiq-enabled functionality is activated incorrectly

4. Consent withdrawn after previously being granted

How to test

1. Grant Utiq consent and complete a successful identifier-related flow.

2. Afterwards, withdraw Utiq consent.

3. Return to the app and repeat the relevant flow.

Expected result

• the app recognizes that consent is no longer valid

• the app no longer behaves as if Utiq consent is active

• any Utiq-dependent state is updated accordingly

5. Consent withdrawn outside the app

This scenario is important for cases where the user revokes their Utiq consent outside the mobile app, e.g. using consenthub

How to test

1. Grant consent in the app and complete a successful flow.

2. Revoke the Utiq consent using consenthub (make sure you use the same network connection).

3. Return to the app and trigger the same flow again.

Expected result

• the app detects that the Utiq consent was revoked

• the app switches off the Utiq consent in the CMP

• the app does not do try to fetch Utiq IDs

6. Repeat use and network behavior

When testing repeated identifier requests, developers should be aware that network activity may vary depending on how much time has passed since the previous fetch.

For example:

• if the next fetch happens within a short period, such as less than 10 minutes, the SDK may reuse previously available valid data

• if more time has passed, the SDK may perform network calls again to refresh the data

How to test

1. Complete a successful Utiq-enabled flow.

2. Repeat the same flow again shortly afterwards.

3. Repeat it again after a longer interval, based on your test setup.

Expected result

• the integration should continue to work correctly in both cases

• it is expected that the user may or may not see network calls, depending on the time between fetches

• differences in network activity alone should not be treated as an issue if the functional result is correct

7. App close, reopen, and resume behavior

How to test

1. Grant consent and complete a successful Utiq-enabled flow.

2. Put the app into the background and bring it back.

3. Fully close the app and open it again.

4. Repeat the same flow.

Expected result

• the app continues to behave correctly after resume

• the app also behaves correctly after a full restart

• consent status and Utiq behavior remain aligned across normal app lifecycle events

8. Clean-state recovery

How to test

1. Use the app and complete a successful Utiq-enabled flow.

2. Reset the app state using your normal QA approach.

3. Start the app again and repeat the integration flow.

Expected result

• the app can recover cleanly from a reset state

• the SDK continues to work correctly after reset

• the integration behaves like a fresh installation where expected

Minimum Recommendation Before Production

Before going live, Utiq recommends confirming at least the following on both Android and iOS:

• the SDK initializes successfully

• the app behaves correctly when consent is granted

• the app behaves correctly when consent is not granted

• the app responds correctly when consent is later withdrawn

• the integration still works correctly after app close and reopen

• repeat usage remains stable and consistent