I am implementing the feature of automatically logging in the user in an iOS app. This is easy for a single app as we can persist the username with NSUserDefaults while the password using System Keychain.
Now, I want to do it across multiple apps. In my understanding, we'd need a unique device identifier for this, which we can pass to the server and then use it to activate auto login across multiple apps on the same device. Now since, Apple prohibits the use of UDID now, I am thinking of using the Vendor Identifier which would of course require me to set the Bundle IDs accordingly. Is this the best way possible? Or is there a better standard method that is more effective?
Also, Is it at all possible to have auto login between different devices? Like for e.g. If I login on one iOS device and then open the app in another, I should automatically sign in.
To implement login between multiple iOS apps you can use the same App ID prefix in them. It will work because they will share keychain data. Here you can find more details:
https://developer.apple.com/library/ios/technotes/tn2311/_index.html
And here the related question: Keychain group access to share data between my existing applications
And about automatic sign in between different devices. I used encrypted iCloud Key Value storage to store login & password between devices. And it worked but not too good. Problem is that first time you start app on new device it will take some time to sync data from iCloud to local storage. And this means that first time you trying to Sign In and may need to wait for some undefined time. In may case it was about 20 seconds. To long for Sign In in a good application :) And of course this require user to be logged in iCloud with the same Apple ID.
ASAIK there is no proper way to implement automatic Sign In from multiple devices. And Apple recommend just to ask for Sign In on every new device of user.
Related
My iOS app is currently on beta in TestFlight, and as a way to retribute to the nice people who helped me test it I would like to offer them some goodies such as, for instance, the full final version of the app for free.
For this, I was thinking of sending them a last beta version which would, automatically and upon execution, store some kind of ID from the logged in user into a VIP list I would keep online and then every next version of the app would check for their ID in order to verify if the user is a VIP user and unlock all the premium features.
Is it possible to obtain in the Cocoa apis a unique identifier that is associated to the user (as opposed to the device unique identifier)? I want this because I want to recognise the user in whatever device he installs it. I would like to avoid having to make my beta testers manually register as VIPs.
Thanks!
Yes, this is possible using CloudKit. You'll need a CKContainer, and you'll ask it to fetch the user record ID. That record ID is unique for your apps, but is also stable for that user this means the same iCloud account will have the same record ID, regardless of which device they're running on or which of your apps they're using.
If you turn on the CloudKit capability for your project, Xcode will automatically create the iCloud container for you, and you can then access it using one of the two CKContainer constructors.
Working for a company where we are starting to have many small apps, each with their own log in screen.
So that means whenever someone's password changes, they'll have to re enter their password for every app
Can be cumbersome to the user, especially when our policy is to have user's passwords change every 3 months and there are 6 or more apps to enter the password on
Has anyone come up with a work around for this problem where the user would only have to enter their password once? I'm thinking I could have one dedicated app solely for authenticating and then do some kind of interprocess communication if that's even possible
Again, doing this for iOS. I know on Android it wouldn't be an issue because developers can add accounts in the settings screen. However, iOS is a different beast
*Note these are enterprise, in house only apps. Not public facing on the app store
You need to store the username/pwd on keychain and share them between apps as mentioned here
https://developer.apple.com/documentation/security/keychain_services/keychain_items/sharing_access_to_keychain_items_among_a_collection_of_apps
As I understand it now can not get apple id in iOS 7.
iOS 8 has many edits to work with iCloud and adding iCloudKit. Will I be able to get Apple id from API and use it, for example, for registration in own server?
No, you cannot get the user's Apple ID.
What you can do with CloudKit is get an opaque user record ID. This object will be the same for the user for your app on all of their devices, but it will be different for other apps or other users. You can save that on your server and use it as something like a "log in with CloudKit" feature. This was described in the WWDC 2014 intro to CloudKit session. Basically, you use the fetchUserRecordIDWithCompletionHandler: method on CKContainer. But there's no way to link this to the Apple ID automatically-- you still need to ask the user if you want that.
Not that I am aware of. That's kind of "invading" the user's privacy because you'd be getting his Apple ID (which is an email) without his consent.
What I do, using Parse SDK, is to make the user log in anonimously at my Parse App, then save his automatically generated User ID in a iCloud Key-Value container. Whenever the user deletes the app and reinstalls it (or simply install in another device of his), my app knows that he has an username saved on iCloud and then uses that instead of creating a new user. This way, I get to keep track of my users without invading nobody's privacy.
To contextualize the question, our use case is an app through which users can get free promotional items on signup. We would like to prevent abuse of the system by limiting to one promotion per device. Since we can't access the UDID, we need some other (mostly) reliable way to check if the phone has already signed up an account. We don't need a solution that is impossible to circumvent, just one that is highly inconvenient to circumvent.
If we store a unique key in the user's keychain, then we'll be able to read it again even if they uninstall and reinstall the app. We're considering using this method to track devices that have already signed up accounts.
Questions:
Is there a relatively easy way that the user could delete or change our app's keychain data? You can assume that the user's device is not jailbroken, and that they will not go to the trouble of completely reinstalling the OS.
What are other options besides using the keychain we might consider? Keep in mind that the app communicates with our server during signup, so we can store previous signup information of any kind on the server.
Are there any gotchas or problems with the keychain method we should know about?
I am working on an app that has a number of in app store purchase items that will enable certain functionality.
After each item is purchased, I would need to remember it (of course). I would also like to persist this information in iCloud in case the app is deleted or is installed on another device.
What is the best data structure to be used?
Can user defaults database be used for this?
What is important is that the user will not have access to change those values and enable by themselves the paid functionality.
Can user defaults database be used for this?
It can, but it's not the best idea to do so, since
What is important is that the user will not have access to change those values and enable by themselves the paid functionality.
and NSUserDefaults stores its contents as binary or plaintext property lists. Easily changeable on a jailbroken device. (Also changeable on a non-jailbroken one by modifying the iTunes backup files).
What you could do is either store them in the keychain, although the keychain is not really designed for this (and it can also be dumped on a jailbroken device using Ptoomey3's awesome Kaychain-Dumper tool), or better store it remotely on your server and let your server check what the user has purchased.
Of course, if it's not only the server that does the check, so for example you don't only send or don't send content based on purchases, but you also use this check for performing actions within your app, then it also can be hacked (google "MobileSubstrate cheat DoodleJump" for a nice example).
All in all: there's no perfectly secure system.
I use the KeychainItemWrapper class to store a flag in the keychain. The nice thing is, so far, is that the keychain survives an app deletion. IF the user then reinstalls the same app on the same device, the keychain data is still there.
There is no need to use iCloud. If the user installs your app on another device, you just need to provide a "Restore Purchases" button in your app. Then you call the Store Kit APIs to restore existing purchases. The "In-App Purchasing Programming Guide" covers how to do this.
This same functionality will allow a user to restore their purchases even if the flags in the keychain are lost.