I wish to create a User system based on each unique iOS device. This way, user don't have to register for my service and they can't delete and reinstall my app to become a "new user" again.
I wanted to use the UIDevice uniqueIdentifier but Apple has deprecated and asked us to use identifierForVendor. The problem with identifierForVendor is that if a user uninstalls my app and reinstalls it, they are view as a "new user" since the identifier changes.
OpenUDID & SecureUDID is also deprecated. Please help me solve this issue. Thank you.
You got it:
Apple has deprecated and asked us to use identifierForVendor
Apple did that to prevent you from tracking down users. Some time ago you were able to ask the system for its MAC address to get a kind of identifier but Apple also changed that API: Now all devices return the same MAC address when being asked.
So short answer: There is no way left for us to get an ID that is really unique and immutable, sorry. The only way to somehow track user's is by vendor ID, as you said, or by letting them register their eMail address. Even though they could change that information when reinstalling the app.
Related
I'm developing now an app for Apple TV. It is a client-server app. On registration, users get a free trial period. My goal is to avoid situations when user will just register new account or reinstall the app and get the trial period again. I need to identify if trial was already activated for each concrete device. So I would like to know if there is a legal or semi-legal way to identify each device? I will appreciate any ideas!
You can store some value in the Keychain (read more about it
here) and check if this value was previously stored in the Keychain. If so, it means that user installed your application before.
You can use identifierForVendor (documentation) but that changes once the app is uninstalled.
The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them.
Perhaps you could couple that with a user's email address to prevent creating new accounts. Not foolproof, but certainly makes it more difficult for the user to get around it. They would need to uninstall the app and use a different email address to circumvent you.
How are we supposed to uniquely identify devices now that the UDID has been deprecated? I need to be able to uniquely identify a device even if the user uninstalls my app and then reinstall it. The new identifierForVendor doesn't work for this purpose because it will randomly generate again once the user uninstalls the app. I also can't use the MAC address to identify the device because it doesn't work in iOS 7.
The advertisingIdentifier seems to work for my purposes but I heard that if you're not actually using it for advertising Apple will reject your app?
Does anyone know of a way to reliably identify a device?
According to Apple, you should be using the vendor or advertising identifiers. Vendor doesn't work for you obviously, but you are fine to use advertisingIdentifier.
The advertisingIdentifier seems to work for my purposes but I heard that if you're not actually using it for advertising Apple will reject your app?
They are not currently rejecting apps for using avertisingIdentifier in place of uniqueIdentifier as a device ID. I just had a version of my app approved that uses advertisingIdentifier for purposes other than advertising. A bigger negative is that users can change this identifier any time they like, which is guaranteed to mess up your reporting.
I have heard some rumours that Apple is rejecting apps for using the iOS5 deprecated method [UIDevice uniqueIdentifier]. Can anyone confirm that they have had their App rejected for this reason? I know of the alternatives to using this deprecated method, but one of our customers is requesting we use a 3rd party library that we know uses this method.
I would be surprised if this is the case as the API method has been deprecated and not made private.
Apple is not rejecting apps because of this. I collect device UDIDs along with tokens within my apps that support push notifications and they have all been approved. UDIDs are simply deprecated, meaning that Apple will eventually not allow you to access them. Everything still works and will be approved.
I heard that Apple deprecated access to UDIDs to prevent developers and third party analysts from being able to identify specific people. If it truly was because of issues with iCloud, Apple would clearly have fixed this instead of inconveniencing everyone else.
Edit: It looks like Apple is rejecting some apps for accessing the device's UDID. Just to be safe, I would use CFUUID to create a random unique identifier. You can use NSUserDefaults or the keychain to save it. The advantage to the keychain is that if the user deletes your app, the keychain items are not deleted so you can still access the UDID if the user reinstalls your app. It will only get deleted if the user restores their device.
Using Identifiers in Your Apps
Starting May 1, the App Store will no longer accept new apps or app updates that access UDIDs. Please update your apps and servers to associate users with the Vendor or Advertising identifiers introduced in iOS 6. You can find more details in the UIDevice Class Reference.
Source: https://developer.apple.com/news/
It appears that App Review is enforcing this rule on apps that transmit the UDID without getting the user's permission -- as suggested by this post -- rather than ones that simply invoke the deprecated API.
We had an update in review for an app that would send the device UDID to our server, on which we would use it to index the user's account. We decided not to take any chances and change our code to generate an app-specific unique identifier, as proposed by documentation on the deprecation of the UDID
now Apps are not permitted to access the UDID and must not use the uniqueIdentifier method of UIDevice. Please update your apps and servers to associate users with the Vendor or Advertising identifiers introduced in iOS 6
NSUUID *uuid = [[UIDevice currentDevice] identifierForVendor];
NSString *uuidString = [uuid UUIDString];
and must to add ADSupport framework
Since May 1, Apple is rejecting all apps which access to the UDID.
But it seems the only thing that they can do is to check if the string "uniqueIdentifier" is in the binary or not.
So even if you don't acces anymore to the uniqueIdentifier of the phone, but you give to one variable the same name, they will find it in the binary and they will reject it cause they can't do the difference.
If you want to know if you binary contain it, you can change the extension of the .ipa (export for ad-hoc deployment) to .zip, unzip it, and do fgrep -R uniqueIdentifier . in the terminal at the payload/ folder.
You can also do this command in your project folder to find the files which contain the string.
This worked for me.
So I already have 2 versions out on appstore..
One app is a free but limited version.
The other is a paid unlimited. The basic layout..
I have had questions from companies wanting to buy the app and give to their employees. So they don't have to buy the app with their personal accounts..
So I was thinking of releasing a 3rd version that prompts the user for a license key on first start, if the key is valid the app starts and works until reinstalled or w/e. If the key is invalid the app just keeps prompting for a valid license.
Now I remembered reading somewhere that apple wouldn't allow apps that had no public function or something like that. Which this app wont have unless u have a valid license..
But since I do also provide a valid public version of the app, will this one get accepted? Or have they removed theese rules?
Any insight in the matter would be helpful!
Edit:
Forgot to mention that the reason im looking to use the license is because i have the same app for android and want the companies to be able to buy for both device types, not just apple devices.
Thanks
I believe you should use the B2B functionality in ITunes Connect: http://developer.apple.com/support/ios/volume-purchase-program.html
Also check: https://developer.apple.com/appstore/resources/volume/
I did something very similar to this some time ago, they seemed ok with it (then at least), they just asked for a license key in the complementary info (during the app submission) to go through all their usual validation tests.
Klassmating has an app in the app store that has no public functionality unless you are a student at a specific university. So it seems like you can have apps like that.
Without knowing exactly, I would assume Apple would reject such an app from the store (mainly because it would allow you to sell applications "behind their back" - i.e. sell licence keys and not using in-app purchase) :-)
However, there are two possible solutions to your problem that come to my mind:
Create and distribute gift codes (would be a problem if you had to give out too many of them).
Do an ad-hoc distribution of your app to the companies. Basically they would need your application bundle and an ad-hoc mobile provision file. Then they can simply install your application by dragging it to iTunes.
There are different official iPhone application distribution methods.
In which for your current requirement,I suppose you can use the Custom B2B Apps,where you can deliver apps directly to your business customers who have a Volume Purchase Program account.You can get more information from the link provided above.
cheers!
Yes, I too have had an app in the app store which works like this. You have to provide them with a key/licence to access the app functionality so they can test it fully.
I've had an app rejected for this very reason - required a username and password, not a licence key, but was free. They said in contravened the licence terms regarding in app purchases.
Mine allowed time limited free trials from within the app, but full functionality was restricted to purchases outside the app. Apple wanted their 30% cut of the subscription cost so it was no dice for us.
On the other hand, the app store review process is seemingly entirely random, so who knows.
We have an app on the app store that we need to remove. As such we have a new version to upload as a completely new app with a new app SKU and Id but we want to offer a free upgrade for those who have purchased the original version.
Is there a way to do this?
But if you're willing to give new App for free for everybody who's got an old one why do you create a new application and not just update old one? You can change anything you want about app except SKU# as I understand. Do you have anything tied to old SKU# or you have other reasons to create a new app?
I agree with the other posters. Apple does not have a mechanism to do this.
What you can do:
-make a black and white or very washed out icon for the old app
- change the app description to say that this is an old version / no longer supported / deprecated and to search for the new version.
- Make sure the new app title show something like NEW, 2.0 or some signifier to draw attention
I have not heard or seen anything about it. Only thing that comes to my mind is to give a promotion code. This of course opens up some other questions:
How to communicate that to your customers?
How to secure that it is not explored by users who have not bought the first app?
Don't have any good answers to that (time limited offer?) but maybe it could lead you to some new ideas.
Good luck!
Unfortunately there's no real way to do this. Apple intentionally keeps information about the users of your old app private.
Well, there's one way I can think of, but it requires some forethought (and I'm not certain it would be ok by Apple) and it would cost you a bit: When your old app runs it contacts a server of yours with the device's UDID, which you save on the server. Then you show an alert in the old app that tells existing users to contact you via email with their UDID (you could make it easy on the user by putting together the email in-app with the UDID in the subject or body). You then send a gift of the new app (via iTunes) to every user that emailed you that way.
You'd take a 30% hit (Apple's cut) but the rest of the gift price would end up back in your bank account. People who pirated the app would get the offer, too, and there's no way you could tell a pirating user from a valid user. But it would more-or-less work.