SFMC In-App Messaging badge count for iOS

Question

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.

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).