|
Now when Apple is to phase out the UDID, what will happen to Unity's class iPhoneSettings.uniqueIdentifier? Are we better off generating our own unique identifier for each game (some md5 string at first boot of the app)?
(comments are locked)
|
|
I only worked once with an Android phone, so i don't even know what uniqueIdentifier has returned by this (old) property, but i guess it's the phone's unique identifier which identifies the device. If that's what it was good for, it has been moved to a more general place. Specifically here: SystemInfo.deviceUniqueIdentifier which should return the UDID (unique device identifier) I'm not sure what this property will return in future builds since, like you said, iOS has removed the possibility to read the UDID of the device. Thanks Bunny for the answer. So I guess we, as developers, are fine just creating something of our own unique identifier (for user data etc when connecting to servers). This is probably the most correct answer there will be, so I'll mark yours as correct, although it would be nice to get an insight from what Apple will do with this as many functions and services depends on this feature.
Jan 27 '12 at 03:44 PM
save
Well, i guess you have to find another way to identify a user. One the one hand the UDID was a reliable user identification, one the other hand it's private data. A lot users don't want to be recognised everywhere. I don't know why Apple removed this feature, but i guess due to security / privacy issues. Beside the fact that Apple is going to deny reading the UDID, the more important thing is what will be returned by
Jan 27 '12 at 06:15 PM
Bunny83
Yes lets hope for that! We would be able though to do a quick md5 hash of, lets say localtime of first boot and some highly random value and store it in the prefs.
Jan 27 '12 at 06:28 PM
save
(comments are locked)
|
By the looks of it Unity have already removed it from the scripting reference.
currently a silent fail for apple devices