I have an iOS application in which i am using Facebook login, and after that phone verification is done which lets the user continue with the app. I ask for phone verification only once when user is being registered.
I wanted to ask if there is any way i can stop users from using the app on two devices? because application records user's footprints(location) and current location, if users use the app on two devices, locations updates will be made by both devices and there won't be any way to tell which location belongs to the user?
Can i use UUID or some other identifier?
You are not allowed to use the UUID. But you can generate a vendor id. But you will need to check if the user already uses on device on some kind of server and let the App ask if it is allowed to run.
But keep in mind that Apple doesn't like such things.
Well, I had to do a similar thing once. The app used to have in app purchase of number of device it can run for a single user. What I did was:
I used to take the UUID of the device while signing in to my app and send it to server.
In my server side database could store the UUID against a user. Whenever a user tries to sign in I used send the UUID with the sign in request.
If the UUID was present then I return success response otherwise I used to check the number of device allowed for this user. If adding this device exceeds the limit then I used to send failure response. Otherwise used to insert the UUID against that user and return a success response.
Suppose if a user deletes the app from a device and want to login from another device. Then display a popup like "Do you want to change the device?" If he/she say Yes then I used to update the UUID and allow him/her to use the app in this device. And every time the app starts (new launch or from background) I used to check the UUID against server's UUID.
You can design your own system but using device UUID gives some extra benefit. like you don't need to store the UUID anywhere and you can rely on its uniqueness.
Related
I'm making a card game for apple appstore that consists of 5 decks, 2 of them being free to play and 3 of them needed payment to be unlocked. I am not currently planning to do a login for my app. Would there be any way for me to track whether or not the user has paid and unlocked a particular deck?
If you want to detect if user bought something and you need to do it in different devices and even in the same device if user uninstall / install again, you'll need to implement a sign up strategy.
If you don't care about cross device, cross installations.. then you could generate an installation id that you're sure to be unique and send it to the server the first time the app is opened and use that to identify activity on that device/installation in the future.
You could use a uuid or any other identifier that you know that won't be used by anyone else.
So the flow would be:
App opened for first time
Generate installation id
Store it locally
Send installation id to server
Send it in the future to identify current installation
I have iOS application where new data arrives each hour on server.
When new data arrives, I would like to notify user if there is something of interest for him, based on his alert definitions.
I learned that only way to achieve that is APNS (Background tasks are not an option for regular precise waking up and fetching data so far I can tell after reading a lot).
I don't want to add registration/login requirements for user.
Is it possible and aligned with Apple standards to retrieve device token and send it to server each time with each alert request created by user, so that I can notify him/her by push notification once it is fulfilled?
So I can pair device token with alert request in database on server.
I don't want to implement apps feature and to go through effort of implementing APNS both client and server side only to get application rejected by Apple. Therefore, any reference to if it is possible or not, personal experience or working solution proposal is much appreciated.
Unfortunately, iOS uses a UUID as "device token" and it changes frequently and randomly (to protect privacy) so unless your application handles users one way or another, you won't be able to pair users with devices.
A solution might be that when your application installs for the first time and opens, you generate a unique id, it can be a UUID or some random string and save it to the keychain or if possible loses are okay, just save it to userDefaults. Keychain persists between app install and even is the user switches phones and you can use this uuid as "user per device"
I went through almost all the related SO questions, googled lot, but I can't get help.
There are lot many posts and SO answers which states to use [UIDevice identifierForVendor], but as this Id is not visible to user, I want different way to uniquely identify the device.
Basically I am developing Enterprise app which will not going to App Store(no need to worry about private APIs).
I am having server which has all users details including device id(don't know what to use as device id) already entered.
When device launches app, web service will be called and it needs to send device id to authenticate the device.
That's why I need device id which will be visible to user as well as programmer.
Any help is appreciated!!!
Update
'Visible to user' means user can see this unique id before installing app, so as he/she can send this number to admin to register it on server.
If this unique id is registered on server then and then only access will be given to application, otherwise app will not connect to server.
Use
NSString* uniqueIdentifier = [[[UIDevice currentDevice] identifierForVendor] UUIDString];
NSLog(#"UDID:: %#", uniqueIdentifier);
You've to put a small case to check the app is running on simulator or on device.
You can no longer get a unique ID of device. "identifierForVendor"
is the best you're going to get. Apple has systematically disabled
identifying a specific device.
Though, "identifierForVendor" value also changed after every new installation of application.
for more info visit.
You're also confusing me with this line "visible to user", could you please be more specific about it?
There's also one more way - Using icloud kit you can get a unique token of currently logged In icloud user account. This is unique per application on device.
It seems you want to track user using unique ID or UDID and Apple doesn't like this so before moving forward please visit.
Update:
If Apple is preventing tracking users using Unique Id, you shouldn't be using it then.
You simply want to validate user on your server. The best solution for you is iCloud token,
Fetch it and store it in User defaults or Keychain and use anywhere you want.
In this way you can also track single user on different devices if he/she is using multiple devices with same iCloud account.
You can try obtain UDID of device via service http://get.udid.io and then authenticate this device on your server.
But after this you will need to obtain the same UDID in your apps to pass it to server... It is possible to pass UDID to app via specific URL schema.
What do you think about this idea? I can share more details if you like it.
Assume a user has two iOS devices that support Passbook and that the user has both registered on the same iCloud account, and has Passbook toggled on for synching with iCloud.
If a user downloads an updateable pass (e.g. has webservice URL) through an app (via link) and installs the pass on device A, will device B go through the motions of registering the Passbook pass using the registration service/get serial number/get updated pass? E.g. from a different POV, must the server assume that the user can synch their updateable pass across different devices, and must it support multiple registrations of the same pass across different devices?
Background:
Our business wants to use passbook, and we naively thought we could use the device lib identifier to distinguish a device. Turns out that within a single update (manual or automatic update) the same pass (e.g. passTypeID+serial combo) can change device library identifer as part of their call to the registration REST service. So we thought we could at least handle this by always updating the most current registration entry with new details so we would at most have one registration.
This breaks if two or more devices can be synched and both automatically go through their own registration processes. Only one of the devices would have it's pass registered correctly, and it would be difficult to predict which device has a correctly registered pass. If this doesn't happen, we can hobble along with our current solution.
We have implemented a Passbook Plaform, and we support multiple devices for each Coupon, here is my example with my Mac, iPhone 5 and iPod.
I download the coupon from the Mac from the URL eg: https://passqlub.com:8443/passGen/Pass.seam?passId=71
Then I have the preview of the coupon and then I click to "Add to Passbook"
Like in 5-10 mins, the iCloud of both devices (iPhone and iPod) sync the coupon in both device. As soon as the coupon is downloaded to the Device, it get registered with to records (same serial, same PassType, but two deviceId and tokens)
If the platform want to send an update, it must get the serial and passtype and iterate over the devices and send the push notifications.
Hope it helps to clarify the sync of passbook on multiple devices.
You are correct in that it is not possible to use the device identifier to distinguish a user or a device. There are two reasons for this, firstly if a user has multiple devices and an iCloud account then the pass will automatically sync across all devices, and all devices will register with a unique device identifier.
Secondly, for security purposes, devices rotate their identifiers and tokens. When this occurs, the device re-registers with a new device identifier. Annoyingly, it does not deregister the old identifier. The only way you discover that a device identifier is stale is via the APNS feedback service. So if you are not regularly pushing updates to the pass, or you are not frequently checking the APNS feedback service, you will continue to accumulate device identifier records, when in reality the number of devices has not increased.
The only reliable way to uniquely target a pass is via a combination of serialNumber, authorizationToken and passTypeIdentifier. These three (or a combination of passTypeIdentifier and either of the other two), can act as a reliable primary key.
You might perhaps want to reconsider your schema and logic for targeting records. Apple's sample Passbook Server code contains a simple but effective SQLite schema for pass records and device records. In this example, device records are indexed by a concatenation of device identifier and serial number.
In any event, you should be considering your pass records independent to your device records. When you wish to update a pass, update the pass record, then identify the devices on which the pass is installed, retrieve their device tokens and send to the APNS server. When each device calls in to retrieve the update, you can always identify the pass record using a combination of serialNumber, authorizationToken and passTypeIdentifier.
Is there any way to get something unique about a user that will be found on all his devices?
I take that a device-token is unique per device itself, not user?
So is it possible to uniquely identify a user to record all his device-tokens on my server under him? Or is the only way to have the user sign in?
I would like the setup to be automatic and have the user just open the app without having to sign-up/in.
This is for APNS. I would like to send notifications to all the devices of a certain user.
You will have to store all users tokens on server and have the user sign in at least 1 time from each device, then You store each devices token for that user and log the user in automatically on subsequent app runs.