One of our iOS teams at iCapps is currently working on a project where we need to be able to play HLS video streams that are protected. It took a while to find out how everything works from a technical perspective. So once we found a working solution, I decided to share this knowledge in a blogpost.


Now just for the record: what is HLS? HLS stands for HTTP Live Streaming. It's a protocol that allows you to send on-demand or live video or audio streams to your devices. This technology is developed by Apple, and is optimised to deliver the best possible quality. It adapts seamlessly to the network conditions, so when the network is unreliable, HLS will adapt without causing user-visible playback stalling.

Why would you want to use HLS and not MPEG-DASH or others? Well, when you want to stream to Apple systems, then I recommend using it. This is especially true in the case of Apple TV. HLS is currently the only streaming protocol that can be used by developers.


Digital Rights Management (DRM in short) allows a content provider to securely manage multimedia content. Its main goal is to protect by encrypting the video fragment so it cannot be copied without authorization. The DRM technology used by and developed by Apple is FairPlay.

FairPlay allows you to securely send the streaming content to the device. It securely delivers keys to Apple devices that make it possible to decrypt the encrypted content.

A big advantage of using HSL with FairPlay is that you can even stream the encrypted content over AirPlay. So no more black screens on your TV!

How does it work?

Here is a small overview of what happens when you want to play protected content on your device,

  1. The application will send a video or audio stream to the native player.
  2. The native player will read the playlist from the manifest and will come back to the app when the content is protected.
  3. Your app will request an encrypted Server Playback Context (SPC) message from the OS. This will be generated by combining the correct FairPlay application certificate and a content identifier.
  4. The encrypted SPC message is uploaded to the Key Server Module (KSM), also known as your content provider's DRM server.
  5. If the SPC is correct, the KSM will return an encrypted Content Key Context (CKC) message.
  6. This CKC is sent back to the native player and now the player is capable of decrypting the stream. 

Here is a small graph of what happens in a nutshell. Credits go to Apple.

I'm not a big fan of all the abbreviations used in the above explanation. But it helped me to get through the decryption process.


Explaining what needs to happen was the easy part. Now I'll go through the above steps from a technical perspective.

  1. Send an encrypted audio or video stream to AVPlayer.