FWIW, the API to access the UDID no longer exists in iOS 5. That means, if you build an app against the iOS 5 SDK, you can't use it (perhaps you 'can', in the sense that it has become a private API and the hooks are still there inside the OS)
I wonder what happens when you build against iOS 5, but set a 'Deployment Target' of 4.3 or less (which DO have the UDID API).
FWIW, the API to access the UDID no longer exists in iOS 5. That means, if you build an app against the iOS 5 SDK, you can't use it (perhaps you 'can', in the sense that it has become a private API and the hooks are still there inside the OS)
I wonder what happens when you build against iOS 5, but set a 'Deployment Target' of 4.3 or less (which DO have the UDID API).
In that case you can't use the API as it is not available. The question is can you build against the 4.x SDK and submit using this UDID API , which would run on iOS 5.
Whatever. I think I'm right and I'm not going to take your word for it without some kind of proof.
If an app is automatically rejected for using private or unofficial API's (fact) and if Apple clearly indicates that they want you to use only the official API's (fact) and then they personally deprecate the API and tell you that you should be using something else, I'm pretty sure that apps that still use the UDID are going to be rejected from the app store admission process. I mean why wouldn't they? Maybe they will let some apps update for a while without kicking them out because it takes a while to work out an alternative, but new apps would likely be rejected.
Anyway this whole thread is just an example of why people don't like developers. What a colossal waste of time arguing over the exact meaning of the word "killed." It's always going to be somewhat subjective and it's not like "killed" is some official programming term that means something specific anyway.
Every other site is reporting this story is using the word "killed" to describe the situation. Any normal person can see that Apple just "killed" the use of UDID's. If developers want to whine and argue over the exact meaning of the word or wait until Apple actually forces them to change or leave the store, all I can say is that I'm absolutely certain that no one really cares.
You are wrong. And do people "not like developers", or does Professor Peabody not like being contradicted by experts?
Let me explain terms.
1) An api is deprecated when it generates a warning on compile that it will be going away, or private, some time in the future. It is still a public API.
2) An api is hidden or private when it moves from the public to the private headers of a framework ( or has always been private). Still usable, but you have to hack it to compile. On OS X this would allow you to build using private APIs and sell (outside the Mac Store) - however these apis are not guaranteed to continue to work so you would likely break going from OS to OS. On iOS it would be rejected at the app store, the only way in.
3) An app is rejected from the app store when it contravenes Apple's policies.
As it happens, with regards to 3, there is a policy to ban private api, but not deprecated api.
unfortunately, this report is using the term deprecated in ( possibly) a non technical way. It is possible that the API has been made private. It may however, just generate a compile warning in the public header, meaning it is going to go away sometime. Possibly in iOS 6. Since I dont have the latest SDK I dont know.
That said there is, now, no restriction on any app submitting using the iOS 4.3 SDK continuing to use the UDID API. Thats because Apple's policy ( see 3) have not changed, and the API is available on iOS 4.x. They may change their policy, but at the moment - as it now stands - apps can submit for iOS 4.x, which is what they are all doing, with this API intact. Since it is intact in iOS 4.x. and developers are building for iOS 4.x only at the moment, no app is being killed at the moment. If the API is merely deprecated ( generating a warning) then apps for iOS 5 would not be deprecated either.
As devs are not going to build exclusively for iOS 5 for a while, then this is also moot. Now, Apple may change their policy at the app store, but it would be that change of policy which would ban existing apps built against 4.x from using the UDID api, not the change to a header file in iOS 5.0,
( and that would be a very strange policy, as the UDID API is a formal API from Apple, declared in headers. An API is a promise to work, and a promise that the work is "legal". Banning apps built against iOS 4.x from using an Apple approved API for iOS 4.x would be weird indeed).
So nothing is banned, or killed yet. Lets use terms exactly rather than what the peanut gallery thinks it is.
In that case you can't use the API as it is not available. The question is can you build against the 4.x SDK and submit using this UDID API , which would run on iOS 5.
I think so.
Since iOS 4.0 came out, each new Xcode version ships with only the latest version of the SDK (Before that, you would have 2.2, 3.0, 3.1 etc and you could choose the target).
Unless you keep backups of previous SDKs and "manually add" them to your Xcode config (I'm not sure about the details of this), it is currently not possible to build against an SDK version lower than the one that shipped with your version of Xcode.
You can still set the 'minimum supported version' (i.e. deployment target ) all the way back to 3.1.x... What happens then, if you use 'deprecated' APIs? (e.g., UITableViewCell's setText My experience is that they get marked as deprecated in the docs and you get a nice, yellow warning in Xcode. Never pushed it so far as AppStore Submission, so can't really tell if Apple will reject it or not.
No, it's a "This is a private API now, thanks very much," move.
Do you have any proof that Apple don't use this API? are you saying that when it was, and is, public in pre iOS 5 builds the normal dev could use it but Apple didn't? Unlikely.
And since Apple apps are not restricted from using private API why would they stop?
Do you have any proof that Apple don't use this API? are you saying that when it was, and is, public in pre iOS 5 builds the normal dev could use it but Apple didn't? Unlikely.
And since Apple apps are not restricted from using private API why would they stop?
Do you have any proof that they will use it? Apple is innocent until proven otherwise.
Before this turns into a conspiracy theory of how evil big-corporation-Apple is, I would like to take a minute to think of for what on earth they would need your UDID. They have your iTunes account, Apple ID, Credit card, iCloud account... That's much more valuable than the UDID of your "old iPhone 3G-become-kids-ipod-touch".
Do you have any proof that Apple don't use this API?
Oh, no no, I have no idea myself right now. I'm just saying that if anyone looks into it and finds that iAd doesn't use it right now, then it likely won't be using it in the future because it wouldn't need to be. Apple wouldn't stop using it if they WERE using it now, but if they're not currently using it, I don't see them starting to do so, is all.
Do you have any proof that they will use it? Apple is innocent until proven otherwise.
Before this turns into a conspiracy theory of how evil big-corporation-Apple is, I would like to take a minute to think of for what on earth they would need your UDID. They have your iTunes account, Apple ID, Credit card, iCloud account... That's much more valuable than the UDID of your "old iPhone 3G-become-kids-ipod-touch".
The API is not now illegal so there is no restriction on Apple using it now, and since Apple apps can use the private API no restriction in the future. They probably use it in IAds but nowhere else, because poeple dont log in once the app is downloaded ( apps using iAds are generally free and may not use iCloud). The idea of the UDID is to sample when the app is used, or where the user goes to in the app ( per run). I think analytic packages like Flurry use it.
In any case I dont think the use of a UDID was all that big a deal, as devs use it not to match information on users with other devs because the individual dev does not have the information from other devs s (Flurry might, however) but for simple purposes of per device heuristics. i think this an over-reaction by Apple.
The general use of the UDID is not an issue, Apple using it mght be ( as a uncompetitive act) but I cant say either way whether they do, or not.
I had read somewhere that UDID was used by a few devs to limit the number of authorized devices, against the terms of their contract with Apple. Has anyone else heard of this? I tried looking for the reference and can't find it.
This is a nice move on Apple's part, and helps differentiate iOS from Android.
The biggest difference between the two right now IMO: Android requires your specific consent, opt-in, to share your details with any third party. Apple on the other hand requires that you opt-out if you don't want your personal data shared with others outside of Apple. If you don't take the time to visit Apple and change your privacy settings, Apple has the right to share your personal information with others without notice to you.
And while Google is trying to disallow fake names on Google+, Apple asks for your Social Security number, the ideal tracking number to link all your data together from public and private sources. Which is more of a red flag if personal privacy is a primary concern?
A good solution to this would be for the OS to provide a hash code based on the UDID and your app's signature. Then you couldn't access the UDID to compare with other app vendors because the hash is unique to your device AND app.
The more privacy people have the better. Now why don't they create a feature in Safari that prevents all web beacons? I think all computers should not even have MAC addresses. There needs to be total privacy on the internet for users. As the US government and other governments constantly spy on us, we need more privacy not less. Even ISPs have been shown to track the habits of their customers.
Start a collection, lets launch our own satellites!
Comments
I no longer work for the company, but I'm pretty sure this is gonna cause one hell of a headache as UDID was the only solution.
This was a popular legitimate use for UDID.
I wonder what happens when you build against iOS 5, but set a 'Deployment Target' of 4.3 or less (which DO have the UDID API).
FWIW, the API to access the UDID no longer exists in iOS 5. That means, if you build an app against the iOS 5 SDK, you can't use it (perhaps you 'can', in the sense that it has become a private API and the hooks are still there inside the OS)
I wonder what happens when you build against iOS 5, but set a 'Deployment Target' of 4.3 or less (which DO have the UDID API).
In that case you can't use the API as it is not available. The question is can you build against the 4.x SDK and submit using this UDID API , which would run on iOS 5.
I think so.
Whatever. I think I'm right and I'm not going to take your word for it without some kind of proof.
If an app is automatically rejected for using private or unofficial API's (fact) and if Apple clearly indicates that they want you to use only the official API's (fact) and then they personally deprecate the API and tell you that you should be using something else, I'm pretty sure that apps that still use the UDID are going to be rejected from the app store admission process. I mean why wouldn't they? Maybe they will let some apps update for a while without kicking them out because it takes a while to work out an alternative, but new apps would likely be rejected.
Anyway this whole thread is just an example of why people don't like developers. What a colossal waste of time arguing over the exact meaning of the word "killed." It's always going to be somewhat subjective and it's not like "killed" is some official programming term that means something specific anyway.
Every other site is reporting this story is using the word "killed" to describe the situation. Any normal person can see that Apple just "killed" the use of UDID's. If developers want to whine and argue over the exact meaning of the word or wait until Apple actually forces them to change or leave the store, all I can say is that I'm absolutely certain that no one really cares.
You are wrong. And do people "not like developers", or does Professor Peabody not like being contradicted by experts?
Let me explain terms.
1) An api is deprecated when it generates a warning on compile that it will be going away, or private, some time in the future. It is still a public API.
2) An api is hidden or private when it moves from the public to the private headers of a framework ( or has always been private). Still usable, but you have to hack it to compile. On OS X this would allow you to build using private APIs and sell (outside the Mac Store) - however these apis are not guaranteed to continue to work so you would likely break going from OS to OS. On iOS it would be rejected at the app store, the only way in.
3) An app is rejected from the app store when it contravenes Apple's policies.
As it happens, with regards to 3, there is a policy to ban private api, but not deprecated api.
unfortunately, this report is using the term deprecated in ( possibly) a non technical way. It is possible that the API has been made private. It may however, just generate a compile warning in the public header, meaning it is going to go away sometime. Possibly in iOS 6. Since I dont have the latest SDK I dont know.
That said there is, now, no restriction on any app submitting using the iOS 4.3 SDK continuing to use the UDID API. Thats because Apple's policy ( see 3) have not changed, and the API is available on iOS 4.x. They may change their policy, but at the moment - as it now stands - apps can submit for iOS 4.x, which is what they are all doing, with this API intact. Since it is intact in iOS 4.x. and developers are building for iOS 4.x only at the moment, no app is being killed at the moment. If the API is merely deprecated ( generating a warning) then apps for iOS 5 would not be deprecated either.
As devs are not going to build exclusively for iOS 5 for a while, then this is also moot. Now, Apple may change their policy at the app store, but it would be that change of policy which would ban existing apps built against 4.x from using the UDID api, not the change to a header file in iOS 5.0,
( and that would be a very strange policy, as the UDID API is a formal API from Apple, declared in headers. An API is a promise to work, and a promise that the work is "legal". Banning apps built against iOS 4.x from using an Apple approved API for iOS 4.x would be weird indeed).
So nothing is banned, or killed yet. Lets use terms exactly rather than what the peanut gallery thinks it is.
In that case you can't use the API as it is not available. The question is can you build against the 4.x SDK and submit using this UDID API , which would run on iOS 5.
I think so.
Since iOS 4.0 came out, each new Xcode version ships with only the latest version of the SDK (Before that, you would have 2.2, 3.0, 3.1 etc and you could choose the target).
Unless you keep backups of previous SDKs and "manually add" them to your Xcode config (I'm not sure about the details of this), it is currently not possible to build against an SDK version lower than the one that shipped with your version of Xcode.
You can still set the 'minimum supported version' (i.e. deployment target ) all the way back to 3.1.x... What happens then, if you use 'deprecated' APIs? (e.g., UITableViewCell's setText
one question, willapples own iad network utilize teh UDID?
If it doesn't now, it won't later.
Is this meant as a privacy move of just a way to give their in house ad network a leg up?
No, it's a "This is a private API now, thanks very much," move.
If it doesn't now, it won't later.
No, it's a "This is a private API now, thanks very much," move.
Do you have any proof that Apple don't use this API? are you saying that when it was, and is, public in pre iOS 5 builds the normal dev could use it but Apple didn't? Unlikely.
And since Apple apps are not restricted from using private API why would they stop?
Do you have any proof that Apple don't use this API? are you saying that when it was, and is, public in pre iOS 5 builds the normal dev could use it but Apple didn't? Unlikely.
And since Apple apps are not restricted from using private API why would they stop?
Do you have any proof that they will use it? Apple is innocent until proven otherwise.
Before this turns into a conspiracy theory of how evil big-corporation-Apple is, I would like to take a minute to think of for what on earth they would need your UDID. They have your iTunes account, Apple ID, Credit card, iCloud account... That's much more valuable than the UDID of your "old iPhone 3G-become-kids-ipod-touch".
Do you have any proof that Apple don't use this API?
Oh, no no, I have no idea myself right now. I'm just saying that if anyone looks into it and finds that iAd doesn't use it right now, then it likely won't be using it in the future because it wouldn't need to be. Apple wouldn't stop using it if they WERE using it now, but if they're not currently using it, I don't see them starting to do so, is all.
Sorry for the confusion.
Do you have any proof that they will use it? Apple is innocent until proven otherwise.
Before this turns into a conspiracy theory of how evil big-corporation-Apple is, I would like to take a minute to think of for what on earth they would need your UDID. They have your iTunes account, Apple ID, Credit card, iCloud account... That's much more valuable than the UDID of your "old iPhone 3G-become-kids-ipod-touch".
The API is not now illegal so there is no restriction on Apple using it now, and since Apple apps can use the private API no restriction in the future. They probably use it in IAds but nowhere else, because poeple dont log in once the app is downloaded ( apps using iAds are generally free and may not use iCloud). The idea of the UDID is to sample when the app is used, or where the user goes to in the app ( per run). I think analytic packages like Flurry use it.
In any case I dont think the use of a UDID was all that big a deal, as devs use it not to match information on users with other devs because the individual dev does not have the information from other devs s (Flurry might, however) but for simple purposes of per device heuristics. i think this an over-reaction by Apple.
The general use of the UDID is not an issue, Apple using it mght be ( as a uncompetitive act) but I cant say either way whether they do, or not.
This is a nice move on Apple's part, and helps differentiate iOS from Android.
The biggest difference between the two right now IMO: Android requires your specific consent, opt-in, to share your details with any third party. Apple on the other hand requires that you opt-out if you don't want your personal data shared with others outside of Apple. If you don't take the time to visit Apple and change your privacy settings, Apple has the right to share your personal information with others without notice to you.
And while Google is trying to disallow fake names on Google+, Apple asks for your Social Security number, the ideal tracking number to link all your data together from public and private sources. Which is more of a red flag if personal privacy is a primary concern?
I think all computers should not even have MAC addresses. There needs to be total privacy on the internet for users.
That would be like ordering a product from a mail-order catalogue and refusing to give them your mailing address.
The more privacy people have the better. Now why don't they create a feature in Safari that prevents all web beacons? I think all computers should not even have MAC addresses. There needs to be total privacy on the internet for users. As the US government and other governments constantly spy on us, we need more privacy not less. Even ISPs have been shown to track the habits of their customers.
Start a collection, lets launch our own satellites!