We have integrated SFMC Inbox messaging in our iOS application. Whenever we trigger an alert + push inbox message from SFMC portal, badge count on the app icon is incremented by 1.

We mark a message as read by calling sfmc_markMessageRead function, whenever user reads a message inside the app. (We have a controller to display all the messages (sfmc_getAllMessages) & a message detail controller)

Scenario :-

  1. I send 4 alert + inbox message, badge count on appicon is set to 4. (App is killed)
  2. Now if I launch the app, read 2 messages and then kill the app, badge count on app icon will be set to 2 (unread message count) by the SDK.
  3. Now if we trigger another alert + inbox message, badge count would be updated to 5. (App is killed)
  4. Now if I launch the app & kill it, badge count would be updated to 3 ( as we have 3 unread messages).

What I have concluded from my observation is

  1. Everytime you send an alert + inbox message from SFMC portal & enable update badge count option. Badge count will be equal to number of notifications sent.
  2. When user launches the app, SDK overrides the badge count & it's set to number of unread messages user has.

Questions :-

Q1) Is there anyway we can tell SFMC server that a message has been read?

Q2) How SFMC maintains badge count at its end?

Q3) How to reset badge count on SFMC portal?

Q4) We want to display badge count as number of unread messages user has. How do we achieve this when app is killed? Is there any out of the box function or config which SFMC provides?

Any help is much appreciated.

1 Answer 1


Swipe to kill is pointless and discouraged by both Apple and Google, however, the iOS SDK could handle it better.

In the scenarios you outline, the application is being abruptly terminated and the SDK is not able to notify the server that the message has been read. Your application counter is correct until such time as it is overwritten by the next send you initiated from the server.

A release of the iOS SDK is in process that will move the Inbox Status update sooner in the termination lifecycle event which will increase the likelihood that it will execute before the app is terminated.

It is important to note, however, that there is still a small propagation delay on the server side and while this shouldn't be an issue in real-world use cases, your testers might see a discrepancy if they send a message, read a message, send a message in a very short amount of time (~2-5 minutes).

  • Thanks for the prompt response bill. I'll ask the team to send one message in 5-10 mins. How much time does SFMC SDK requires to sync data to the server? There is a possibility that the user of our app might swipe kill the app immediately after reading the message inside the app and we cannot control that.
    – Developer
    Commented Feb 10, 2021 at 3:01
  • Bill, if possible please share the link to the sales force official documentation where this behaviour is documented, so that I can pass it on to the team & stake holders.
    – Developer
    Commented Feb 10, 2021 at 3:51
  • 1
    Ok, thanks for responding
    – Developer
    Commented Feb 10, 2021 at 14:56
  • 1
    I was actually working on updating the SDK to 7.4.0 Thanks for update @BillMote.
    – Developer
    Commented Feb 16, 2021 at 13:06
  • 1
    Yes, that issue has been resolved. It was related to the APNS certificates.
    – Developer
    Commented Feb 17, 2021 at 14:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .