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.
Related
This question already has answers here:
UIDevice currentDevice identifierForVendor - can this change on an iPad
(5 answers)
Closed 4 years ago.
My server wants to track unique number of devices.
But UIDevice.current.identifierForVendor?.uuidString is changing for each installation.
Please suggest for any alternate.
As an alternative to storing a identifier in the KeyChain, you could try using the generateToken method of the DeviceCheck framework.
Using the DeviceCheck APIs, in combination with server-to-server APIs,
you can set and query two bits of data per device, while maintaining
user privacy. You might use this data to identify devices that have
already taken advantage of a promotional offer that you provide, or to
flag a device that you've determined to be fraudulent.
This question already has answers here:
Programmatically lock and unlock iPhone screen
(8 answers)
Closed 8 years ago.
I've seen an app that activates the lock-screen after showing a local notification (so the user has to enter the passcode).
... and now I wonder how they did this, since I need this kind of functionality for one of my projects. It might even pass Apple's review process because it does make sense for this app... (and, yes, I'm aware that Apple might reject it, but I'd like to give it a shot).
How would I do this???
I don't believe it is possible as the framework that handles this is private.
iOS 8.1 does not offer API to do this. Most likely you have seen an App implementing its own lock screen. You will need to implement something similar.
You can find examples on GitHub, e.g. https://github.com/venmo/VENTouchLock
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.
This question already has an answer here:
Programmatically answer an incoming phone call on iPhone
(1 answer)
Closed 9 years ago.
Is it possible to programmatically answer a call in iPhone? I have already googled about this and found that iOS SDK does not support such feature. But I found an answering machine app in Appstore.
https://itunes.apple.com/in/app/prank-answering-machine-free/id508457142?mt=8
Please help me out.
No this is not possible, the iOS SDK does not allow any interaction with the phone.app.
Also the app you have found is a prank app, one that you start if you receive a call and the play back one the messages from the app.
No, that is not possible. The CoreTelephony framework lets your application receive notifications if there is any change in the call state, but there is no way to answer it.
The app that you mentioned does not say anything about answering a call, from what I can see.
I would say it depends. If you want to make a app and publish it in app store, its not possible. However if you want don't want to publish on app store and willing to use private api, then its possible. Refer this answer.
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.