I have this exact scenario on an app I ' ve been working on for a client . Our LoginManager is a singleton state machine , and our back end service is a REST JSON API thing that we use for everything . We don ' t store the token in the keychain , but we do store the login username and password , and just reauthenticate once on app launch . Consider this if you store the token and it ' s expired , you ' re going to have to reauthenticate anyway . Or your server can have a redeployment say daily weekly and your tokens may expire very quickly or clash , and you end up with someone else ' s token because of a redeploy , so again you ' re going to end up reauthing in that case too . Also , if a user changes their password via a web interface outside of the app , and you relaunch the app , your token should be expired , however if your backend server doesn ' t consider expiring the token on a password change , you basically have app clients that now shouldn ' t have access to the account now having access . There ' s other edge cases like this to consider say your backend starts giving you 500 ' s because of a bad deploy , or the user ' s connection drops before you realize it and essentially your app thinks you have a bad token . In all these cases what our policy is is to just store login password in the keychain , authenticate once on launch if succeed store the token until the user logs out quits app . If failed , bring user to login screen with prepopulated username and password . Keeps things easy to manage and debug , and we don ' t have to worry about getting out of sync with the backend server . So if I haven ' t pressed the point enough I ' ll say just store the user credentials , and keep the token locally per login session . For your next question , you can either store the user object locally in say the temporary directory or caches directory , or write a class structure that contains the relevant data you need and just decide to it when you load the object for the first time , or give your LoginManager singleton readonly accessor methods to access that data . In ours we do the last option for login , we have relevant data like subscription tier that we need to access pretty much everywhere , so we have a getSubscriptionLevel method in our LoginManager class for this . We also have the equivalent of a getUserToken method in this class as well . In other places in the app , we fetch JSON data and store it into a data model class , and when we decode the JSON , we decide it into that data model type or construct arrays of that data model type . What you ' re doing is not weird , but there tends to be a lot of edge cases you can trip over . my advice would be to try to keep your classes modular and your logic simple where you can .