Mobile In-App SDK Troubleshooting

Use this page when you integrate or debug the iOS or Android Engage Mobile SDK. For audience, Launch, and campaign targeting issues, see Campaign Troubleshooting.

Check the following items:

1. Initialize the Core SDK before calling any Engage API.
2. On iOS, call TDEngage.install() after Core SDK initialization. On Android, Mobile In-App rendering is bundled in td-android-sdk and needs no install step.
3. Configure the Personalization endpoint and token.
4. Configure the database and table used for trigger requests.
5. Confirm that the preview artifact matches the platform and release-specific installation instructions.

For the required values and initialization examples, see Set Up Mobile In-App Campaigns and the SDK API and Event Reference.

Verify that the URL is HTTPS, reachable from the device, and does not require credentials that the WebView cannot provide. Check redirects, hosted assets, and the page's responsive viewport.

Inspect device logs for network, certificate, or WebView errors. Test the URL outside the campaign flow to distinguish hosting problems from Personalization or SDK problems.

Add a close, back, or completion action to the hosted page. Hosted Pages does not use the Modal or Banner close-button settings.

A page that cannot provide an exit path can leave the SDK-owned full-screen WebView open.

Set profileContext before displaying the message and verify that every value is JSON serializable. Clear or replace stale context when the signed-in customer changes.

Do not put API keys, Personalization tokens, passwords, or unnecessary personal data in the context.

Check whether the URL is an app-owned custom scheme or a web URL handled by the SDK. Validate app-owned routes before navigation. The app must authorize custom actions and Deep Links.

For iOS, inspect linkHandler. For Android, inspect TreasureData.setLinkHandler.

Confirm that the bridge delegate is configured and that its object remains alive. Validate the action name, login state, permissions, and every parameter before taking an app-specific action.

The SDK does not authorize app-specific actions on behalf of the app.

The app obtains the token and calls registerDeviceToken; the SDK does not request notification permission or discover the token automatically.

For Android, confirm that the app receives a non-empty FCM token, passes TDPushProvider.FCM, and uses a valid table name. For iOS, confirm that the app passes the APNs token with the APNs provider.

Push receipt, notification display, and notification-tap handling remain app responsibilities.

Confirm that the message was returned as a campaign offer and that the SDK presented it. A direct openUrl call does not have campaign identity and does not create campaign measurement events.

Also check the following:

• enableAutoAppendUniqId() was enabled before the trigger when installation-level association is required
• disableCustomEvent() has not disabled the Core SDK path used by measurement
• Another message was not already visible
• The host screen-state gate did not reject the presentation

See Mobile In-App Measurement for the event fields and destination.

• Mobile In-App Troubleshooting
• Campaign Troubleshooting
• Mobile In-App Measurement
• Engage Mobile SDK API and Event Reference
• iOS SDK Integration
• Android SDK Integration
• Mobile Push Device Token Registration