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.
Related
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.
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.
I'm reading over this previous thread because I was having a problem converting the device token to something I could send in a POST. That problem is solved, and my token is being sent properly to the server, which we store in a user's account record.
That is all I need to do, right? If we notify using that token, it will go to that user, and only that user? Or am I missing something really critical here?
When you say 'user' do you mean that your app can have different users log in and out?
To handle this, you can set up a table to map user_id to push_token and device_id. You should also add an enabled flag to this map - which means the user is currently logged in on that device.
Conceptually, while a device has only one push token, it may have many users, and a user may have many devices.
When a user signs into your app on a device you send user_id, push_token and device_id and set enabled=TRUE in your table. If this user/device combo never existed, add to your table.
When a user signs out of your app on a device you send user_id and device_id and set enabled=FALSE in your table.
When an event occurs that would trigger a push to user with user_id then you can look up what push_tokens are associated to that user_id and enabled=TRUE. Then you can simply push to those tokens.
#dmorrow is right. In addition, you need to make a .pem certificate with the same app id to make server push notifications work, check this ANSWER
I had a look into a few airline apps around there. This posed some questions, I couldn't find an answer to and would like to ask you as well. My questions won't have any code but aim more at the procedural level of such applications.
The first thing I wondered: When I use an airline app for booking a ticket for example, I guess that my smartphone will be registered in a database on a web service somewhere. Usually the companies will send you push notifications for further updates. This would imply to me that the device token by the APNS is saved in a database table "devices" for example, such they could find my device later on and send me notifications.
To make my question clearer I think about the flow of the user that way:
Open airline app for first time
User is being asked if he will allow push notifications
User confirms
APNS is providing a device token
The web service of the airline will save that device token in their database
If an update is necessary, use the device token in the DB and send
an update to the client
That would be the "easy" way to identify my users by their device token. But what would be the "standard" way of keeping track of registered devices?
To build upon my first question, I would like to expand this example a little bit. Most of the airline apps have the feature within the app to save a ticket as a passbook pass. I we take into account that the user has already accepted push notifications for the app he would be registered and listed on the web server with a device token for future reference.
As far as I know, passkit will send a web request to the airline server that they would have to parse in order to communicate with the passkit server. But in this request contained is a push token requested by the passbook app to receive updates.
Now I would think, that you have two different device tokens for the same user? I don't think you just can use the existing device token for pushing messages to the client in the database?
So how do you solve such an issue? If you have a user in your database registered and the airline provides a ticket as passbook pass, how can passbook interact with this data correctly afterwards?
I hope I could make my point in my questions :)
Thank you
what would be the "standard" way of keeping track of registered devices?
Whenever user starts your app you will get a callback
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken{
// associate device token with your username and send this to your server
}
Please note that device token keeps changing . From Apple docs
you cannot save a device token and use it for future reference. You need to update it for every run. Your server need to sync it's database of tokens.
Edit ..
Flow of user
To make my answer clearer I think about the flow of the user that way:
Open airline app
User is being asked if he will allow push notifications
User confirms
You provide device token and username to your server.
If your server now needs to send push notification it uses the most recent token and
send it to APN.