Take the 2-minute tour ×

Does anyone have any tips migrating from the old iOS FB SDK (the one hosted on their GitHub account) to their .framework (package-based installer) one? I'm having issues getting the existing auth token and expiration date objects to validate against the new FBSession object.

Here's the situation:

In the old SDK/technique, the Facebook iOS SDK required you to save things like the auth. token and expiration date manually through your own storage mechanisms. In the new framework based SDK they now handle this for you, but in order to migrate users (i.e. not have them re-login) I need to provide this information to the new SDK.

It winds up being that Facebook is storing the K-Vs in NSUserDefaults and they even tell you the root key name as well as all the keys for the nested K-Vs of the dictionary they use to store this information.

Their token class FBSessionTokenCachingStrategy even has a class method to verify if an NSDictionary validates to a proper dictionary that establishes a usable Facebook session

+ (BOOL)isValidTokenInformation:(NSDictionary*)tokenInformation;

So I've taken my preexisting auth. token and expiration, put them in a new dictionary, stored it in the proper key'ed location and synchronized NSUserDefaults.

So far so good right? Well once I initialize a FBSession object via

- (id)initWithAppID:(NSString*)appID permissions:(NSArray*)permissions urlSchemeSuffix:(NSString*)urlSchemeSuffix tokenCacheStrategy:(FBSessionTokenCachingStrategy*)tokenCachingStrategy;

The whole key is removed from NSUserDefaults and the session object's state property is in the state of FBSessionStateCreated (i.e. no preexisting state) vs what it should be FBSessionStateCreatedTokenLoaded (i.e. it knows it has the locally saved properties and is ready to be checked online).

Why is it being removed? It validated against the class method.


share|improve this question

1 Answer 1

up vote 2 down vote accepted

It turns out that the local storage object for newer Facebook SDK also preserves the permissions list related to the token. This wasn't required before so while I didn't have it saved locally, my permissions list did not change. So what I did was also save the permissions list into the new storage object (totaling 3 keys: auth. token, expiration date, and the permissions list).

Once I had done this, creating/initializing the FBSession object did not remove my locally stored object and upon invoking openWithCompletionHandler: it established the expected session state to FBSessionStateOpen.

share|improve this answer

Your Answer


