I have a requirement wherein I should not allow the user to install my app in more than 1 device. This is an enterprise application and I distributed this using Enterprise developer account. Based on the Google search I use IdentifierForVendor to get unique device ID, but this doesn't seem to work now as when the user uninstalls and installs the new/same version of the app in the same device again, it returns new DeviceID. Now I am back to my old question - How to find a DeviceID for IOS?
What I think is a possible approach is to deactivate the DeviceID when the user uninstalls the application. But I am not sure how to achieve this as there are no cycle/function calls when the app is uninstalled.
Apple documentation says if all the apps from the same vendor is uninstalled from the device, then at the time of new installation of any app from that vendor will take new IdentifierForVendor.
So I would suggest store this unique id in Keychain and whenever you open the app check if there is any unique id stored in keychain if not then generate one and keep it there.
If app in uninstalled also , the key will be still there.
After you re-install the app , when you access the key in keychain it'll be still there.
This way you can achieve your objective of uniquely tracking a device.
Talking of keychain , it's worthwhile to take a look at Xamarin.Essentials Nuget.It provides many cross platform features including keychain.
Hope this helps.
Related
I am a junior professional software developer.
I'm working on app with device limit per user, we use UIDevice.current.identifierForVendor for identifying device. Unfortunately we have problem with "device limit is reached" when installing and reinstalling app.
According to identifierForVendor documentation:
The value in this property remains the same while the app (or another
app from the same vendor) is installed on the iOS device. The value
changes when the user deletes all of that vendor’s apps from the
device and subsequently reinstalls one or more of them.
The problem is obvious - after app is deleted and reinstalled we have a new identifierForVendor and we treat it as a new device.
According to another part of documentation:
Normally, the vendor is
determined by data provided by the App Store. If the app was not
installed from the app store (such as enterprise apps and apps still
in development), then a vendor identifier is calculated based on the
app’s bundle ID.
I have two questions:
Problem accurs when we install app from Xcode or TestFlight. Would it appear also when we install app from AppStore?
Is there any other way to limit device number and determine a device?
PS. I know, that there already were a few similar questions, bu in my opinion the answers were not exhaustive and it was a few years ago :)
You can try to do it with Keychain:
Generate UUID().uuidString
Save it to Keychain with some of Keychain wrappers (e.g. KeychainAccess) using key "UniqueDeveiceID" or something.
Send generated UUID to the server(or whatever)
As summary:
After the app starts just check the value for the key UniqueDeveiceID exists. Keychain is not cleaning after reinstall so you'll have to chance to check if it's a reinstall or a newly registered device.
I'm developing an iOS app in Xcode 12.2 for a client.
The client does not have an Apple Developer account yet, so I'm using the Testflight of my own account to test the app with the designer.
The app uses AppGroups, let's say I have a group named "group.com.myorg.appname".
I'm also using CoreData, and will implement NSCloudKitContainer very soon.
My question is:
Once the client has purchased a developer account, can I easily delete my version from my Testflight, and then add it to the client's Testflight, without issues?
For example, do I have to change the AppGroup identifier? And is this a problem for iCloud?
I have read this answer which contains lots of good information, but didn't allow me to be sure about iCloud or the AppGroup identifier. This was also very useful but incomplete. I've also read information about app transfert, but in my case the app is not published, it's just in Testflight, there's no publishing before moving to the client's account.
If you do not want to lose the IDs, the safest option is the transfer the app to the new account rather than deleting it. If you have push notification certificates, these would need to be regenerated on the new account. However the same goes for the App Groups. You will need to delete it from your old account to release the ID and make it available for the new one. There shouldn’t be issues doing this since it is not launched yet. https://developer.apple.com/forums/thread/70297
A previous developer created and uploaded our app with our dev team. They then transferred it to our client's account and released it. However it kept our Team ID. When uploading to the App store, I get the following:
"Potential Loss of Keychain Access - The previous version of software
has an application-identifier value of ['XXXXXX.XXXXXXX'] and the new
version of software being submitted has an application-identifier of
['YYYYYY.XXXXXXX']. This will result in a loss of keychain access."
I can accept losing Keychain Access as I understand that there is little that can be done here and it may not affect this app.
However, my question is, could current users be affected? There are no passwords in the app or any user details stored, it is mostly an informative app. I assume it won't stop them updating the app or block them from using their current build? These users have paid for the app, so if they stop getting access all of a sudden, they might be upset!
i.e. I'm not sure about the following technologies from Apple:
Important: The only apps that can ignore this warning without
consequences are those that do not use technologies that rely on the
App ID prefix, like keychain access, Handoff, and UIPasteboard
sharing.
I think you need to check with the developers to see if they are using anything related to the app ID prefix.
As stated by Apple, the app Prefix is critical to using a couple of their capabilities.
Basically, most of the technologies listed are all about inter-app communication. If you only offer one iOS / Mac app, you aren't doing any special interactions with other apps with the same app prefix, and you don't have anything to worry about. Pasteboard is basically a shared clipboard used to share information between apps by the same developer. Handoff is about syncing state between apps on different platforms (e.g. Sharing Safari tabs between your Mac and your iPhone).
The other thing to worry about would be the first error you show. That error means that if your app is storing any information in the keychain, the new version of the app would lose access to anything that was stored in the keychain by the old version of the app. If, like you say, your app really isn't using the keychain to store information (it doesn't have to just be passwords, FYI), you don't need to worry about that either.
I would definitely have the developers check for anything related to the keychain to confirm, as well as anything related to the PasteBoard or Handoff.
EDIT
As to the affect on current app users, they should not be affected if you are not using any of the above technologies. Existing users will get the update and should not notice any difference. More on that in this answer.
I need to be able to identify an iOS device across uninstalls/reinstalls.
To do so, I plan to store the identifierForVendor in the keychain at first install, and retrieve it on following installs.
Is there any risk of being rejected of the AppStore by doing so?
I've seen several questions about that so I guess it would be allowed, but the Developer Program License Agreement states that:
Further, neither You nor Your Application will use any permanent,
device-based identifier, or any data derived therefrom, for purposes
of uniquely identifying a device.
I could also use a NSUUID instead, would it be safer?
Edit: add some context for answers suggesting to implement a login.
My app already has an identification system (with a login). It allows the user to connect to his account, and he should be able to see a list of the devices linked (i.e. from which he did connect at some point) to its account, in order to monitor or to unlink them.
The problem is that the identifierForVendor changes after an uninstall/reinstall of the app, leaving a "ghost" device in the user's list. Storing and retrieving it would allow a reinstall of the app not to be considered as a new device. It would only be used for this, and not for advertising or tracking in any way.
TL;DR:
Storing UUID in phone's Keychain will not get your app rejected. So don't worry.
The UUID you're trying to use is NOT a permanent identifier as we know, and storing them does not violate the licensing term that you quoted. Apple deprecated UDID's, MAC addresses, IMEI number etc. to prevent developers from tracking/spamming users based on their unique ID's. This is a privacy problem. Since UUID is a temporary ID, we are free to store them and use them later on, which does not do harm to the user.
I am quoting this from the link from Apple's resources here: Using identifierForVendor
The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them. The value can also change when installing test builds using Xcode or when installing an app on a device using ad-hoc distribution. Therefore, if your app stores the value of this property anywhere, you should gracefully handle situations where the identifier changes.
-----****UPDATE IN IOS 10.3:****-----
It seems that Apple has made some changes to how Keychain works in iOS 10.3+. Keychain items stored in the Keychain will be deleted when the all the apps from the specific vendor are uninstalled. According to Apple, the residence of sensitive information of an app even after the app is gone from the device may lead to security risks, so they decided to forbid this kind of behavior.
Developers relying on Keychain storage even after an uninstall for their apps can make use of this WORKAROUND to continue with the intended functionality. According to this workaround, any app can access the information stored in that specific Keychain Access Group, so it is recommended that adding an extra layer of encryption to your data will protect it with even more security, although keychain encrypts items by default.
You may generate a device-id(->similar to UUID) on the server and store that in Keychain of iOS. If your app is reinstalled on the device and you find that device-id in the keychain, then you will be able to identify the device.
Our iOS app is transfer from Account A to B, Earlier we had used the certificates which was created in Account A and upload a build on iTunes Connect using certificates of Account A.
Now when we uploading app on iTunesconenct for Beta Testing that time we have used the certificates which was created in Account B(Due to Transfer App Account).
So, Now application identifier of the live app is different from the application identifier of the Beta TestFlight Testing App on App Store. And we have got the warning potential loss of keychain access.
Right Now, We are using SSKeychain Wrapper for Store UUID to track user.
[SSKeychain setPassword:UUID forService:#"com.example.appname” account:#“appname” error:&error]
If App ID Prefix changed then SSKeychain loss it’s access?
Because We track UUID in database for further use using SSKeychain. My doubt is if APPID Prefix changed then it is also effect the SSKeychain and it is generate new UUID for all devices?
So, How we can solve this issue ? Please let us know about solutions of this issue.
The keychain access is tied to the App(s) ID Prefix(s). They must have the same prefix. We had a case where different Apps in the same Developer Account and different Prefix(s) and they would not share the same keychain access. Had to have Apple fix so all were the same.
In your case, if you move the app to account B, the App ID will have a different prefix and would not be able to access the "old" keychain.
As far as I know there is NO workaround for this if the App Prefix has changed.
Yes, all devices would get a new keychain store for data and would not be able to access the "old" keychain data.