Apps on Phone

Ever heard stories of never-ending promotions? In certain cases, a user can download an app and sign up for a business or service under a limited-time promotion, and when the offer runs out, the user deletes the app and / or logs in with new credentials to take advantage of the promotion again. This has been difficult challenge for developers and businesses alike, and in the past some of the solutions devised have prompted Apple to take legal action for violating privacy rights. One of the more recent cases occurred when Uber violated this policy and tried to hide it, motivating a confrontation by Apple and threats of removing the App from the App Store.

To combat these issues, Apple has developed and will be releasing an API called DeviceCheck. Starting in iOS 11 and tvOS 11, developers will have a reliable way to identify a device, even if a user deletes and redownloads an app, logs in using different credentials or performs a system reset.

The new functionality centers around generating an ephemeral token that will identify the device. The server associated with your application combines this token with an authentication key from Apple and uses the result to request access to the per-device bits and a timestamp of when they were last modified.

You can see the token generation below is straightforward and easy to use.

import DeviceCheck

let currentDevice = DCDevice.current

// check if DeviceCheck is supported by the current device
if currentDevice.isSupported {
 currentDevice.generateToken(completionHandler: { (data, error) in
 if let token = data{
 // send token to your server
 }else if let error = error{
 // handle error 
 }
 })
}

Generating the token can take place at any point in time in your user's flow through your app, although it would make sense in some areas more than others. If a company is launching a promotion or feature designed to be available to the user only once, querying these bits would allow the app to determine whether to present the feature or direct the user elsewhere. One thing to keep in mind is that upon generating the token, that token will need to be sent to the app's associated server, which will communicate with Apple's DeviceCheck API to receive and evaluate the meaning of the per-device bits.

Accessing the Per-Device Bits from the Server

Upon receiving the token on the device, we'll pass it to our server, which will assemble a payload and request to either query or update the per-device bits. From the server's perspective, we'll authenticate using provider authentication tokens just as recommended for connecting to APNS.

To query the bits, we'll assemble a payload like the one below, with the token from the device, the current timestamp, and a unique transaction identifier from the associated server.

{
 "device_token" : "wlkCDA2Hy/CfrMqVAShs1BAR/0sAiuRIUm5jQg0a..."
 "transaction_id" : "5b737ca6-a4c7-488e-b928-8452960c4be9",
 "timestamp" : 1487716472000 
}

The server will send that JSON in a post request to Apple's DeviceCheck API in a POST request, as modeled by the cURL command below. Keep in mind that the request header will contain the authentication tokens generated from the above link.

curl -i --verbose -H "Authorization: Bearer " \ -X POST --data-binary @ValidQueryRequest.json \ 
https://api.development.devicecheck.apple.com/v1/query_two_bits 

To update the per-device bits, we'll assemble a JSON payload identical to the last, with two additional fields for each bit.

{
 "device_token" : "wlkCDA2Hy/CfrMqVAShs1BAR/0sAiuRIUm5jQg0a..."
 "transaction_id" : "5b737ca6-a4c7-488e-b928-8452960c4be9",
 "timestamp" : 1487716472000,
 "bit0" : true,
 "bit1" : false 
}

The server will again send that payload to Apple in an authenticated POST request, as modeled by the cURL command below.

curl -i --verbose -H "Authorization: Bearer " \ -X POST --data-binary @ValidUpdateRequest.json \ https://api.development.devicecheck.apple.com/v1/update_two_bits 

The response for each device is tagged with two bits, along with a timestamp of when the bits were last modified. These bits can have any value that you as the developer want to assign to them, with any meaning you wish to specify. All of this information is stored by Apple. Full documentation on Accessing and Modifying the Per-Device Data from your server can be seen here.

The DeviceCheck implementation was designed to reassure users of their privacy. Developers gain access only to a non permanent token, rather than a device serial number or any other identifying data. When requesting the bits, they must authenticate in a manner identical to APNS, before receiving the per-device bits. From Apple's perspective, they receive and store only a timestamp and the two bits, with no significant meaning attached.

Use Cases

With this new feature, businesses have a more reliable way of preventing users from taking advantage of business promotions outside of their intended window. This could apply to apps that provide full functionality for a limited time before requiring the user to pay for the full version, or limited time promotions.

DeviceCheck also provides a way to flag fraudulent devices. If a business like a bank provides access to secure or sensitive data, they need to be wary of individuals attempting to use their app on a jailbroken phone. If you are successful in identifying the suspicious device, you can flag it with a series of bits that will prevent another account from attempting to access your services.

One thing developers will need to consider is how this will affect users switching phones - for example, a parent passing down an old iPhone to their child, or someone buying a used iPhone online. DeviceCheck does not handle situations like these right out of the gate, and it will be up to developers to provide some sort of work around for this situation. A simple possibility is allowing for some form of contact if this situation arises, so the device bits can be reset accordingly.

With DeviceCheck, Apple has created a solution that addresses a huge pain for their developers, while still keeping user privacy at the forefront of their design. It will be exciting to see this feature become a staple of the strategy businesses implement in their mobile experiences going forward.

Interested in finding out more about CapTech? Connect with us or visit our Career page to learn more about becoming a part of a team that is developing world-class mobile apps for some of the largest institutions in the world.

CapTech is a thought leader in the Mobile and Devices spaces, and has deployed over 300 mobile releases for Fortune 500 companies. Additionally, CapTech was identified by Forrester as one of top Business to Consumer (B2C) Mobile Services Providers in their 2016 Wave.