Offline support starts with a clear local promise. A listener can choose to follow a show while disconnected, but the cloud has not received that choice yet. Your interface should distinguish saved-on-device intent from confirmed account state.
Keep a small queue of pending changes, owned by the authenticated account. Each item needs the show identity and the final intended relationship, not only a record that a button was tapped.
Coalesce opposite actions
If someone follows and then unfollows the same show before reconnecting, sending both operations may be unnecessary. A desired-state model can reduce the queue to the final choice, provided that it matches the API's documented semantics.
Do not merge a queue across accounts. Signing out or deleting an account changes which writes remain valid. Keep the queue's ownership explicit and check it before replaying work.
During reconnect, handle authentication, temporary failure, and validation failure separately. A temporary network problem can keep an item pending. An invalid or unauthorized request needs a visible recovery path rather than endless retries.
Test a full disconnected journey
Follow two shows, unfollow one, close the app, and reopen it without network access. The local view should still reflect the final intent. Reconnect and inspect the account state from a second client.
Then repeat after changing accounts on the original device. None of the first person's queued writes should affect the second account.
Avoid describing an offline change as synchronized until the confirmation point you define has been reached. A small pending indicator is more useful than a confident label that hides a failed upload. The queue is part of your product's data model, not merely a retry helper.