Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I am not trying to be argumentative here. Just trying to illustrate that these problems could have been avoided with a little more thought on the developers side.

But you yourself offered UDID usage as part of your solution (above). And it was also an Apple sanctioned technique prior to iOS 5. I'm certain if you had needed a similar system pre-iOS 5, you would have used the UDID and not thought twice about it.

arn

----------

You can store settings on an per-install basis, that is, the settings will be there until the user manually deletes the app. Even updates can't mess with these settings.

wouldn't work for global high scores. ;)

Edit: for the record, I'm not "pro-UDID" or anything. Just offering some counter discussion.
arn
 
Last edited:
Correct me if I am wrong but I think the "per install" method will survive a device upgrade if the new device restores from a backup of a previous device. The backup can be from iTunes or iCloud.

You can store settings on an per-install basis, that is, the settings will be there until the user manually deletes the app. Even updates can't mess with these settings. It isn't as great as "per device" settings, but "per install" is how most apps work anyway, and gets the job done in my opinion. I can supply the code to do this if needed.
 
wouldn't work for global high scores. ;)

arn

There is a method or two being tossed around for this actually. One is storing the UUID in iCloud so the app can retrieve it in the future if it gets deleted. I'm not aware of any apps that use this though.

EDIT: I'm not really sure why you comment on these threads though Arn, last I checked you don't actually have any development experience... Don't mean to sound harsh, but weren't you a doctor in your past life?
 
Last edited:
iOS 5 was released to developers on June 6th, 2011. Apple announced the deprecation of UDIDs on August 18th, 2011 and this is there wording: "Deprecated in iOS 5.0. Instead, create a unique identifier specific to your app." That's 8 months ago. These are facts.

Looks like Apple not only gave enough advanced notice, but also told developers exactly what to do to workaround the problem.

Another article that only serves to exemplify the laziness, self-righteousness, and extreme sense of entitlement of some people.

Damn right.
 
EDIT: I'm not really sure why you comment on these threads though Arn, last I checked you don't actually have any development experience... Don't mean to sound harsh, but weren't you a doctor in your past life?

I was a CS major in college. I don't do much programming these days, but I have a background in it and always done small stuff on the side.

arn
 
Wirelessly posted

iEvolution said:
Is there no way for developers to associate scores based on iTunes account name instead?

UDID should not have been allowed to used in the first place, cudos to Apple for giving users a little more privacy, lord knows everyone else is trying to eliminate privacy, especially the government.

There is. It's called game center.
 
It sounds like apps are being rejected during the app review process so existing apps should be okay. The article makes it a bigger deal than it actually is.

How long till you think Apple starts auditing the apps already in the store and pulling ones that aren't in compliance? You seem to be under the impression there's going to be a "grandfathering" of sorts.
 
How long till you think Apple starts auditing the apps already in the store and pulling ones that aren't in compliance? You seem to be under the impression there's going to be a "grandfathering" of sorts.

Probably not long. But now you've been warned. Again. You won't be surprised when it happens, because you would have fixed your game and delivered an update. You're smart that way.

Aren't you?
 
For many developers, this is a very scary thing. For instance, this goes beyond just advertisers. For online games, UDIDs are used to identify specific users, to ensure that they don't get mixed up and that scores (if the game has scores) are being recorded properly. I know a couple apps that use UDIDs for this purpose.

That would be quite a stupid thing to do. I have an iPad. The UUID lets you identify "Gnasher's first iPad". When I buy a new one and someone else uses my old iPad, this stupidity would _completely_ mess up all the scores, because the new user would have the UUID that the stupid game has recorded, and my new iPad would have a different UUID. In other words, contrary to what you claim, _my_ scores would _not_ be recorded properly at all.

And of course the reason why UUIDs allow privacy violations is that companies working together can identify my iPad through the UUID.


If you are a developer you SHOULD have been reading these guidelines which highlight how to work around using the actual device UUID. If they didnt read nor follow these guidelines then they deserve to have their apps pulled/rejected

... and by reading the documentation that you linked to a developer would find a very, very easy way to identify any game player completely reliably in a way that both gets around the practical problems (where the UDID doesn't work, as explained above), and around the privacy problems (only this game and no other game can identify me).


You can store settings on an per-install basis, that is, the settings will be there until the user manually deletes the app. Even updates can't mess with these settings. It isn't as great as "per device" settings, but "per install" is how most apps work anyway, and gets the job done in my opinion. I can supply the code to do this if needed.

"Per install" is actually better, because it works. Unlike the UDID, which only "gets the job done" if you are interested in linking multiple uses of the device together.


Is there no way for developers to associate scores based on iTunes account name instead?

There's something better. An application can ask the operating system for a unique ID and remember it. The ID is not based on anything, it is just a random number, guaranteed to be totally unique.


give me a better way that doesn't require registration.

Google for "CFUUIDCreate".
 
Last edited:
I recently submitted an app update that was rejected because of the UDID. The review panel said that it just needed to alert users (through a note that the UDID was used so that they could choose not to register (and share their UDID). That was 2 weeks ago, and a week before that I submitted an update and it got through fine. I submitted an update for the app today so hopefully they'll let that pass through too. By the sounds of it it might be a good idea to start implementing our own systems!!
 
I think this is good.

tying information to a specific device is bad idea. numerous times i've migrated devices for new ones or had one replaced under apple care. several games lose all my data despite backing them up before replacement. i can't help but think they are tied to UDID.

not to mention any privacy concerns with devs trying to track our every move these days.
 
Wirelessly posted

There are apps like Shopkick than ban users if they think they are abusing their shopping rewards app. They ban the user and the UDID. If you give your phone to someone else, the phone is still banned. They also sell the user's shopping info to retailers based on UDID.
These are the apps that are causing this response from Apple.
 
Ask Google and Apple. They have business models that evolve around this. It's called ads.

Last I checked apple made quite a decent chunk of change of the sale of iPhones, ipads, and Mac computers. I didn't see a line item in the breakdown for iAds.

Back on topic, I think it's great apple is taking steps to keep my data just a bit more private. Using devices and connecting to the Internet will never be 100% anonymous, but every little bit helps.
 
How can anyone possibly think that using UDID is a good thing?

I once used this free texting app on my iPhone3GS (after I had upgraded to the iPhone 4) that only used the UDID to identify the user. I sold the phone a few months later to a friend and he tells me one day that the app installed with my username and all of my texts that I had sent and received using the app. Really? People think that this is the optimum solution to getting around usernames and passwords? :mad:

Developers who use UDID are either lazy and incompetent at best or greedy at worst. The only people who advocate UDID are people who can financially benefit from tracking you.
 
that requires registration.

pick a username, a password etc...

arn

simple solution to that is Game Center!

----------

Ask Google and Apple. They have business models that evolve around this. It's called ads.

Hardly just those pair. Microsoft do it (Facebook and Bing), Yahoo, etc.

----------

It's the sudden nature of it that might be an issue for some.

If you haven't already migrated your existing users' data off UDID, then you can't anymore.

arn

Sudden nature? Devs have been asked not to use UDID for months!
 
give me a better way that doesn't require registration.

arn

make a web service call to generate a unique id (a guid even) and store that locally. Also, a unique id is assigned when a device registers for push notifications (see: application:didRegisterForRemoteNotificationsWithDeviceToken:).
 
You don't even need a web service. If you just pick a random 128-bit uuid, it's almost certain to be unique (2^128 is a very large number). This isn't some obscure solution either, it's The Way To Do It that any experienced developer should know.
 
You don't even need a web service. If you just pick a random 128-bit uuid, it's almost certain to be unique (2^128 is a very large number). This isn't some obscure solution either, it's The Way To Do It that any experienced developer should know.

I agree, i was just suggesting a web service to manage the id's. Also, uuid/guid is not guarenteed to be unique. So it's best if a server handed these out.

...In this context the word unique should be taken to mean "practically unique" rather than "guaranteed unique".
http://en.wikipedia.org/wiki/Universally_unique_identifier
 
As for "surprise" and "scrambling'… Apple started saying as of iOS 5 (which came out in late 2011) to stop using the UDID. Usually, Apple's pattern is to deprecate an API in one major version of the software, and fully remove it in the next. So by that pattern, we'd expect to have at least until iOS 6 to get off of UDID, maybe iOS 7 (if 6 were the deprecation and 7 were the removal).

So while a lot of us were already moving to other systems (like the recommended practice of generating a CFUUID and storing it in the NSUserDefaults or the Keychain), we expected we'd at least have until iOS 6 to do a migration. For example, if an app currently phones home to a server with a UDID, we figured there'd be a few more months to phone home with a "migrate this UDID to this new CFUUID" call.

So a cold turkey, drop-dead, no-more-UDID policy going into effect at an arbitrary time, unrelated to a major iOS version, really is a surprise, as it's atypical of Apple's established behavior.

Also interesting that Flurry sent an e-mail to its users two weeks ago, just before the UDID rumors started popping up on Twitter, saying "we gotta get off UDID, so update to the new version of Flurry by March 23." Wonder if they got an early heads-up from Apple?

--@invalidname
 
Apple has been telling us for months to stop doing it and they would reject apps in the future that used this feature so w were totally caught off guard when they did exactly what they said they would do and gave us months of notice to fix.
 
Ooooo. My life is so over!

And we all know it's a serious as a stroke if some Hobo in Haiti doesn't know Chuy in Chicago has global high score.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.