At first glance, Apple Push Notification services seem pretty darn complicated. Luckily, we’re all about demystifying technical things here at Bushel. So let’s take a moment to look at what happens when an Apple Push Notification transaction occurs. In this example, we’re going to look at using our tool to send some command to a device, like enforce a passcode policy. Now, you send this passcode enforcement in what is known as a profile. That’s just a way of saying some code that tells the device to enforce a passcode policy. That transaction of sending the profile might seem like it’s as simple as just send the code from the server to the device, but the server doesn’t communicate to the device, the device communicates to our servers.
Under the Hood
So here’s what’s really happening behind the scenes:
▪ You create a policy ▪ The policy gets saved into a profile ▪ The fact that there’s a profile change gets communicated from us (the Provider) to Apple’s Push Notification Servers, or APNS. ▪ When the device checks into APNS (over port 5223), it gets what Apple calls a token. The token is an anonymized bit of data that doesn’t actually know what is being sent in the profile. This is key as it means that Apple themselves never know what policies you’re sending you to your devices. ▪ Once the token is received, the device checks in with us, the Provider. ▪ We send the command to the device. This could be a profile change, sending an app to a device, a lock command, unlock command or even a device wipe. ▪ Once the device gets the command we sent, the device processes the command, letting us know the result of the command. ￼ OK, so it’s a little complicated. But not technically, just logistically. Luckily, you hit a button and we handle all the other stuff. But if you’re ever curious about what we’re doing under that hood, now ya’ know!