[jferrao-itrbl]

📝 Summary

Adds Jest coverage for IterableInboxMessageDisplay link routing and fixes reserved iterable:// handling so unknown paths close the message without calling urlHandler or customActionHandler.

🎟️ Jira Ticket: SDK-615

📖 Description

• New IterableInboxMessageDisplay.test.tsx exercises WebView onMessage flows: https, iterable://delete / dismiss, action://, unknown iterable://, custom scheme → urlHandler, and trackInAppClick / trackInAppClose.
• Unknown iterable:// (other than delete/dismiss) now calls returnToInbox() after tracking, matching native HTML in-apps (SDK-633 inbox item 3 only).

SDK-633 follow-ups (not this PR)

• Example: example/src/hooks/useIterableApp.tsx still allows iterable:// in urlHandler / allowedProtocols — may need a separate change after this ships.
• Docs: reserved iterable:// for delete/dismiss (AC1).
• SDK-633 AC3, AC5.

🧪 How to test?

• yarn test src/inbox/components/IterableInboxMessageDisplay.test.tsx
• yarn lint && yarn typecheck && yarn test --coverage && yarn check:circular

🧾 Changelog

Unreleased Fixes bullet for inbox iterable:// handling (no test-only changelog line).

📹 Loom recording if applicable

N/A

🐞 Github Issues solved

N/A

[github-actions]

Lines	Statements	Branches	Functions
	88.87% (767/863)	77.01% (315/409)	86.86% (238/274)

[qltysh]

Coverage Impact

⬆️ Merging this pull request will increase total coverage on master by 4.2%.

Modified Files with Diff Coverage (1)

Rating	File	% Diff	Uncovered Line #s
	src/inbox/components/IterableInboxMessageDisplay.tsx	100.0%
	Total	100.0%

Commit 5c42a46 · 🚦 See full report on Qlty Cloud »

🛟 Help

• Diff Coverage: Coverage for added or modified lines of code (excludes deleted files). Learn more.

• Total Coverage: Coverage for the whole repository, calculated as the sum of all File Coverage. Learn more.

• File Coverage: Covered Lines divided by Covered Lines plus Missed Lines. (Excludes non-executable lines including blank lines and comments.)

  • Indirect Changes: Changes to File Coverage for files that were not modified in this PR. Learn more.

[jferrao-itrbl]

Product note — unknown iterable:// URLs and analytics (Q1)

The behavior where we still call trackInAppClick / trackInAppClose for unknown iterable:// paths (while skipping urlHandler and returnToInbox) matches native HTML in-app behavior:

• Android: IterableInAppFragmentHTMLNotification.onUrlClicked records click/close before invoking the click callback that routes URLs and keeps unknown iterable:// off urlHandler / custom action handlers (IterableInAppManagerTest).
• iOS: IterableHtmlMessageViewController records the click before onClickCallback, which leads to InAppManager.handleIterableCustomAction — unknown names return without routing (InAppManager.swift).

So the most consistent product answer is: keep click/close tracking for reserved-but-unknown iterable:// URLs unless Product explicitly wants RN inbox to diverge from native.

[rtlsilva]

Requesting changes, plus one additional PR-level comment:

The body says "SDK-633 alignment", but this PR ships only SDK-633 item 3 (inbox parity). Suggest saying that SDK-633 stays open for:

• the example: example/src/hooks/useIterableApp.tsx:197 still sets allowedProtocols = ['app', 'iterable'], and its urlHandler (lines 178–189) still treats these links as navigation. After this PR, example inbox links that use iterable:// stop navigating.
• docs saying iterable:// is reserved for delete/dismiss (SDK-633 AC1). None exist yet.
• SDK-633 AC3 and AC5.

[rtlsilva]

Approved with minor wording suggestions. LGTM