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.
Related
I cannot find anything on Device check Api in iOS over here. However, let me draw your attention to the fact that, I wanna use and pass Unique ID from my iPhone app to the server always with the pretty much the same ID even after reinstalling the App. Eventually, I got to know that, Device Check Api is well suited for this purpose for the simple reason of Access per-device, per-developer. But I'm bit confused how to use it properly and can anyone help me with the proper and clear-cut guidelines including both front end and back end parts. It would be great if you help me with it. The Apple documentation link is provided here below for the reference, https://developer.apple.com/documentation/devicecheck.
Have you checked this? https://fluffy.es/devicecheck-tutorial/
It explains the whole thing and gives an example.
Edit: But as suggested by #Paulw11 DeviceCheck does not provide a Unique ID, it only gives you access to 2 bits of information (2 booleans really) by device by developper (not by app).
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.
I know there are quite a few threads on this, but it seems none of them would satisfy what I am trying to look for. Here's my constraints:
not a hack that uses private API/framework or undocumented
directory access that would run the risk of app being rejected
because of that
being able to share data across different
vendors / app developers
data can persist outside the lifecycle
of the app (even after app is deleted)
UPDATED: I was in general trying to stay away from using a 3rd party cloud-based service to achieve the goal as this would introduce additional external dependency. But if I have to, I was hoping it could satisfy this one constraint
being able to tell which iOS device it is communicating with. It shouldn't have to uniquely identify the device (which will go into that evil UDID discussion route as we all experienced ). But as long as it can differentiate among different iOS devices it should be fine.
I kind of need this too. I use Parse.com as the backend of all my apps — their free tier should satisfy your development needs.
Parse has APIs available for iOS, Android, Windows 8, OS X, JavaScript and .NET, with all your data available on the cloud on any platform (contrary to Core Data and iCloud). They also offer "Cloud Code," which is code you can execute remotely, to process information remotely and get the data back to your app.
You should definitely check Parse.com out for cloud storage for your app. In my experience, it really gets the job done.
For Data Persistence, I think you might want to take a look at FMDB (although if you decide to persist data locally, it will get deleted with your app, but it might help you, anyways). Core Data is an overkill in many cases.
Edit: Parse.com has an "Installation" class, in which all the devices that have your app installed get listed (wether they're running iOS or Android), uniquely, without you having to type any code.
Maybe this blog post by TextExpander authors will help:
Smile has responded to this by discussing the issue with Apple
engineers at WWDC, filing a bug (#14168862), and checking up on the
status of that bug. We also developed a workaround by storing the
TextExpander data in a new place. Reminders requires user consent to
store and retrieve data. Completed reminders are not normally shown in
its interface. Long-past reminders appear at the bottom of the
completed reminders.
TextExpander touch 2.1 (and later) supports storing shared snippet
data in a long-past, completed reminder. We produced an updated SDK
and kept our developers posted on its progress. Our final SDK was
ready within a few hours of the end of Apple's official iOS 7
announcement.
UPDATE (22.11.2013)
This might not be the best way to do that, because TextExpander's team recently had problems with the App Review Team.
Edit: this only works for apps with the same vendor.
You can save a password to the device's keychain, then access that password from any app.
Using the SSKeychain library...
NSString *service = #"com.yourcompany.yourservice";
// read
NSString *password = [SSKeychain passwordForService:service account:#"user"];
// write
[SSKeychain setPassword:password forService:service account:#"user"];
The password string doesn't have a length limit, so encode all your data as a string and save it there. The keychain entry will persist after the user deletes the app.
One of the ways to do this is using THRIFT. This is a data communication protocol that would need a back end server (private) and THRIFT can be compiled into many languages / platforms. There is a meta language to describe the data and then can be thrift compiled into many languages. Write the data definition once and can be used on many platforms.
More information at.
http://thrift.apache.org/
for me (I have 2 apps and a widged) the best solution is using SSKeyChain and do not forget to add Capabilities for your apps like here
or if you don't wanna to use 3rd party library you can use NSUserDefaults and set the group identifier like here but again do not forget to add the group identifier in Capabilities in AppGroups section for all your apps that have share data.
Is there any way to determine if a user has a specific app installed, or even to count how many apps they have installed?
The information would be used to target information passed to the user.
Not on a stock phone. Jailbroken maybe, but I have not played with the jailbroken side of things.
You could try to open an app via a URL scheme. Using Twitter as an example, one of its URL schemes is twitter://user?screen_name=somename
You can check if you can open that URL:
NSURL *tURL = [NSURL URLWithString:#"twitter://user?screen_name=somename"];
if ( [[UIApplication sharedApplication] canOpenURL:tURL] )
// if here, you can open twitter app
You can extrapolate from here if you want.
Yes if the apps in question are known to you as a developer of that feature and do implement custom URL schemas (which you also need to know). There is a service that tries to collect that information: handleopenurl.com
Short answer: No.
Long answer: there are ways to detect if certain apps that provide the capability are present. For example, the Facebook app (see this question). However, it is not possible to detect apps that do not support that kind of detection, and it is not possible to get a total count of apps (unless, of course, they only had detectable apps, but the likelihood of that is incredibly slim).
Yes and No. On iOS, there are a few methods which can be used, but they won't get you the entire list, only some of the apps. Daniel Amitay has a nice framework for this. You can find it here (iHasApp)
I have used it and it gets most of the apps, but as I said, not all. Daniel explains in his blog post what techniques you can use.
There is a newly introduced issue with iPhone 3.0 SDK and how it deals with the NSURL method for automatically making phone calls. It used to be that you could call a method (NSURL), pass in a string with a URL prefix (tel://, sms, etc...) and the iPhone OS would dispatch the message to the device, such as iTunes, App Store, Phone, SMS, Mail, Safari, etc... The code goes something like this:
[openURL:[NSURL URLWithString:#"tel://8005551212"]];
When the method was called the phone call would be placed automatically. With the iPhone OS 3.0 when the method is called the app pops up a dialogue box asking for confirm the phone call. This breaks several existing apps as well as one that we just pushed into the App Store for review.
Can anyone think of a fix to this issue? I'm currently at a loss for what to do and trying to decide what other ways to handle this new wrench in the works.
I blogged about this and suggested that people contact Apple and make them aware of this issue. I also recommend a fix that a friend and I were thinking about - and that is to use the same "authorization" that location aware apps have; an app knows it's location aware and asks the user if it's okay to use their location.
Again, if anyone has a fix for this issue (and that is within the realm of the iPhone SDK as to not be rejected by Apple) please let me know; I would be greatly appreciative.
Update: Julian Romero Nieto has a good description of the bug and cites the (updated) Apple documentation and shows the issue at hand. You can read his posting to Oper Radar here.
I believe this is included as a security feature - imagine an app that called a 900 number at 3am every day for 10 minutes. If you compare it to the new 'In-App Purchase' API - it's much the same.
The location API comparison is a bad example - getting the users location is a privacy concern, not a financial one.
You can't fix this issue as this is what is intended - anything you do to "fix" the issue will result in an app that won't be approved.
The user experience is considered not to be good when an app can choose to dial a number without the user's consent. It would be possible for software to dial "premium" numbers that cost the user a lot of money without them realising.
This is standard across all mobile software platforms and OS - if it just changed in OS 3.0 then this shows that it must have been an issue that initially Apple thought they could get around. However I think that Mobile Operators will have put pressure on Apple to introduce this as often then end up having to refund the user - but will have already paid out the money to the "premium" number.
I am not sure if "premium" numbers exist in the US as much as they do in Europe and that maybe the reason this is hard to understand.
The RFC for tel:// says to NOT allow autodialing of numbers via the tel: scheme.
So they have to chose between RFC compliance and breaking these few apps.
I hope the chose to ignore the RFC, at least to allow apps to keep dialing if they allow it.
I question whether this is intentional on Apple's part to push users to purchase a new iPhone if they want voice dialing - this problem breaks all of the 3rd party voice dialing apps, making them unsafe and basically useless.
Let's keep up the pressure on Apple to make this a user-configurable setting.
Perhaps you meant newly introduced feature instead of issue?
I don't think you will get Apple to remove the confirmation popup, especially if it is RFC compliance.
Lemmy quote Joel (http://www.joelonsoftware.com/items/2009/06/10c.html) regarding broken apps:
A good platform always has
opportunities for applications that
aren’t just gap-fillers. These are the
kind of application that the vendor is
unlikely ever to consider a core
feature, usually because it’s vertical
— it’s not something everyone is going
to want. There is exactly zero chance
that Apple is ever going to add a
feature to the iPhone for dentists.
Zero.
I would not want some application to make calls, send sms or even connect to internet (living in a country where unlimited mobile data plans are still far in the future) without my consent.
Certainly operator's headache when customers complain about unknown calls on bills.