Skip to main content
When the device comes back online, the SDK runs a catch-up sync: it refreshes the conversation list, then replays everything that changed in your messages since the last sync, and merges the results into the local cache. This page covers how to observe that sync, trigger one on demand, and manage the cache it maintains.
Everything on this page is a no-op unless offline support is active for the logged-in user (CometChat.isOfflineEnabled() is true). See Enable Offline Support.

How catch-up works

A sync runs automatically when the connection settles after a reconnect. It never runs on a brief connect-then-drop flap, and overlapping triggers coalesce: at most one follow-up sweep is queued behind the running one. It proceeds in two phases, in order:
  1. Conversation phase — the conversation list is fetched as one fresh page. A conversation-list UI can replace its list with the result.
  2. Message phase — the SDK replays the message changelog from the last sync point. New messages and updates to already-cached messages are merged into the cache.
The sync is incremental and safe to repeat: it only moves forward from the last successful point, and a failed or interrupted phase simply resumes on the next reconnect. The conversation refresh does remove conversations the server no longer returns, along with their cached messages and any still-queued messages for them (which fail with reason .discarded). A first-ever sync (cold start) fetches the conversation list only, records where to resume from, and replays no message history. Older history is reached by scrolling online. A cold start fires the conversation-phase callbacks only.

Listen for sync progress

Register a SyncListener to observe the lifecycle of every automatic and manual sync. Each phase fires started, then exactly one of completed / error, all on the main thread. Every method is optional — implement only the ones you need.
The two phases are independent — a conversation-phase error does not stop the message phase. A phase error is informational: the cache is never left in a wrong state and the sweep resumes automatically. The SyncListener is self-sufficient: onMessageSyncCompleted carries the swept messages, including action and call messages that the message delegate does not deliver, so you can use it without a CometChatMessageDelegate. onMessageSyncCompleted reports the outcome: Remove the listener with CometChat.removeSyncListener("SYNC_LISTENER").
Registering a listener under an ID that is already in use replaces the previous listener, and removing an ID removes whatever is registered under it. Use a distinct ID for each listener.

Receiving synced messages

If you already use a CometChatMessageDelegate, synced messages still arrive there, so you usually do not need a SyncListener to keep your chat up to date:
  • Genuinely new messages arrive one-by-one on the normal received callbacks (onTextMessageReceived, onMediaMessageReceived, and so on), tagged with source == .sync.
  • Updates to already-cached messages arrive together on onMessagesSynced(_:).
Register the delegate as usual, with CometChat.messagedelegate = self or CometChat.addMessageListener("MSG_LISTENER", self). The per-message callbacks fire before the bulk onMessagesSynced. On reconnect, queued messages are sent first, then the sync runs. forceSyncNow runs only the sync; it does not send queued messages (use retryMessage or retryAllFailedMessages for those). A message deleted on the server reaches you as an update on onMessagesSynced, not as a removal.

Check sync state

Poll the current sync state and the time of the last completed sync at any time.
getSyncState() returns .syncing while a sweep is in flight, otherwise .idle (also when offline support is disabled). getLastSyncTimestamp() returns a server-provided epoch value in seconds, never the device clock, and 0 if the cache has never synced.

Trigger a manual sync

Call forceSyncNow to run a catch-up immediately — for example behind a pull-to-refresh. It routes through the same throttle as the automatic sync, so it will not start a second overlapping sweep or hammer the backend. A manual sync refreshes the cache only; it does not flush the outbox. Use the callback overload to learn whether the request was accepted. onSuccess fires as soon as the sync is accepted and starts — not when it finishes; the sync’s actual progress and outcome still arrive on your registered SyncListener.
If you do not need the acceptance result, call the no-argument CometChat.forceSyncNow(); a rejected request is silently dropped.

When the cache resets

In rare cases the SDK cannot keep the existing cache — for example the encryption key became unrecoverable, or the database file is damaged. When this happens it rebuilds the cache from scratch and notifies an OfflineCacheResetListener. Any un-sent messages that were queued are lost in the rebuild; pendingMessagesLost reports how many, or CometChat.offlinePendingCountUnknown (-1) when they could not be counted. A logout never fires this listener.
Remove the listener with CometChat.removeOfflineCacheResetListener("RESET_LISTENER"). See Encrypt the Cache for the encryption-related reasons.

Manage the cache

Read the current cache size, or clear the cache entirely.
getCacheSize() returns the total on-disk size of the user’s cache (the local database files plus the media files) as an Int64, or 0 when offline support is disabled or nobody is logged in. It is a physical size, so it can read higher than the logical maxStorageSize budget. It walks the files on the calling thread, so call it off the main thread.
clearOfflineCache() is destructive and irreversible. It empties the entire per-user cache — cached messages, conversations, media bytes and the un-sent outbox. Each still-queued pending or sending message fails with reason .discarded (ERROR_OFFLINE_MESSAGE_DISCARDED); messages that had already failed are removed without a further callback. A send already on the wire that the server accepts is still reported sent. The next sync is a cold start. It is a no-op unless offline support is active.
You never need to clear the cache on logout — the SDK does it for you. The cache is stored per user: it survives app restarts while the same user stays logged in, and is wiped automatically on logout, token expiry, or when a different user logs in. See Offline Support.