Release 3.1.0

What's new in v3.1.0

New: source field on link events

The reteno-in-app-custom-data-received event (addInAppMessageCustomDataHandler / inApp.onCustomData) now includes an optional source field that tells you where the link interaction came from:

type InAppCustomData = {
  customData?: Record<string, any>;
  url?: string;
  source?: "inAppMessage" | "pushNotification"; // new
  inapp_id?: string;                            // Android
  inapp_source?: "DISPLAY_RULES" | "PUSH_NOTIFICATION"; // Android: how the in-app was shown
};

• iOS: mapped from the native link source, so a push link tap reports pushNotification and a link inside an in-app reports inAppMessage.
• Android: events from in-app link actions report inAppMessage. inapp_source is unchanged and still describes how the in-app was shown (display rules or push), not where the link was clicked.
• The field is optional, so this release is fully backward compatible.

Use it to avoid double navigation or skipped links when push and in-app links are handled by different flows.

Android note: the native SDK emits this callback only when the in-app link action has at least one custom-data field. URL-only actions are opened directly and do not emit the event.

Fixes and improvements

• Android: one in-app link interaction now produces one JS event. Previously the native SDK's receiver and the React Native receiver both forwarded the same broadcast, which could deliver the event twice. Events received before initializeEventHandler() are queued and flushed afterwards.
• Android: getInitialNotification() resolves only for launches from a Reteno push (identified by es_interaction_id). Launches carrying extras from other SDKs, such as a Branch deep link, resolve with null.

Native SDK versions

Platform	Version
Reteno Android SDK	2.10.2
Reteno iOS SDK	2.7.5

The iOS deployment target is now 15.0, as required by Reteno 2.7.5.

Documentation

• Added source vs inapp_source explanations to the In-App Messages and Push notification guides.
• Documented the Android getInitialNotification() behaviour and the custom-data requirement for in-app link callbacks.

Example app

• New "Link Source Test" section on the In-App Messages screen that shows source, inapp_source, url, customData and the raw payload of every link event, including events queued before JS started.

Known limitations

• On iOS cold start via a push that carries a link, the link event with source: "pushNotification" may not reach JS. Use getInitialNotification() to read the launching push on iOS.
• getInitialNotification() returns the raw launch payload. It does not include in-app link customData or source.