Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple has had deprecated API's for years in the SDK's, but it is new, unprecedented, and "all of a sudden" that apps are being even been rejected for using those API's. Deprecated means "going away in the future". If Apple wanted developer to stop using the API, then they could simply not offer the API.
Yes, going away in the future. And in the case of this one, that future has arrived. If they simply removed the API, apps that use it would stop working immediately. By deprecating it, they give developers time to transition to a different way of doing it.

Many games allows the user to purchase in-app upgrades with virtual currency (i.e. coins). If the UDID is allowed to be used by the developer, the those upgrades can survive the app being uninstalled and reinstalled. If the UDID is not used, then user will lose all their purchased upgrades when they uninstall the app and reinstall.
In-App Purchase framework provides a way for developers to allow users to restore purchases.
 
Last edited:
Yes, going away in the future. And in the case of this one, that future has arrived. If they simply removed the API, apps that use it would stop working immediately. By deprecating it, they give developers time to transition to a different way of doing it.

That is simply not true. Removing the API does not change any apps that exist on the App Store. Only newly submitted ones would be impacted.


In In-App Purchase framework provides a way for developers to allow users to restore purchases.

That is true for In-App Purchases, but not true for games that use virtual currency which is the vast majority of games today.
 
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

It's not sudden though.
 
How are developers "caught by surprise" and are "scrambling" as it is not exactly news. 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.

Because MacRumors.com had to grab your attention and make it sound like developers were caught off guard when they have known about this for quite sometime.
 
That is simply not true. Removing the API does not change any apps that exist on the App Store. Only newly submitted ones would be impacted.

It doesn't change the apps, correct. But trying running an old app on a new OS (which is when the API would disappear). Can you say "crash"?
 
I'm building an app that will require a user to sign in once and my system will remember their device by its UDID. This kind of sets me back, but guys, don't forget that Apple has provided a fake "UDID" that can randomly generated per app. This should help a bunch of the smaller guys (not the big ad networks) but either way it helps a little. Another idea is to use the device's MAC address.

So you are planning to get rejected from the App Store? Let me check if I get you right: It is actually your intent to violate the privacy of your users? What you call a "fake UDID" is actually _exactly_ what Apple tells you to do. And there is no disadvantage using this _unless_ you want to identify the same user across multiple applications, which is _exactly_ what Apple is banning apps for.
 
How do you associate the high scores on the leaderboard with their device/install without any sort of registration process? UDID (or equivalent) is one easy way.

You create your own, app-specific ID - either by calling the CFUUIDCreate() function, or by assigning one from your server the first time a new device is registered.

The app then stores this ID in it's NSUserDefaults and sends it back to the server each time it reconnects. No user registration required.

This approach has a significant advantage because the ID will be automatically retained (via iTunes backup, or iCloud) across devices or if the user switches to a new device - thus uniquely identifying the user and not just the device.

The only disadvantage of UUID removal is for the ad networks, because they can no longer have an ID (other than IP address, which changes) that they can use to track/identify users between different apps.
 
How is using UDID a good idea for storing high scores, preferences etc? What happens when users upgrade to a new device?

Exactly. We saw that happen with Skies of Glory -a fantastic WWII fighter game. Change your device, lose your ranking/scores.

I posted this to their site as some guys have been playing for a few years and have insane scores/ranking. That is sure to change.
 
The problem with random numbers is you always have to worry about a collision happen because no matter how big of a number you use there is a chance of it happening. Also remember computers can only do sodo random numbers. They can not do true random.
 
So you are planning to get rejected from the App Store? Let me check if I get you right: It is actually your intent to violate the privacy of your users? What you call a "fake UDID" is actually _exactly_ what Apple tells you to do. And there is no disadvantage using this _unless_ you want to identify the same user across multiple applications, which is _exactly_ what Apple is banning apps for.

A login system that I mentioned that authenticates users and remembers them by UDID has completely to do with my need to access or generate a UDID.

Please read up on it here (scroll down a little): http://www.tuaw.com/2011/08/19/ios-5-deprecates-udid-as-identifier-for-developers-but-its-not/ and then read about it in Apple's documentation. The solution isn't a real UDID clearly, or even formatted the same, but it is a working solution PER APP. The random UDID is different every time you generate it.

From the article: "So why isn't losing access to the UDID a big deal, at all? Any developer can always roll their own unique identifier. Apple provides a way to randomly generate one, so you never really had to use the UDID."

----------

You create your own, app-specific ID - either by calling the CFUUIDCreate() function, or by assigning one from your server the first time a new device is registered.

The app then stores this ID in it's NSUserDefaults and sends it back to the server each time it reconnects. No user registration required.

This approach has a significant advantage because the ID will be automatically retained (via iTunes backup, or iCloud) across devices or if the user switches to a new device - thus uniquely identifying the user and not just the device.

The only disadvantage of UUID removal is for the ad networks, because they can no longer have an ID (other than IP address, which changes) that they can use to track/identify users between different apps.

Exactly, thanks for pointing that out man :)
 
Why are developers "scrambling" for a solution to this? They've known for how many months exactly that this was coming?

:rolleyes:

They are scrambling because many of them didn't believe Apple would actually do anything so they didn't bother to do anything either.

ANd now Apple is apparently checking all apps and app updates and rejecting violators.
 
The problem with random numbers is you always have to worry about a collision happen because no matter how big of a number you use there is a chance of it happening. Also remember computers can only do sodo random numbers. They can not do true random.

So generate the UUID server end. Upon initial run the app can request a new UUID if it doesn't already have one, then store it in the local defaults and/or as an icloud value.

This way the server can pre-verify that the UUID hasn't already been used, and if so, generate a new one.
 
It's the sudden nature of it that might be an issue for some.

Sudden?

They told us back in August they were depreciating use of the UDID and to find other methods. It's been a good six months since then so how is this sudden

----------

simplest case is high score.

So you have a game, you want people to be able to save their high scores to the global leaderboard without having to register an account.

How many games actually use that method. Typically they either use something like Facebook, Game Center or make you sign up for their own choice of network.

Game Center, from a user standpoint, is the best because you sign up once and the game uses code to add itself into the system and the user doesn't have to do anything more than perhaps approve the addition (if the developer adds that need). In fact it is so simple from a user standpoint that I'm surprised Apple hasn't made it a requirement that you must use Game Center alongside any other systems with identical functionality as any other nets in use. Just so users can have their choice with no penalties in terms of game play

----------

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

That's what Game Center is.

----------

How long till you think Apple starts auditing the apps already in the store

Who says they aren't.

It's likely that that will be the last step after they hit new apps and new updates but it could have already started.

----------

Many games allows the user to purchase in-app upgrades with virtual currency (i.e. coins). If the UDID is allowed to be used by the developer, the those upgrades can survive the app being uninstalled and reinstalled. If the UDID is not used, then user will lose all their purchased upgrades when they uninstall the app and reinstall.

Fat lot of good that is when I uninstalled from my iPad 2 and reinstalled on my iPad 3.
 
Security and privacy were two of the main components that really helped OSX to take off amongst consumers.

It's the same thing with iOS, consumers aren't comfortable with unknown corporations and individuals being able to mine their personal information and look into their most personal details at will.

Another way to make iOS distinct from Android would be to make consumers private information safe against prying eyes and give the consumers full control over what they wish to share and what they don't wish to share.

I like my iPhone, and will buy more, but I was unhappily surprised to learn that Apps like Facebook's were monitoring text messages and uploading address book contacts. That's not why I installed the Facebook app.
 
There are many legitimate uses of UDID (whitelisting, analytics, etc.) that Apple are effectively wiping out here. What they need to do is provide developers with a "per device, per app" identifier which is isolated from other apps, but consistent between installs. A "per install" identifier (UUID) doesn't really work either, as the user could easily restore from a backup to multiple devices. Google's decision on UDID system is quite solid: It changes only after the device is formatted.

It's surprising how many MacRumors members blindly support the decisions Apple carry out, but make no consideration as to the effect it has on app developers, and their time.

Well it is pretty clear look at the up and down votes on this thread. Point out a legit use for UID or a reason why this was bad huge amounts of negative votes. Claim it is great huge amount of up votes. The blind support is pretty scary and covers a lot about how little clue many people here really have.

Apple can claim all they want that this is about privacy but my guess is that it is a lot more than that. It is more about bean counting and locking down that info only for iAds and cutting everyone else out of the loop. Due to Apple system of preventing access to some type of shared memory it makes really generating a system to prevent the other ad agencies from forming relatvent data shared across multiple apps. While I agree UID is not the best system a way to have some type of shared ID that an App can create would be better. If the phone is wipe that info is lost and a new one is generated.
 
that requires registration.

pick a username, a password etc...

arn

So? If you care enough, you'll do that. If you don't do that or care enough, you don't get the benefits of being able to track your high score with others but you probably aren't going to be heartbroken since you didn't care enough to spend a minute or two creating an account. Seems easy enough to me.
 
@arn

So you are basically worried about the storage and synchronisation of game content, which is inherently some data? It's weird.

You either use Game Center or Use iCloud. Device specific IDs should never really be used to store anything apart from device specific data for e.g. purchase date, customer ID, etc which Apple may be using in their databases.

I wonder why anyone would do this.
 
You create your own, app-specific ID - either by calling the CFUUIDCreate() function, or by assigning one from your server the first time a new device is registered.

The app then stores this ID in it's NSUserDefaults and sends it back to the server each time it reconnects. No user registration required.

This approach has a significant advantage because the ID will be automatically retained (via iTunes backup, or iCloud) across devices or if the user switches to a new device - thus uniquely identifying the user and not just the device.

The only disadvantage of UUID removal is for the ad networks, because they can no longer have an ID (other than IP address, which changes) that they can use to track/identify users between different apps.

Sorry if I miss something being only a newbie to development.

If you stored the ID in a group keychain instead of the App specific Keychain or NSUserDefaults it would have the ability to track the User across apps right?

Trade off being you'd have a keychain item labeled rather honestly against the ad network or shared tracking.
 
Wirelessly posted

arn said:
As I understand it, the problem with using the UDID is that it doesn't track your scores across devices. If you upgrade to a new iPhone, say goodbye to your highscores.

sure, it's not the only solution you'd have available. If you care about your score, you register an account. But no game dev is going to require registration just to post high scores.

arn

Is that what game centre is for?
 
I think one of the main reasons developers are complaining about this is because although Apple stated that UDID was deprecated and devs should move away from it, they didn't state when they would start rejecting apps that used UDID.

Granted devs should / could probably have started moving away as soon as that became public knowledge, but it would have been nice if Apple had given a heads up that as of date X, apps using UDID will be rejected.

Unless I'm blind, the app store review guidelines currently do not state anything along the lines of "Apps using / storing a devices UDID will be rejected", which they probably should. I'd be curious to know what guideline the apps are being rejected under. Possibly one about privacy.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.