Test and Troubleshoot

React Native SDK 1.1.1: uses native SDKs 1.1.0 and FCM token registration on iOS and Android. Existing 1.0.x integrations should also follow the updated identity and profile instructions below.

Use this checklist after completing your chosen setup path and shared JavaScript integration.

Work through the first test in stages. This helps you tell whether a problem is in startup, connectivity, push delivery, or navigation.

Your first successful test

1. Open the newly built app on a real phone and confirm init() succeeds. This checks native startup and the JavaScript bridge.
2. Identify a test customer and send one event. Confirm both in AlgorithmX; a successful SDK call alone does not confirm network delivery.
3. Confirm that the app's FCM registration token is registered, on iOS as well as Android. Connect its project's service-account JSON in Settings → In-App Integration.
4. Publish an eligible in-app campaign, then open or return to the app. Confirm the automatic GET and rendered campaign.
5. Check the campaign impression, close it, and check the close result. You have now tested the journey in both directions.
6. Allow visible notifications and send a plain notification using the dashboard test form, first with the app in the background. Then send an AlgorithmX campaign and check that its tap opens the intended screen once, including when the tap launches the app.

You can now expand to the release checklist below. Firebase accepting the test confirms the send request was accepted, not receipt on the phone or campaign interaction reporting.

In-app campaigns

Production backend support is pending: the .NET in-app delivery route must be implemented as described in AlgorithmX issue #207. Current device tests use in-app-test-backend; no .NET implementation is included in this SDK update.

In-app campaigns use the API in SDK 1.1.0. Initialise the SDK and identify a signed-in customer; no campaign-fetch code, silent push, push token, or notification permission is needed for this flow.

1. The SDK bootstraps its anonymous profile and device automatically.
2. On startup or returning to the foreground, it calls GET /api/v1/inAppViews?language=...&customerId=....
3. The backend checks the customer's segment, campaign publication/schedule and language, and returns eligible inline HTML, CSS, JavaScript, translations and variation parameters.
4. The SDK selects a stable variation, applies priority, frequency, expiry and app-enter delay, and displays at most one campaign per visit. The template supplies its close button; Android also supports Back.

The SDK supplies X-Partner-Id, its persistent UUID in X-Anonymous-Id, and the installation UUID in X-Device-Id. Before login, customerId is the anonymous UUID. After identify / identifyUser, it is your application's account ID, stored by AlgorithmX as ExternalId. The backend resolves the internal profile ID; your app does not pass an AlgorithmX profile UUID. Identification, logout and account changes invalidate old campaign requests and content. Signed-in variation selection and local display history use the account ID.

Language defaults to the device/app language. Override it only when your app has its own language selector:

AlgorithmX.setInAppLanguage('ar');

An empty language override restores the automatic default. Arabic, Hebrew, Persian and Urdu translations use RTL layout; text and placeholder translations are applied from the template's builderState.translations.

First check: publish an active campaign that matches your test customer's segment and language, open the app, and confirm the GET request and impression. Leave the app and return to check another visit. Impressions, clicks, submits, copies and closes are logged through POST /api/v1/Event/Log as inAppViewInteraction; campaign and variation UUIDs remain strings.

The automatic mobile flow supports app-enter campaigns and an optional time delay. Browser URL/scroll/exit/inactivity rules and custom triggers are excluded by the backend from this automatic feed. Display history is stored on the installation; this is not a global cross-device frequency counter.

GET requests follow queued identity/profile POSTs. When identity is still processing (409), the SDK retries up to three times, and it retries again when connectivity returns or the app re-enters the foreground. Normal event/profile requests remain fire-and-forget. The old silent-push algoTriggerWebview is ignored. Visible push notifications retain their separate integration.

Release checklist

Use real Android and iOS phones and a test customer. Test release builds, not only debug builds. On iOS, repeat the main checks with a TestFlight build, because store builds use a different Apple push server.

• Update while logged in: install your current store version, log in, then update to the new build. The customer is recognized without logging in again.

• Login, restart, logout, second account: events use the right customer each time. No campaign from the first account appears for the second.

• Your existing notifications still work exactly as before.

• AlgorithmX notification with the app open, in the background, and closed: a tap opens the right screen once, also when the tap starts the app.

• Each deep link, custom action, and button opens the right screen.

• In-app campaign: the SDK fetches it and it appears when the app opens and closes with its close button.

• Notifications turned off: verify API-based in-app campaigns on your devices; visible alerts should remain disabled.

• Events appear for the customer in AlgorithmX.

• Token changes: a refreshed token reaches AlgorithmX, and reinstalling the app registers its new token.

• Expo: clean prebuild preserves SDK startup and the chosen push integration. The Expo Notifications plugin alone does not register the iOS FCM token required by the current sender.

• Offline events: the app handles lost delivery without treating SDK tracking as an order/payment record.

Validation status of this SDK update

On October 18, 2026, native iOS SDK 1.1.0, Flutter 1.1.1, and React Native 1.1.1 were installed from their published packages, built, and run on a physical iPhone 13 with separate Firebase app registrations. The shared service-account dashboard connection and FCM test notification flow were confirmed working in project testing. The wrappers retain native SDK 1.1.0; the React Native Firebase adapter's 1.1.1 update adds iOS token registration and refresh support. These checks used development-signed iOS builds and do not establish TestFlight delivery or iOS FCM support for the unchanged Expo Notifications plugin.

The following checks describe earlier identity/in-app releases and historical APNs testing; their direct APNs setup is not the current sending configuration.

The 1.1.0 release has local native identity/event contract tests, React Native bridge/type tests, Flutter tests and analysis, and a website production build. These checks cover UUID persistence, login/logout/account switching, supported profile mapping, API request headers/query encoding, inline assets, fractional allocation, translations and RTL. The local test backend's 18 contract tests cover identity/profile bodies, API query/header validation and event/interaction transport. Production campaign processing is tracked in AlgorithmX issue #207; the SDK update includes no .NET implementation.

On October 13, 2026, SDK 1.1.0 passed physical-device checks on a Samsung Galaxy A51 (Android 13) and iPhone 13 (iOS 26.6.2), using local SDK sources and in-app-test-backend. Native Android/iOS, Flutter, React Native and Expo 55 were exercised through real apps. Checks covered automatic identified customer/language queries, inline campaigns and Close buttons, custom events, account switching and restart behavior. Native SDK tests additionally covered supported profiles, logout, Arabic/RTL and submit; Expo's logout control was also verified. The physical React Native iOS release app built and passed its UI test. These fixture results do not verify production segmentation, identity/profile merges, RabbitMQ processing or APNs/FCM delivery. The following paragraphs describe earlier releases.

React Native bridge tests, Firebase adapter tests, type checks, and Android/iOS simulator release builds were checked locally. Expo verification covers SDK 55. An Expo 55 app using published SDK 1.0.2 was also built and launched on an iPhone 13 on October 6, 2026: identity, events, APNs token registration, silent campaign receipt, and campaign impression reporting were verified against a local test backend.

SDK 1.0.3 adds the general-event transport at /api/v1/Event/Log. Native event-contract tests, React Native bridge tests, Flutter tests, and published package contents were verified for this release. The October 6 phone checks above cover SDK 1.0.2; they do not establish live device delivery for 1.0.3.

That iPhone check used development signing and APNs sandbox. It does not establish Android FCM delivery, every notification action, or TestFlight delivery for your app. Complete the device checklist above with your own credentials and release builds.

Troubleshooting

For a local test server, use the computer's network address rather than localhost on the phone. Put both devices on the same network, allow iOS Local Network access, and use HTTPS or your app's development HTTP settings. After fixing connectivity, send the event again or relaunch to repeat your startup calls; failed offline events are not replayed.

API endpoints

The SDK sends these requests for you when you use its APIs. Keep this reference handy when checking your server logs or discussing the integration with your backend team.

These paths are relative to your configured apiBaseUrl. SDK API requests include the x-partner-id header.

trackEvent posts a one-event array to /api/v1/Event/Log: [{ eventType, data, timestamp }]. data contains the supplied properties or {}; timestamp is ISO 8601 UTC. In SDK 1.1.0, X-Anonymous-Id always contains the SDK-generated anonymous UUID, including after login. Identity requests use anonymousId and trustedIdentifiers, not fingerprintDevice, previousFingerprintDevice, or an attributes object on the wire. The SDK separates profile fields into /Customer/Ingest and adds X-Anonymous-Id and X-Device-Id to that request. All requests include X-Partner-Id.

API-based in-app view interactions use /api/v1/Event/Log with eventType: "inAppViewInteraction". Manual previews, visible-push interactions, token registration and notification status retain their existing transport contracts and need separate backend endpoint support. API templates are inline; manual preview HTML and notification images use GET requests to supplied URLs.

API reference

Existing low-level push methods remain available for integrations that already use them. Prefer the ownership-checking helpers in the new guides.

Create campaigns with In-App Push Campaigns and In-App View Campaigns.