I'm creating an iOS that interacts with an API using Alamofire, and requires a Token for most requests. I've built the app using the MVC pattern, and it works great, but I've encountered a problem as I've tried to integrate the API. How should I share/store the token so that it can be accessed from the view controllers/models? I've read up quite a bit and have found negative opinions on using singletons or UserDefaults, but I've yet to encounter a straightforward answer. I understand this is a pretty broad question that might not have a simple answer, but I am pretty new to this and was wondering if anyone can help point me in the right direction. Thanks!
Best practices for storing a Token in iOS app
Viewed 11821
1 Answers
If view controllers need this token, you've broken MVC. There is no reason for a view controller to directly talk to the network. That should be handled in the model layers. A view controller coordinates a view while it's on the screen. It doesn't do anything else.
So you'll store your token in the model. How do the view controllers access the model? That depends on your experience level:
If you're fairly new to Cocoa development, use a shared instance (a "singleton," though really it's not a singleton; it's just a
static let sharedproperty). This pattern has been used very successfully by Cocoa devs for decades. There's a reason we use it. It just works, and you don't have to fight it. But, it has some problems, which brings me to the next option:If you have enough iOS experience to have actually run into problems with shared instances (usually related to unit testing and occasionally related to code reuse), then you will know enough to have an opinion on all the many other patterns people have been applying (and sometimes inventing) in recent years. But jumping into these more complicated patterns is not, in my opinion, a good approach for new developers. They tend to move you away from how Apple intends us to work (in particular, most of them assume you won't use Storyboards, and Apple pushes Storyboards very hard). There are reasons to go against Apple's guidance, they're not always right, and some of the new patterns are very interesting. But wait until you have some experience before you decide that you know more than Apple about developing Cocoa apps.
If you need to store the token in memory, you're done. If you need to persist it and it's considered sensitive, then the correct place is Keychain. Use a wrapper. The Keychain API is horrible beyond description. Any wrapper will do. KeychainAccess is popular these days, but really, any of them are fine.
The main problem w/ NSUserDefaults is that if someone steals the phone and jailbreaks it, it's easier to read NSUserDefaults than Keychain. As a matter of policy, don't put sensitive information in NSUserDefaults.
Related