What is the main difference between using [NSFileManager URLForUbiquityContainerIdentifier:] and [NSFileManager ubiquityIdentityToken]?

Question

I'm trying to add iCloud support to my application, and have been following Apple's own iCloud Design Guide. The guide says I should be checking for user credentials by calling [NSFileManager ubiquityIdentityToken]. It also says I should check [NSFileManager URLForUbiquityContainerIdentifier:] to make the app's ubiquity containers available.

The issue I'm running into is that ubiquityIdentityToken is returning nil while URLForUbiquityContainerIdentifier: is not. Because the latter is returning a correct URL, I'm assuming my provisioning profile and entitlements are set correctly. I also double checked that the device I'm running the app on has iCloud enabled, it's logged in and has Documents and Data enabled.

Why would one method imply there is no iCloud connection while the other does?

UPDATE: I noticed that if I call ubiquityIdentityToken it returns a value if I call it after a call to URLForUbiquityContainerIdentifier:. Nevertheless, how will ubiquityIdentityToken work if my app is using the key-value store instead of a ubiquity container?

Answer 1

ubiquityIdentityToken is a new thing introduced by Apple to allow apps to check if the user is logged into icloud. This is an extremely fast way to find out if the same user is logged in between app activations/if the user is infact logged in etc.

It can be run on the main thread and is extremely fast. This will allow you to take decisions about your app logic.

The key thing to note is that it can be run on the main thread and is extremely fast.

You generally get this token, store it in your app and then compare it again when your app comes back from background.

That way, you can make sure that it is the same user etc etc.

If this returns nil, that means that the user is not logged into iCloud.

Previously to check if the user was logged in, there was a separate call but you had to run it on another thread asynchronously. I guess, they saw situations where a user is logged into iCloud, suspend their app, log into another account and come back to your app. This will allow you to check for those things very efficiently and easily. The token does not have any user identifiable information though.