在蘋果平台上的 AVFoundation Framework 中，有個 API 叫做 AVContentKeySession — 這個 API 的用途晚點再講，反正大多數人用不到—我想講的是他的 delegate－AVContentKeySessionDelegate，你在 macOS 上面實作這個 delegate 的時候會遇到一個鬼打牆的狀況：
- AVContentKeySessionDelegate 理論上是一個 macOS 10.12.4 以上的 API
- 然後裡頭有一個 delegate method 用到了一個 macOS 10.15 以上才有的 class AVPersistableContentKeyRequest
- 然後用到 AVPersistableContentKeyRequest 的這個 delegate method，它的 signature，跟另外一個 AVContentKeySessionDelegate 必須要實作的 delegate method 的 signature，在 Swift 裡頭一模一樣。
AVContentKeySession 是拿來更新 FairPlay 的 Content Key 用的。蘋果在大概十年前在 iOS 上推出了 HLS，十年下來，有一大堆的影音服務用 HLS 提供影片串流以及直播，而在 2015 年的時候公開 FairPlay 版權保護機制，加密保護 HLS 格式裡頭的資料。
但，一開始抓取加密用的 Key 的流程跟播放流程綁死，只能在播放的時候更新 Key，所以很有可能在某場直播開始的時候所有人都去抓取加密用的 Key 導致很高的瞬間流量，所以在 2017 年蘋果推出 AVContentKeySession，讓你可以單獨要求某把 Key，所以你可以在直播開始之前就先讓大家把 Key 先抓好。由於我們也可以把一份 HLS 串流下載到裝置上離線播放，離線檔案也需要加密，於是，AVContentKeySession 就會處理兩種 Key：線上播放用的 Key （透過 AVContentKeyRequest），與播放離線影音用的 Key—就是我們前面提到的 AVPersistableContentKeyRequest。
這幾個 API 在 iOS 11 （2017 年）就有，但 macOS 的 API 大概落後了兩年，AVPersistableContentKeyRequest 到了 10.15 （2019 年）才有。
AVContentKeySession 會處理兩種 Key，在處理線上播放的 Key 時，會向 delegate 呼叫 -contentKeySession:didProvideContentKeyRequest:，在處理離線播放的時候，則會呼叫 -contentKeySession:didProvidePersistableContentKeyRequest:。這兩個 method，在 Swift 裡頭，都叫做 contentKeySession(_:didProvide:)。
好的。我們想要有個 Class，這個 Class 實作 AVContentKeySessionDelegate，它可以處理這兩種不同的 Key，所以想像中，我們這個 Class 應該要是 10.12.4 以上可以呼叫，而因為 -contentKeySession:didProvidePersistableContentKeyRequest: 用到了 AVPersistableContentKeyRequest，所以就必須是 10.15 以上…。結果我們就遇到了編譯錯誤：
因為有兩個 method 在 Swift 裡頭是同名的，所以，當我們把 -contentKeySession:didProvidePersistableContentKeyRequest: 標成了 10.15 以上，Swift 編譯器就把我們當成我們連 -contentKeySession:didProvideContentKeyRequest: 都沒有實作。
用 @objc 語法告訴它在 Objective-C 裡頭應該是哪個 method 也沒用。
怎樣才能成功通過編譯呢？你需要把整個 Class 都變成是 10.15 以上才能使用：
目前全球 mac 用戶中，大概有 37% 升到了 10.15，所以，如果你只用 10.15 以上的 API 的話，那大概有六成以上的 mac 用戶沒辦法用你寫的東西了。
