Is there a way to find the ECID of a iPhone programmatically?
I know that this is the same question as https://stackoverflow.com/questions/4978725/calling-amdevicecopyvalue-from-mobiledeviceframework-help-please/30481898#30481898 but the answers there use IOKit which has been depreciated. so is there any other way to it.
Can this be done in iOS7?
Could you give us an idea what you need the ECID for?
Apple no longer allow of the usage of unique device ID's, the best you can get is the Vendor ID see the docs here. (Assuming you are going to be submitting to the app store). Also this ID value may change on app reinstall, which may or may not be a problem for you.
The exception to this is the Advertising ID but they may only be used for serving advertisements, see here.
You could also use NSUUID to generate you own ID string, see docs here.
Also, saving whatever ID value you use in the keychain will allow persistance through app reinstalls. Keychain docs are here.
Related
My project have a case: one account user can only log on to one device ( if user log on to app in device A, user can't log on to app in device B). My Idea is: when user login, I'll get the imei Iphone (like android) and send it with request login to server. But I can't get imei. I try with UUID, but UUID will change when re install app. Keychain does not solve the problem. Please help me.
You have to use Keychain to store Unique Id , this will not change even if user delete app
You can use any wrapper Source code to do this
here is an example
https://github.com/Joe0708/KeychainUUID
At the beginning I'd like to mention that I do not know any method that directly answers your question, especially that Apple does not allow you to read IMEI and other similar stuff due to privacy concerns. This has been answered here.
The workaround might be as follows
Take a look at the UIDevice class, especially at the identifierForVendorProperty which provides you (according to documentation ) with a device specific value.
The value of this property is the same for apps that come from the same vendor running on the same device. A different value is returned for apps on the same device that come from different vendors, and for apps on different devices regardless of vendor.
As far as i know some financial apps are secured this way to permit only one device to access the account. This however requires registering a device each time application is reinstalled.
Alternatively you can use UUID you generate within your app (first run) and then you assign it for the user online. It might take the form similar to two step verification process. Be aware however that with such restrictions user will have to be online all the time to use your app.
In my app, I use the CallKit to identify any call from my app user. And there is a logic pop up an alert window that checks whether the user has turned on the Identify and Blocking in app settings. (which you see in my screen shot). And this is the reason I got my app rejected by apple. They told me to add some privacy key in info.plist. But there is no any private key related to Callkit calling identify.
So, I do not know how to deal with this, is there any one have same experience
?Please show me what you do to this problem, thx a lot.
There's conflicting information about this. One (accepted) answer here says it's not needed, but the comments in this blog post and this StackOverflow answer says the key you are looking to add is NSVoIPUsageDescription (for CallKit and VoIP).
So that's the key I would add into my Info.plist file, along with a description string in the value section.
This Apple forum thread has a different possible key that you could try, too.
I'm self taught, and program alone so I have no one else to ask what might be a dumb question but at the same time could be very important. Is keeping your iOS appID and Bundle ID private important? Everyone always whites out their IDs on SO. Or do these pieces of information make their way around the web in plain text?
I ask because I stumbled on a text document of applinks that shows the corresponding iOS app associated with the link and its appID: "ABDJCEI890.com.john.smith" along with associated keys for a popular API. Mine was on the list and I was taken aback thinking that that information should be private.
There are hundreds of apps on this list, just a quick scroll reveals the IDs and keys of: lonelyPlanet, NBCUniversal, Vevo, etc.
Is this important or not important?
Important, no. Embarrassing, perhaps. For example, com.DanielStorm.iHaveNoIdeaWhatImDoing as a published application's Bundle Identifier might be a little awkward if you're trying to maintain a professional image on the App Store.
To be honest, I always hid my app id & bundle id for two reasons
app id, So the competitors wouldn't know what's my app name and what I am working on
bundle id, for most users it their real apple developer name. I don't like the world to know that either
Their maybe other better valid reasons that I don't know.
As for the site that you just mentioned, they didn't get appID info directly from some apple website and I bet they used some sort of web crawlers program that downloaded and decompiled their ipa and read info.plist file. It's really easy to do that. I bet you wouldn't find info for apps that are paid and were never made free.
To be honest its a shame apple doesn't encrypt everything in a ipa. Only certain data is encrypted the rest is easily viewable with a text editor
I read a few threads and it seems like the UDID is deprecated. I also checked out CFUUIDCreate() but that's not really what I'm looking for.
I'm planning to do give aways in my app, so the only information I need from the user is the email address and a unique identifier of the device. I don't want the user to be able to simply reinstall the app and re-register for the give away. The easiest way would be to send some kind of device identifier together with the email address.
Any suggestions?
EDIT: Can I use the MAC address for this purpose? Any other ideas?
EDIT2: Nevermind, that's deprecated aswell...
EDIT3: I think I found something: How to generate unique identifier which should work in all iOS versions?
EDIT4: I'm using the solution in the link above, it works great!
Apple no longer allowes access to UDID from public APIs.
Perhaps you can use a web service to tell the device by it's IP, etc. Although there may be a way to mislead it, it will be better than using nothing.
Another solution would be using iCloud, only a few users would actually make the effort to make a new account.
Whatever you do, remember to make sure you don't break Apple's AppStore guidelines:
https://developer.apple.com/appstore/resources/approval/guidelines.html
(see "20. Contests, sweepstakes, lotteries, raffles, and gambling")
See a list of possible identifications below. Only the CFUUID provides you an unique identifier, but when you reinstall the app the ID is regenerated.
You may save the mail address of the user who received a giveaway in a separate online db.
UDID
unique and permanent device identification
(deprecated)
CFUUID / NSUUID
Random-ID, which is not bound to the device
is for each installed app different
only persistent till you delete the app
Advertising Identifier
for all apps identically
can be changed by the user
can be globally turned off
Identifier for Vendor (IDFV)
identically for all apps of one developer
MAC adress
cannot be used
no identification of a device, because the API returns the same MAC address for all devices
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
UIDevice uniqueIdentifier Deprecated - What To Do Now?
I know there have been quite a few questions on SO about this, but I think that because Apple is moving ahead of schedule and actively denying applications that make use of UDIDs (http://pulse.me/s/7mzKE), us developers need to take an active approach and discuss this matter in bulk.
So the question is - what is a good, stable and correct alternative for unique device identification, other than accessing it's UDID property?
This depends on your needs...if you're looking for a simple device identifier for your application to use, then the documentation on the deprecated uniqueIdentifier method pretty much provides your answer:
Do not use the uniqueIdentifier property. To create a unique identifier specific to your app, you can call the CFUUIDCreate function to create a UUID, and write it to the defaults database using the NSUserDefaults class.
CFUUIDCreate will return a unique handset identifier that is unique to your application. You need to store it in NSUserDefaults because it will change if you make subsequent calls. For most uses this will suffice, and it's not as if Apple didn't provide enough warning of this change (iOS 5 has been out for over six months now, and the developer docs for longer).
The other scenario is where you need to share your device identifier across applications (ie, mobile advertising networks). That's a more complex problem, with a number of alternative options (there's also no guarantee they'll remain around in the future: Apple's primary reason for deprecating the UDID API is presumably to stop cross application user tracking).
My personal favorite is OpenUDID.
You can grab the GitHub here.
I've summarized my thoughts and put a brief description of it here.
SecureUDID, based on OpenUDID but more secure, accessible by domain only (and salt)
More info.
One of a devices 2 or 3 MAC address is already exposed by the protocol specification during any wireless communication.
While I think this is not a typical "how do I overcome this particular technical challenge" I agree it is wildly important and could be well discussed in SO somehow (not sure - wiki? Forum?). I'd be interested to know whether there are discussions in how Flurry beat this.