How are we supposed to uniquely identify devices now that the UDID has been deprecated? I need to be able to uniquely identify a device even if the user uninstalls my app and then reinstall it. The new identifierForVendor doesn't work for this purpose because it will randomly generate again once the user uninstalls the app. I also can't use the MAC address to identify the device because it doesn't work in iOS 7.
The advertisingIdentifier seems to work for my purposes but I heard that if you're not actually using it for advertising Apple will reject your app?
Does anyone know of a way to reliably identify a device?
According to Apple, you should be using the vendor or advertising identifiers. Vendor doesn't work for you obviously, but you are fine to use advertisingIdentifier.
The advertisingIdentifier seems to work for my purposes but I heard that if you're not actually using it for advertising Apple will reject your app?
They are not currently rejecting apps for using avertisingIdentifier in place of uniqueIdentifier as a device ID. I just had a version of my app approved that uses advertisingIdentifier for purposes other than advertising. A bigger negative is that users can change this identifier any time they like, which is guaranteed to mess up your reporting.
Related
The API documentations says that Titanium.Platform.getId() returns the UDID (unique device ID) for android but for iOS this is a unique identifier for a particular installation of the application. It also says that Apple has restricted the access to UUID.
However, if I need to retrieve a unique device ID for an iPhone, is there any way to do it? Or is it not possible at all?
There is no way to get any device unique identifiers in iOS 7 and up, Apple has restricted this due to privacy concerns. The trick to use the MAC address is also no longer working.
You options are the identifier for vender (the one Titanium.Platform.getId() returns).
This one is unique for the device as long as there is app on the device from the same developer.
Another option is to create a unique identifier and save it in the keychain, this way it will be saved there until the user full wipes it's iOS device.
No, you can't. Check this article for some more informations:
http://www.doubleencore.com/2013/04/unique-identifiers/
In my app, I want UDID of all the devices in which my application is installed. Can i get this ?
Is there any way to get UDIDs ?
Thanks for any help.
I am pretty sure you can't get the UDID from each device your app is installed on. That would open up possibilities to privacy breach - I am sure. You can only get the UDID of the device you are holding in your hand, or if someone sends you their UDID. However in iOS 6 Apple is moving away from the UDID system.
You can get UIID by NSLog(#"%#",[[UIDevice currentDevice] uniqueIdentifier]);
I want UDID of all the devices in which my application is installed.
You can get UIIDs by web service. You need to write a web service to send UIID to your server.
Use of UDID is deprecated, and replaced by UUID.
If you require to collect this, your app will need to make a HTTP connection to a server and record this information (usually in a database).
It depends on what you mean. Do you mean the old UDID for iOS devices, or just a unique identifier for each device?
If it's the latter, see answers to this question.
As I posted in my answer, there is a new NSUUID method you can use.
After you app reads this, of course, you would probably want to post it to your web server for storage.
I have heard some rumours that Apple is rejecting apps for using the iOS5 deprecated method [UIDevice uniqueIdentifier]. Can anyone confirm that they have had their App rejected for this reason? I know of the alternatives to using this deprecated method, but one of our customers is requesting we use a 3rd party library that we know uses this method.
I would be surprised if this is the case as the API method has been deprecated and not made private.
Apple is not rejecting apps because of this. I collect device UDIDs along with tokens within my apps that support push notifications and they have all been approved. UDIDs are simply deprecated, meaning that Apple will eventually not allow you to access them. Everything still works and will be approved.
I heard that Apple deprecated access to UDIDs to prevent developers and third party analysts from being able to identify specific people. If it truly was because of issues with iCloud, Apple would clearly have fixed this instead of inconveniencing everyone else.
Edit: It looks like Apple is rejecting some apps for accessing the device's UDID. Just to be safe, I would use CFUUID to create a random unique identifier. You can use NSUserDefaults or the keychain to save it. The advantage to the keychain is that if the user deletes your app, the keychain items are not deleted so you can still access the UDID if the user reinstalls your app. It will only get deleted if the user restores their device.
Using Identifiers in Your Apps
Starting May 1, the App Store will no longer accept new apps or app updates that access UDIDs. Please update your apps and servers to associate users with the Vendor or Advertising identifiers introduced in iOS 6. You can find more details in the UIDevice Class Reference.
Source: https://developer.apple.com/news/
It appears that App Review is enforcing this rule on apps that transmit the UDID without getting the user's permission -- as suggested by this post -- rather than ones that simply invoke the deprecated API.
We had an update in review for an app that would send the device UDID to our server, on which we would use it to index the user's account. We decided not to take any chances and change our code to generate an app-specific unique identifier, as proposed by documentation on the deprecation of the UDID
now Apps are not permitted to access the UDID and must not use the uniqueIdentifier method of UIDevice. Please update your apps and servers to associate users with the Vendor or Advertising identifiers introduced in iOS 6
NSUUID *uuid = [[UIDevice currentDevice] identifierForVendor];
NSString *uuidString = [uuid UUIDString];
and must to add ADSupport framework
Since May 1, Apple is rejecting all apps which access to the UDID.
But it seems the only thing that they can do is to check if the string "uniqueIdentifier" is in the binary or not.
So even if you don't acces anymore to the uniqueIdentifier of the phone, but you give to one variable the same name, they will find it in the binary and they will reject it cause they can't do the difference.
If you want to know if you binary contain it, you can change the extension of the .ipa (export for ad-hoc deployment) to .zip, unzip it, and do fgrep -R uniqueIdentifier . in the terminal at the payload/ folder.
You can also do this command in your project folder to find the files which contain the string.
This worked for me.
I have a beta tester to whom, 4 months after the last beta test cycle, I sent a new versions' first beta test of an app. When she said that it wouldn't load, we checked her UDID, and it is different than what we used 4 months ago, so my provisioning clearly didn't work.
She says it's the same device used before.
I've yet to further explore what upgrades she might have done or if she (or maybe her child?) has jail-broken it.
Are there any Apple sanctioned actions that would change the UDID on a device?
If you jail break a device, do you need to take further action (e.g., install something with code like UDIDFaker) for the UDID to change?
Thanks!
Henry
I didn't find any official word on whether the UDID can change.
But the documentation, while not being explicit, says the following (in UIDevice Class Reference):
A UDID is a hash value composed from various hardware identifiers such as the device serial number. It is guaranteed to be unique for each device. The UDID is independent of the device name. For devices that use a SIM (subscriber identity module) card, the UDID is independent of the SIM card.
Based on this, I continue to assume that the UDID of a device never change.
You might ask your beta-tester if the device was repaired by Apple, or (more likely), if she changed her device in between. If the device was "repaired", its not impossible that Apple just swapped it with a new one, and she did not realize.
No, the Unique Device ID will always stay the same, and the property is read-only, as you mentioned other than jailbreaking and spoofing a UDID.
Apple has to have a way to identify millions of devices uniquely, so this is why they created the UDID.
UDID can't be modified. You can "change" it for one application for example, it's called spoofing, but it's not permanent - it's useful for debugging for example (swizzling - replace method with custom implementation).
Can I go around Apple and offer applications to users, or do they force you to go through them? How? Just legally?
Aside from the App Store (and jailbreaking), Apple provides two official routes to install applications on the iPhone.
Enterprise Distribution: designed for internal users of a company
Ad Hoc Distribution: allows your app to be installed on up to 100 iPhones
Source: http://developer.apple.com/iphone/program/distribute.html
For phones that are not jailbroken, distribution rules are enforced by the iPhone's code-signing system. The phone won't run any apps that aren't signed by Apple, and the only way to get an app signed is either to get it into the app store or to use ad-hoc distribution.
Ad-hoc is effective but time consuming for more than a few devices, in that you have to get the unique device ID for each device you want to distribute the app to. You then sign the app for that device and send a copy along with a provision file. Some batching is possible-- you can get up to 100 devices in the same ad-hoc build. But if/when Apple finds out you're doing it, they'll close your iPhone developer account (for violating the rules) and then you won't be able to generate any more provision files.
One developer tried using the ad-hoc approach last year when Apple rejected their app (Podcaster). They claimed to have sold something like 1100-1200 copies before Apple shut them down.
Jailbroken phones don't have this limitation, but it's up to you to determine (a) whether the market is big enough and (b) whether enough of those people will be willing to pay for your app. I don't know the answers-- it could well be "yes" to both-- but don't just assume they're true without investigating enough to make a reasonable prediction.
If you wish to distribute applications to phones with out going through the App Store, you must sign each copy of your application for a specific phone handset. If you need more wide spread distribution, all your client phones must be "jail broken". Once a phone is jail broken, it will accept any application for installation.
You can offer applications through Cydia for jailbroken iPhones / iPods. Cydia uses a system similar to Debian's apt. Basically allows users to add custom "sources" (repositories) and install applications provided by those sources.
Obviously this is not supported or approved by Apple since it circumvents the App store and their App approval process.