A) In android i can get the SIM details and can specifically choose the SIM for sending the OTP from that SIM. I have a sample screen which is possible to implement in Android.
I followed the link for ios How can I get details about the device data provider (like Verizon/AT&T) of an iphone programmatically?
https://developer.apple.com/forums/thread/9171 This link states we cant get the SIM Phone numbers from device because of Apple Privacy policy
How to implement the same screen in iOS? Any alternative idea or help is appreciated
B) How to get the Unique id for authentication?
In Android we can get (IMEI+SIM Serial number) can be used for authentication but in iOS all these are restricted due to privacy . Instead it is impossible to get UDID which is unique for every device. I know i can use vendor id for this:
UIDevice.current.identifierForVendor!.uuidString
But as the documentation says: 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.
Since the vendor id changes when the user uninstalls the Application .So is it any way around to get a unique id other than Vendor ID for authentication which doesn't change and is unique all time?
How to get SIM phone number?
As it stated in the question, its not available to get the phone number due to the security reasons. I suggest you to have a textfield and let user to enter the numbers, so you can send the sms to verify it
How to get the Unique id for authentication?
You have two options here based on your deployment target needs:
Apple has come up with the DeviceCheck framework in iOS 11. Your app should use the DeviceCheck APIs to generate an ephemeral token that identifies a device. Your associated server combines this token with an authentication key that you receive from Apple and uses the result to request access to the per-device bits.
Very intentionally by Apple, DeviceCheck tokens can not be used to identify the specific device.
But you can try playing to get unique identifier for the iOS device state
Create your own unique ID and save it in the keychain.
References
WWDC 2017 — Session 702 — iOS, macOS, tvOS, watchOS
Apple Documentation: — Access per-device, per-developer data that your associated server can use in its business logic.
Unique Identifier for the iOS Devices Article
Related
I want to get some unique identifier to allow specific devices to accessing my API, but looking on internet there's no way to get it and it's against Apple Policy,
But I need to get one of unique ID (e.g IMEI, UDID, ICCID, MEID, ETC)
looking on react-native-device-info, it just have getUniqueID() that can changed
This is IDFV on iOS so it will change if all apps from the current apps vendor have been previously uninstalled.
How can I get a unique ID ios devices?
FYI: My app won't be release into AppStore
There are major privacy concerns when getting a unique ID from a device. You have a few options.
First, you could just add some form of authentication or login system. This could be per device, per user, or even 1 login for the entire API. You could also limit the API to only respond to certain controlled IP addresses.
Second, you could add a flag and have a different version for production then in development. Limiting access that way.
Third, on first launch of your app you could request a new token from your server. The device would then store that token and the server would as well (to ensure no duplicates). Then just take that stored token and send it to the server for every request.
But on the device level there are privacy concerns in unique IDs for each device. You have to build your own system to handle it depending on your needs.
I would suggest that the IDFV was designed to suit your needs, while maintaining some level of privacy.
It is supposed to allow you (a vendor) to identify a return visit while not allowing you (a vendor) to share a user's identity with a third party in a relatable way for the third party to data-mine.
If users are routinely uninstalling and re-installing all of your apps I would look at solving the distribution issue you have there. I would assume (although haven't tested) that an update of an existing app would maintain the IDFV.
Is there any way to generate unique id for IOS devices?
I have a framework that helps to the apps to take login token from it, I am using identifierForVendor with no problems because all consumer apps published from same vendor, but I want to add another one from different publisher and adding that app to chain, identifierForVendor is no work anymore,
Also I can't use keychain since they are using different team id,
So can you please let me know if there is any other way to do this?
If I'm not mistaken Apple has revoked access to the real device identifier (UDID) and rather provides a pseudo-identifier to limit malicious usage thereof.
Refer to this previous answer https://stackoverflow.com/a/19402414/28305.
UDID is not available anymore so you can use
UIDevice.currentDevice().identifierForVendor?.UUIDString
more here
Or you can use DeviceCheck framework that is available from iOS 11
Just create a new key in Apple Developer account and generate a token with
DCDevice.current.generateToken(completionHandler:)
Note: You must use only real device to receive token.
You can find good tutorial here
Short answer: no because of data privacy concerns (at least in the official statements).
Apple blocked access to 'identifiers' such as UDIDs and hardware data such as MAC addresses and others. Even if there is currently such as field, as soon as it's exploited by a certain amount of people it will be removed or obfuscated soon.
The only thing that might work for a while is trying to get a browser fingerprint of the current device.
In my project i want to get the serial number and IMEI number using iOS SDK, What API's we can use to get in iOS7. I went through few links where they are using IO Frameworks, If we use those Apple will reject the App. How can we got forward.
Apple does not allow you the retrieve any device specific information like IMEI, UDID, Mac address, serial number, etc..
This has to do with the misuse of these identifier and the privacy of the user.
Apple forbids retrieving such information, as this is potentially harmful to the end users. Instead they provide you with identifierForVendor:
An alphanumeric string that uniquely identifies a device to the app’s vendor. (read-only)
refs: https://developer.apple.com/library/ios/documentation/uikit/reference/UIDevice_Class/Reference/UIDevice.html#//apple_ref/occ/instp/UIDevice/identifierForVendor
If you need to distinguish different apps from same vendor(on same device) you could use advertisingIdentifier, however docs clearly states it must be used only when it is in duty of ads(whether contributing install to an ad, or presenting ads in your app). Moreover I had application rejected because it was using this id, and was not declared in iTunesConnect.
An alphanumeric string unique to each device, used only for serving advertisements. (read-only)
refs: https://developer.apple.com/library/ios/documentation/AdSupport/Reference/ASIdentifierManager_Ref/ASIdentifierManager.html#//apple_ref/occ/instp/ASIdentifierManager/advertisingIdentifier
If you still decide to go for the latter one, don't forget do add AddSupport.framework to you project settings.
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.
I'm using QuickBlox for Apple Push Notification Services, while debugging some problems I had a look at their QuickBlox panel:Messages->Devices and I notice there are multiple devices for some users with different UDIDs. These users have only used one device and none of the device UDIDs seem to tie in with the actual iPhone UDIDs as seen on iTunes.
Does anyone know where these UDIDs come from, what they signify and why there are more than one per user?
Apps are not allowed to access the device UDID.
The API for accessing a unique identifier for each device will return a new random ID if you uninstall then reinstall the app.
This is specifically designed to make it impossible for an app to track users of the app.
You must ask the user to type in their email or something, if you want to tell one user from another.