This question already has answers here:
UIDevice uniqueIdentifier deprecated - What to do now?
(32 answers)
Closed 9 years ago.
After 1st May Apple is going to reject new apps and updates which are accessing to uniqueIdentifier. They introduced couple new methods in iOS 6.x which is good, but... what if I need my application run on older versions of SDK? So, my code would look like:
if ([UIDevice instancesRespondToSelector:#(identifierForVendor)]) {
deviceId = [UIDevice currentDevice] identifierForVendor];
} else {
// WHAT SHOULD BE HERE?
}
What should developers use if it is old SDK? Moreover, even if let's say I find something to use the value would be different once user upgrades his OS version, which is obviously bad - we would have two different ids for the same device.
What should developers use if it is old SDK?
Apple won't accept apps built with an SDK that's more than a few versions old, so you may not have the option of using the SDK that you're thinking of. You can still set the minimum supported iOS version to older versions, but you probably won't be able to use -uniqueIdentifier even when running on pre-6.0 devices.
-[UIDevice uniqueIdentifier] has been deprecated since iOS 5.0, so you've had nearly 2 years to deal with the fact that it's going away. It's too late at this point to try to sneak in another update that uses the UDID; depending on what you do with the UDID you may have a problem. There are several good solutions for replacing the UDID that are within the spirit of the new rules, but again, the window for switching to them seamlessly is more or less closed.
even if let's say I find something to use the value would be different
once user upgrades his OS version, which is obviously bad - we would
have two different ids for the same device.
Consider the reason that the UDID was deprecated: users don't want you to be able to track their devices without their permission, and Apple surely doesn't want to be seen as enabling you to do it. So, if you do find a solution that works for you and which doesn't use the UDID, you might still risk rejection if your scheme doesn't allow the user to opt out of whatever tracking you're doing.
Related
I have an application whose minimum version has been set to iOS 7.0. This application also uses NSUserDefaults dictionary. This application is using UIAlertView and UIActionSheet extensively (not sure how much Apple non-disclosure covers). Now, with iOS 8.0, these two views have been deprecated and have been replaced by controller UIAlertController. Now, there are two ways that I can see which can help me in updating the app for iOS 8.
Raise the minimum version to iOS 8.0 for the update. This way, the users running iOS 7.0 won't be able to see the update. However, it leads to the following situation :-
However, there is one problematic case, and that comes from upgrades
performed from within iTunes or on a device with a higher version
number that is then synced to iTunes. When the user syncs the older
device with iTunes, iTunes will actually delete the application from
the device because it cannot run the new version currently within
iTunes. I had a couple of users with original iPod touches report this
when I upgraded one of my applications to only support 4.0.
The above comment is present under the accepted answer at the following url :-
Raising minimum iOS Deployment Target Version for App Update
Since, the application is using NSUserDefaults dictionary, the relevant entries in the dictionary would get erased when the application is deleted.
The other option is for me to detect in the code which version is being used and code accordingly using if-else statements. This would enable me to keep the iOS 7.0 as the minimum version and might also help me in deploying the update for iOS 8.0. However, this seems like a lot of work which can potentially lead to bugs.
So, I was wondering which option is better between the above 2 ways ? (This application would only be using Objective-C for now due to some constraints).
The best thing to do from the user's perspective is probably to code using UIAlertView and UIActionSheet even though they're deprecated. Keep your iOS 7 target the same as it's been. Xcode shouldn't give you warnings since you're using the older version as your base target. You won't need to change anything about your code and it should still work well enough.
Once you're ready to switch (perhaps when iOS 9 comes out), I would switch your base target to iOS 8 and update your code to use UIAlertController everywhere. To me, it doesn't make sense to spend time trying to support two different versions if it's just an API deprecation that still allows your code to work how you've written it for years. Saves resources and energy to just update it later.
But it's really up to you and how much you want to support iOS 7. I think it doesn't make sense to drop support until the next version comes out. I always try to support the current and last versions so there are no annoyed customers, but it depends on your own needs.
If you have analytics integrated, check out percentage of iOS 8 adoption once it's been released for the public. If not, it's a great opportunity to add it to find out how up to date your customers are!
I have done a lot of research on this so please read the question before marking this as similar to some other question.
Our app needs to uniquely determine an iPhone such that even when user completely wipes a phone, when he runs our app we can be sure that it is the same device. The most important thing is we also need to determine devices over multiple Apple ID users so suggestions containing Keychain access and uniqueVendorID might not work as those change when another user starts using that phone. And as I have read using MAC addresses and old UDID for devices is not longer available as of iOS 6.0. I went through [UIDevice identifierForVendor] but this NSUUID changes when all the app by the same vendor has been uninstalled Reference.
I have looked through these resources:
UIDevice uniqueIdentifier Deprecated - What To Do Now?
and
What is a long-term method I can use to uniquely identify an iOS device?
I can not disclose the nature of work that my app performs due to non-disclosure, but to clarify what I require:
Multiple users might use our app on same phones, I need a way to know that the device user A used before and has reported to have handed over to user B is the same device on which our app was run. Is there any way to achieve this?
There's no way to achieve this.
If it's really the case that different users might use your app on the same device after a factory reset of the device, then what you want is not possible. Apple deprecated UIDevice uniqueIdentifier which would have been the way to do this.
as long as they dont restore/wipe the device identifierForVendor is ok
This question already has answers here:
UIDevice uniqueIdentifier deprecated - What to do now?
(32 answers)
iOS unique user identifier [duplicate]
(7 answers)
Closed 8 years ago.
First of all, I'd like to say that I'm fully aware that uniqueIdentifier has been deprecated and there are identifierForVendor & advertisingIdentifier.
My question is, if there is a way to have a fully persistent device identifier which lives through anything like reboots, app uninstalls, etc.
Currently we use identifierForVendor which is OK - but one of our product's main requirements is to allow quick login without any registration, and when people delete our app their save acts as a "local save" (even though it's hosted on our servers) - as their identifierForVendor changes.
Hope someone had better luck than me in finding an answer (or if there even is an answer :P)
Thanks
The best you can do is create a guid yourself and store it in the keychain for your app. That will survive uninstalls and reboots, but not system wipes. If the user logs in to some cloud service that you can create an association with on your server, e.g. Game Center or Facebook, then that id is generally stable across system wipes and you could do a lookup there. Be careful not to violate those services TOS, however.
I`m developing an app that uses MKMapView, and I need it to run in iOS4, iOS5 and iOS6.
My question is, if I develop using the new iOS MapKit features, can someone using iOS4 see things like routing from sourceAddress to destinationAddress?
Yes and no.
If your write a maps app using iOS 6 features, it won't run on older versions of iOS, unless you check for the existence of those methods.
More generally speaking, the MapKit framework is smart enough to show the iOS 6 maps where appropriate, and to use Google Maps everywhere else. However, you need to avoid using the routing features where it's not supported. So, to abswer your question, users on iOS 4 and 5 will not see the new routing features.
So, if your app doesn't use new maps features, you're totally fine. If it does, you'll need to take steps, such as weak linking and method checking to ensure that your app doesn't try to run new API on older system versions. Running new code on iOS versions that don't support said code will crash, of course.
Please refer the answer given in this post.
Should I be worried about rumors that Apple will stop using Google Maps in iOS6?
It has descriptive answer of your question.
In the documentation, it states which OS versions specific functions work on. I don't have the documentation with me (on a PC currently) but if those methods were added in iOS6 they won't be available in earlier versions. What you can do to work around that is use #ifdef to check the OS version of the user and disable features as necessary.
Please note, that iOS6 is under NDA so questions about specific methods introduced in it should be kept in the Apple Developer Forums.
Edit: #ifdef is not the way to stop it from running. You just have to check for the version of the OS in your app and do something like:
if (os >= 6) sourceAddress stuff
else if ((os >= 5) && (os < 6) ignore sourceAddress stuff
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
UIDevice uniqueIdentifier Deprecated - What To Do Now?
I have learnt that apple is going to remove the access of udid from the system in iOS5.For All of us who rely so much on this,what would be the solution?Even ads and analytics would seize to work.Would there be a work around for that?Thanks for any answer
Apple is NOT removing access to UDID, it's just deprecating it.
So, Apple doesn't want you to use it anymore, but they will not forbid it yet, they just strongly recommend using a new feature of iOS 5 that shouldn't be discussed here while under NDA. Compiler will give you a warning if you access udid, but it's still there and it works, so stop spreading panic.