After a quick research I found that using Codable API in OBJ-C requires some bridges with Swift: https://stackoverflow.com/questions/50617542/how-to-use-codable-protocol-in-objective-c-data-model-class. Additionally I am not sure how stable is the current structure of the rescind payload - how likely are we to be changing it in future. Using Codable would require us to declare class with fixed attributes, so each change in rescind payload on the JS side would require a change in this class. This increases the coupling in the codebase. However, once we reach a point where notifications payload structures are unlikely to change we might consider representing them in native languages as more rigid and restrictive types rather than just dictionaries mapping String -> Object.

In this particular case, if we ignore the error we will eventually pull the correct state of thread unread status from keyserver. Currently updating SQLite in response to notifications is a kind of redundancy that can be helpful when user opens the app in weak network environment but they still got the correct state because of received notifications. From the user perspective, killing the app here would be a poor experience (in worst case they would still get the correct state but just later). But from the dev perspective it might be useful since having an error here means that some error occurred on the NSE side since it failed to correctly persist rescind payload (it could be time out for example). This would make us investigate what had happened on the NSE side.
It is high time this issue is taken on: https://linear.app/comm/issue/ENG-2670/c-equivalent-of-dev-flag

Every where in our codebase where we create std::string from NSString* we call UTF8String method before passing it to std::string constructor. Apple docs suggest to do it this way: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Strings/Articles/CreatingStrings.html

It would be a good measure.

This answer: https://stackoverflow.com/a/5503357 nicely explains how capturing and mutability works in C++ lambdas. This lambda has to be mutable since the inner function: comm::ThreadOperations::updateSQLiteUnreadStatus(threadID, false) takes threadID be reference.