The first idea that comes to mind is to create a class called User. It would be a subclass of NSMutableDictionary.
That's a big mistake. If your User class is a subclass of NSMutableDictionary, then any other object with a reference to it can assign any value to any property they wish. They could even change the type of a property or add new properties. It's a very bad architectural choice.
Instead, make your User a struct that has the correct properties with the correct types. Then make a singleton class, maybe called Session that is the single source of truth for the User object. Make the Session observable (à la the Observer pattern) so that whenever its state changes, all observers will be notified so they can update accordingly.
You could do away with the Session class and make the User an observable, singleton class itself, but this IMHO gives the User class too many responsibilities.
I would run the User.update() function during times such as:
- App launch
- App re-opened from sleep
- Profile update
- After in-app-purchase
- etc.
Here's a use-case for you. I have the app open on my phone and my tablet. I make changes on the phone and then watch the tablet and expect the changes to appear there, but they don't because I'm not doing anything on the tablet that would cause the update() function to be called.
If you really want to keep the data in sync, see about setting up a socket server that pushes the data to the device whenever changes occur.