Loading

Marketing Cloud Engagement | Key Differences and Considerations for Inbox Messages Between MobilePush SDK Version 8 and Earlier vs. Version 9 and Later

Julkaisupäivä: Jul 9, 2026
Kuvaus

In MobilePush SDK version 9 and later, the method for retrieving Inbox messages and message properties has changed from version 8 and earlier. When upgrading the SDK from version 8 or earlier to version 9 or later, review the behavioral characteristics and changes described in this article.

Ratkaisu

1. Change in Message Retrieval Method

In SDK version 9 and later, the SDK performs incremental (differential) message retrieval. The SDK retains a timestamp from the last retrieval batch, and each subsequent request fetches only messages updated after that value. In contrast, SDK version 8 and earlier re-downloads all active Inbox messages linked to the target device. This shift to incremental retrieval in SDK 9 affects personalization behavior, as described in the sections below.

 

2. Impact on Personalization from the Change in Retrieval Method

AMPScript and personalization strings in Inbox messages are evaluated at the time the SDK downloads the message — that is, when the app is launched on the target device or when a refresh is requested (via refreshInbox / refreshMessages).

Because SDK version 9 and later retrieves only incremental messages, AMPScript and personalization strings are not re-evaluated for already-downloaded messages. Once a message is downloaded, even if the content or Data Extension data is updated on the Marketing Cloud Engagement side, the device continues to display the value evaluated at the time of the initial download.

Note: See the exception behavior described below under "Message Re-retrieval at Timestamp Boundaries."

In SDK version 8 and earlier, Inbox messages are always fully re-downloaded, so AMPScript and personalization strings are re-evaluated for all messages on every download. This means that when Data Extension data is updated, all message references are re-evaluated against the latest data on the next download.

SDK version 9's incremental approach makes it easier to retain data as of the message download time. However, for use cases that dynamically change content based on MCE data such as Data Extensions, data management differs from version 8 and may require additional consideration. If you were performing personalization in version 8 that relied on re-evaluating all messages on every download, verify and assess whether those use cases continue to work as expected after migrating to version 9.

 
Note: Message Re-retrieval at Timestamp Boundaries

SDK version 9 retrieves only incremental messages — specifically, only messages updated after the baseline timestamp retained on the device.

That baseline timestamp is set to the timestamp of the most recent message from the previous retrieval. On subsequent requests, messages after that timestamp are retrieved. This means the latest message itself is always included in each retrieval.

This results in the following behavior:

  • Even when there are no new Inbox messages, the most recent message alone is re-evaluated (AMPScript, etc.) each time and overwritten with the current data. Earlier messages remain fixed at the content from their last evaluation.
  • When a new message is added, "the previously most-recent message + the unretreived new messages" are retrieved together, and all of them are re-evaluated by AMPScript.
  • After that, the baseline timestamp advances to the new latest message, and from that point forward that one message is re-evaluated each time.


Example: As shown below, with the last message download at 10:45, Message A is no longer a download target afterward and AMPScript is not re-evaluated for it.
TimeEventMessages to Download
10:00
Message A job completed
A
10:05App launch / message downloadA (AMPScript evaluated)
10:10App launch / message downloadA (AMPScript evaluated)
10:30Message B job completedA, B
10:45App launch / message downloadA, B(AMPScript evaluated)
10:50App launch / message download

 

B (AMPScript evaluated)

*From this point on, A is no longer a download target; B becomes the recurring download target.

 

 

 

3. New Features in Inbox 2.0 and App Considerations

SDK version 9 and later introduces Inbox 2.0 with primarily three additions. These changes — as well as continued use of Inbox 1.0 — may require you to review your app-side implementation.

  • Optional CloudPage CTA: The CloudPage CTA that was mandatory in Inbox 1.0 is now optional. You can choose from no CTA, CloudPage, Web URL, or App URL.
  • Additional Properties such as Subtitle and Body: Properties beyond the subject line are now available.
  • Push Copy to Inbox (PCTI): Push notification content can also be received as an Inbox message.


In the Inbox feature, the SDK handles only data delivery; rendering the app screen, handling design, and processing taps are all dependent on the app-side implementation. Which properties to map to which UI elements and the behavior on tap must be designed and implemented by the app developer. Tap-time transitions and behavior for each CTA type (Web URL, App URL, CloudPage) are also defined on the app side. Because so much is handled by the app, design and test your app implementation for each expected pattern and review the implementation thoroughly.

Reference documents:


 

Frequently Asked Questions

Q1. Inbox message or Push Copy to Inbox subject data does not display correctly on screen, or appears blank.
Debug on the app side and verify the property values received by the SDK and the mapping to UI elements. SDK version 9 and later uses different properties from earlier versions. If no logs appear, consider enabling logging. If the issue appears to originate from MCE — such as data sent from MCE differing from expectations — contact Salesforce Support with details.
Reference: Troubleshoot Android / iOS

Q2. Is sample code available?
Support cases do not provide custom code samples. Refer to the Learning App and official documentation.
Reference: Inbox Messaging / Learning App Android / iOS

Q3. Tapping an Inbox message does not navigate to the target URL as expected (e.g., WebView or browser does not open, deep link does not work as intended).
First, debug the app and check how tap-time navigation is handled and what URL the app is attempting to navigate to. These behaviors depend heavily on the app-side implementation. The method for handling URLs contained in Inbox messages (opening in WebView, external browser, or as a deep link) is determined by the app implementation. Therefore, the recommended first step when this issue is observed is to request debugging assistance from the app development team. If the data sent by Marketing Cloud Engagement or handled by the SDK appears incorrect or unclear, contact Salesforce Support with details and debug information.

 
 
*The behaviors described above reflect the state at the time this article was written. SDK behavior may differ depending on the version.
Knowledge-artikkelin numero

005387380

 
Ladataan
Salesforce Help | Article