How will this affect TestFlight and other such apps? Don't they still need your UDID?
iOS developers: Say goodbye to UDIDs
21–30 of 45 posts
Re: iOS developers: Say goodbye to UDIDs
#22It's not a big deal. Just use the: [[ASIdentifierManager sharedManager] advertisingIdentifier]; for advertising across apps from different vendors or: [[UIDevice currentDevice] identifierForVendor]; for tracking your own library of apps or save a: CFUUIDCreate(); for tracking a specific app. Developers who are upset that these IDs could be changed by the user if they restore their device or deliberately reset them ar…
One problem with both advertisingIdentifier and identifierForVendor is that they are iOS 6+ only. That shuts out 10% of my user base.
And more than 30% for me.
Re: iOS developers: Say goodbye to UDIDs
#23It's not a big deal. Just use the: [[ASIdentifierManager sharedManager] advertisingIdentifier]; for advertising across apps from different vendors or: [[UIDevice currentDevice] identifierForVendor]; for tracking your own library of apps or save a: CFUUIDCreate(); for tracking a specific app. Developers who are upset that these IDs could be changed by the user if they restore their device or deliberately reset them ar…
Heads up to iOS devs: the advertising identifier is generated and changes each time that method is called. Generally a good idea to store it in user defaults or keychain and check for it before generating a new one. More info there http://stackoverflow.com/a/12933454/122115
The advertising identifier does not change on every call.
Using "CFUUIDCreate" IS WRONG, though. It generates a GUID. That's what CFUUIDCreate is supposed to do. But it's the wrong method to call to get the advertising identifier.
You get the advertising identifier from ASIdentifierManager, and it does not change unless the user resets it.
Re: iOS developers: Say goodbye to UDIDs
#24Earlier quoted context omitted.
Heads up to iOS devs: the advertising identifier is generated and changes each time that method is called. Generally a good idea to store it in user defaults or keychain and check for it before generating a new one. More info there http://stackoverflow.com/a/12933454/122115
The advertising identifier does not change on every call. Using "CFUUIDCreate" IS WRONG , though. It generates a GUID. That's what CFUUIDCreate is supposed to do. But it's the wrong method to call to get the advertising identifier. You get the advertising identifier from ASIdentifierManager, and it does not change unless the user resets it.
That's what I get for informing others of something I hadn't actually confirmed. Thanks for the correction. :)
Re: iOS developers: Say goodbye to UDIDs
#25How will this affect TestFlight and other such apps? Don't they still need your UDID?
I beleive testflight doesn't use the App Store to deliver the application so should be okay.
An update to the testflight sdk should be sufficient for production applications with testflight integration.
Re: iOS developers: Say goodbye to UDIDs
#26How will this affect TestFlight and other such apps? Don't they still need your UDID?
TestFlight gets your UUID by having you enroll your device in their MDM system. Support for this will likely never go away.
Re: iOS developers: Say goodbye to UDIDs
#27Was there ever a good reason for using UDID anyway? The only examples I've seen are user tracking for ads (has privacy issues) or a horribly broken login system. Anyone bothered by this is probably doing something wrong.
One use of UDID is verifying in-app purchase receipts. It's demonstrated in the sample code associated with Apple's article titled "In-App Purchase Receipt Validation on iOS".
See: https://developer.apple.com/library/ios/#releasenotes/StoreK...
Re: iOS developers: Say goodbye to UDIDs
#28The real story here is not the UDID ban which we knew was coming (and is easily counter-able as demonstrated in the comments already), but the forced iPhone 5 support. Now this wouldn't be an issue except that Apple doesn't allow you to support the iPhone 5 without targeting iOS 4.3 or higher. So this kills off support for iOS 3.1.3-4.2. This might not seem like such a bad thing, but if you're targeting certain demog…
Apparently, with the lipo tool, you can still support iOS below version 4.3 and Apple won't reject it.
Re: iOS developers: Say goodbye to UDIDs
#29Was there ever a good reason for using UDID anyway? The only examples I've seen are user tracking for ads (has privacy issues) or a horribly broken login system. Anyone bothered by this is probably doing something wrong.
One use of UDID is verifying in-app purchase receipts. It's demonstrated in the sample code associated with Apple's article titled "In-App Purchase Receipt Validation on iOS". See: https://developer.apple.com/library/ios/#releasenotes/StoreK...
Never noticed that as I don't have any in app purchases that actually cost me anything. This usage would seem to be more because the ID is available rather than because it is needed though.
The bit about non-public APIs on that page is interesting though - if there is a genuinely necessary use case for device IDs it may not be affected.
Re: iOS developers: Say goodbye to UDIDs
#30It's not a big deal. Just use the: [[ASIdentifierManager sharedManager] advertisingIdentifier]; for advertising across apps from different vendors or: [[UIDevice currentDevice] identifierForVendor]; for tracking your own library of apps or save a: CFUUIDCreate(); for tracking a specific app. Developers who are upset that these IDs could be changed by the user if they restore their device or deliberately reset them ar…
One problem with both advertisingIdentifier and identifierForVendor is that they are iOS 6+ only. That shuts out 10% of my user base.
I know you're complaining, but only having 10% of your users not on the latest OS update is really something we should be cheering.
The progress (some) OS vendors have made at keeping people current is really pretty fantastic when you compare to the situation 10 years ago.