Hi, I submitted a FairPlay Streaming credentials approval request 5 days ago (through the "Request FairPlay Streaming credentials approval" form) and haven't received any response yet. Could someone from the Security Engineering team please check the status? Team ID: US7RGQX775 We're an online education platform and use a third-party DRM/video hosting provider (VdoCipher) that already operates a working, tested FairPlay Streaming KSM on our behalf — we just need the certificate to hand over to them. Thanks in advance!

I am using AVPlayer, but I am unable to retrieve PCM data from .m3u8 streams via the AVPlayerItemSampleBufferOutput API in iOS 27 beta. I have tried both the Objective-C and Swift APIs: the Objective-C delegate methods are not being called, and the Swift methods nextAvailableSampleBuffer() and nextSampleBuffer() are returning no data.

I implemented an AVContentKeySessionDelegate that after calling processContentKeyRequest succeeds in producing a contentKey in the callback func contentKeySession(_: AVContentKeySession, didProvide _contentKey: AVContentKey) of the AVContentKeyRecipient that manages the decoding of CMSampleBuffers. However, when I store the AVContentKey from the contentKeySession callback and try to attach it to the CMSampleBuffer with AVSampleBufferAttachContentKey, I get the error: Error Domain=AVFoundationErrorDomain Code=-11836 "Cannot Open" UserInfo={NSLocalizedFailureReason=This app is not authorized to play this file., NSLocalizedDescription=Cannot Open, NSUnderlyingError=0x28303a220 {Error Domain=NSOSStatusErrorDomain Code=-12161 "(null)"}} Does anyone have some insight on why this is happening and how to solve it?

Currently we are building a service based on Fairplay SDK version 26.0. Currently our solution is using version 4.5.4. When we run the below request to get version we get proper response curl http://xx.xx.xx.xx:8080/fps/v Response - V26.0 Our client applications call below two APIs https://GW_HOST:8080/fairplay_cert https://GW_HOST:8080/fairplay_license Within the cert API call, we are returning the fairplay public certificate. Currently we are trying to use the test certificate provided along with Fairplay SDK (test_fps_certificate_v26.bin) Then within the fairplay_license API call, we are trying to reach fairplay service based on Fairplay SDK v26 We are seeing some issues with below request(attaching the request json payload) curl -v -X POST -H "Content-Type: application/json" -d @SDKValidation_NewCert.json http://xx.xx.xx.xx:8080/fps SDKValidation_NewCert.json We are getting below response from SDK {"fairplay-streaming-response":{"create-ckc":[{"id":1,"status":-42605}]}} When we checked the apache error logs in the file "/etc/httpd/logs/error_log" we see below error [DEBUG] ❌ Assertion failure: invalidCertificateErr (-42605) [src/extension.swift:249] This is looks to be some error related to certificate. As mentioned earlier, client application is making a certificate call where we are returning the certificate set up . These certificates are already configured in the credentials path. Also note that the test samples provided with the SDK return valid license response. We had earlier raised a similar ticket mentioned below and we were asked not to use test certs. So we have raise CSR and used new certs for testing. https://developer.apple.com/forums/thread/836652?page=1

Due to hysterical raisins, our Apple Developer Account (2A...FW) has five FairPlay Streaming resources under https://developer.apple.com/account/resources/certificates/list Three of these are certificates (fairplay.cer) and two of them are provisioning packages (fps-bundle.zip). The three certificates all use 1024-bit RSA keys and have creation dates of: Oct 24 23:22:09 2016 (expired Oct 25 23:22:09 2018) 3J Mar 29 19:39:15 2018 (expired Mar 29 19:39:15 2020) 2N Feb 11 00:32:06 2026 (expires Feb 1 00:22:57 2027) LD (I've included the first two characters of the Apple resource ID to help keep these straight.) The key for the first two (same key for both) is lost to the mists of time. The third is a cert I created from a new key, so I have the key for it. (The developer portal will not let us create any more 1024-bit FairPlay certs.) The two FPS bundles each contain an fps_certificate.bin which itself contains a 1024-bit cert and a 2048-bit cert. Looking at this file in each bundle, the bundles include the same 1024-bit cert that I created on Feb 11, but two different 2048-bit certs with creation dates of: Feb 11 00:32:06 2026 (expires Feb 11 00:32:05 2028) YP Feb 11 00:56:22 2026 (expires Feb 11 00:56:21 2028) 9N Both 2048-bit certs use the same key (which I have). Finally, we use a third-party as our streaming provider. With them we shared the first FPS bundle (YP). So, this is a big mess. And I'm unable to delete any of these entries from our developer account. Questions: Does the expiration date on these certs matter or is it ignored for streaming purposes? How do we delete FP certs/bundles we no longer need/use/are expired? With respect to using third-party vendors for streaming (with whom we've shared an FPS bundle): Is it okay to re-use the same FPS bundle if we change vendors? Should we ask Apple to delete an FPS bundle once we stop using a vendor?

Hello, I cannot find reference to any possible limitation on ShazamKit. How many calls can I make per minute? Is there any limit at all? Thanks

Hello, I am developing a custom player SDK based on AVPlayer that supports HLS and LL-HLS playback on iOS. I have a question about AVPlayer's variant selection behavior with respect to the VIDEO-RANGE attribute. Setup Our multivariant playlist contains a ladder where the dynamic range differs per rung. Simplified example: #EXT-X-STREAM-INF:BANDWIDTH=1200000,RESOLUTION=854x480,CODECS="hvc1.2.4.L93.B0",VIDEO-RANGE=SDR,FRAME-RATE=30.000 sdr_480p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=3500000,RESOLUTION=1280x720,CODECS="dvh1.05.03",VIDEO-RANGE=PQ,FRAME-RATE=30.000 hdr_720p.m3u8 The lower rung(s) are SDR only, and HDR (Dolby Vision, VIDEO-RANGE=PQ) variants exist only at the higher rungs. There is no PQ variant at the low end and no SDR variant at the high end. Observed behavior On HDR-capable devices (AVPlayer.eligibleForHDRPlayback == true), playback starts on the SDR 480p variant and then never switches up to the HDR 720p variant, even when network throughput is clearly sufficient (verified via AVPlayerItemAccessLog.observedBitrate and variant switch events). ABR up-switching works as expected when all rungs share the same VIDEO-RANGE. Questions Is it expected behavior that AVPlayer confines ABR switching to variants of a single VIDEO-RANGE for the duration of an AVPlayerItem, i.e., it will not cross SDR <-> PQ/HLG boundaries at runtime? If so, is the VIDEO-RANGE group selected once at playback start based on display capability and the initially chosen variant, with all other ranges excluded from the eligible set? The HLS Authoring Specification for Apple devices requires parallel SDR ladders for backward compatibility (sections 1.24 / 6.16), which implies each VIDEO-RANGE should form a complete, self-contained ladder. Is a mixed-range ladder like the one above considered a non-conformant authoring pattern, and is completing the PQ ladder down to the lowest rungs the correct fix? Are there any public APIs that influence video-range selection for streaming playback (beyond eligibleForHDRPlayback, which is read-only)? I understand the ABR switching logic itself is not documented, but confirmation of the VIDEO-RANGE grouping behavior would help us author our ladders correctly. Thank you.

Environment: iOS 18 / iOS 26, AVPlayer + AVPlayerItem, live low-latency HLS (LL-HLS). Subtitle renditions are regular (non-forced) WebVTT: AUTOSELECT=YES, FORCED=NO. System captioning (Closed Captions + SDH) is OFF (default). Direct CDN, no P2P. Master playlist (subtitle part): #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="Korean (AI)",AUTOSELECT=YES,FORCED=NO,LANGUAGE="kor",URI="..." #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="English (AI)",AUTOSELECT=YES,FORCED=NO,LANGUAGE="eng",URI="..." #EXT-X-STREAM-INF:...,SUBTITLES="subs" Problem When the user picks a subtitle language we call playerItem.select(option, in: legibleGroup) with an option that is a genuine member of the item's current legible group. Right after the call, item.currentMediaSelection.selectedMediaOption(in:) returns the requested option. But within ~2 seconds, on a subset of real-user sessions, the selection spontaneously reverts with no further app interaction: most often to Off (no legible output is delivered afterwards), or it stays stuck on the previously selected language (a subsequent select to another language, or to Off, is silently ignored). It is intermittent and only appears under real conditions (frequent live playlist reloads / reconnects); it does not reproduce in a short, clean session. What we verified The option passed to select(_:in:) is a real member of the current group (re-resolved from item.asset); the call returns without error and reads back correctly immediately after. appliesMediaSelectionCriteriaAutomatically is the default true. Per the AV Foundation Release Notes ("Advice about subtitles"), automatic selection excludes options that are not AVMediaCharacteristicContainsOnlyForcedSubtitles. So on each live reload the automatic re-selection resolves non-forced subtitles to Off, appearing to override the manual select(_:in:). Reading the selected option against a freshly obtained group instance returns the same value as against the original instance — so this is a real state change, not a mismatched-group read. Questions On live HLS reloads with appliesMediaSelectionCriteriaAutomatically == true, is manual select(_:in:) for .legible expected to be overridden by automatic media selection? If so, is setMediaSelectionCriteria(_:forMediaCharacteristic:) the intended way to persist a user's choice? setMediaSelectionCriteria for subtitles is itself reported as unreliable (sometimes no subtitles) — see thread 108403. What is the recommended, deterministic way to keep a user-selected non-forced subtitle displayed across live playlist reloads, including turning subtitles Off? Is this the same underlying behavior as FB13344652 ("Auto (Recommended) doesn't display subtitles despite language match / DEFAULT=YES")? Related: https://developer.apple.com/forums/thread/722752 (FB13344652) , https://developer.apple.com/forums/thread/108403

We keep live playback at a consistent distance from the live edge using small playback rate adjustments, with a target range based on recommendedTimeOffsetFromLive. Since the live edge is not exposed by AVPlayer, we currently fall back to seekableTimeRanges.end as our best approximation. What should be treated as the live edge, and how should the current live latency be measured? Is rate adjustment the appropriate way to hold a target latency? While playing above 1.0x, the playhead can reach the seekable end, at which point AVPlayerItemDidPlayToEndTime fires and halts the live stream. How can we guard against ? Does any of this differ between regular HLS and LL-HLS? A clear statement of the intended contract here would resolve a lot of uncertainty. Thanks in advance.

Currently we are building a service based on Fairplay SDK version 26.0. Currently our solution is using version 4.5.4. When we run the below request to get version we get proper response curl http://xx.xx.xx.xx:8080/fps/v Response - V26.0 Our client applications call below two APIs https://GW_HOST:8080/fairplay_cert https://GW_HOST:8080/fairplay_license Within the cert API call, we are returning the fairplay public certificate. Currently we are trying to use the test certificate provided along with Fairplay SDK (test_fps_certificate_v26.bin) Then within the fairplay_license API call, we are trying to reach fairplay service based on Fairplay SDK v26 We are seeing some issues with below request(attaching the request json payload) curl -v -X POST \ -H "Content-Type: application/json" \ -d @SDKValidation.json \ http://xx.xx.xx.xx:8080/fps SDKValidation.json We are getting below response from SDK {"fairplay-streaming-response":{"create-ckc":[{"id":1,"status":-42605}]}} When we checked the apache error logs in the file "/etc/httpd/logs/error_log" we see below error [DEBUG] ❌ Assertion failure: invalidCertificateErr (-42605) [src/extension.swift:249] This is looks to be some error related to certificate. As mentioned earlier, client application is making a certificate call where we are returning the test certificates provided along with the SDK (test_fps_certificate_v26.bin). These certificates are already configured in the credentials path. Also note that the test samples provided with the SDK return valid license response.

Hello Apple team, This issue is reproducible with AirPlay mirroring from an iPhone. When a video is played full screen in the Photos app and the user then switches to another app or enters the multitasking flow, the mirrored video output freezes completely on the receiving device. The AirPlay session appears to remain connected, but the receiver keeps displaying the last video frame and the mirrored stream does not recover automatically. Stopping and restarting AirPlay mirroring is required to recover. Environment: Sender: iPhone, iOS [26.5] Receiver: AirPlay receiver device/app The same behavior can also be reproduced when mirroring from iPhone to a Mac Source app: Photos Content: local video played in full screen Steps to reproduce: Start AirPlay mirroring from an iPhone to an AirPlay receiver. Open the Photos app on the iPhone. Play a local video in full screen. While the video is playing, switch to another app or enter the multitasking flow. Observe the mirrored output on the receiver side. Video Recording: https://drive.google.com/file/d/1X9Mj9EB4IYZXjDdCaqrXfgg1PpbhZoUN/view?usp=sharing Expected behavior: AirPlay mirroring should continue smoothly after the app switch, or recover automatically when the source video/app state changes. Actual behavior: The mirrored video freezes completely. The AirPlay connection remains active, but no new video frames are rendered on the receiver side. The stream does not recover until AirPlay mirroring is stopped and restarted. Could Apple confirm whether this is a known AirPlay mirroring issue? Is there any recommended workaround, receiver-side handling, or additional diagnostic information that should be collected for this case?

Following the documented ImmersiveMediaSupport flow (NWBrowser → connectReceiver, NWListener → receiver.start(connection:)) with ImmersiveMediaPreviewMessagingProtocol.definition as the framer. Bonjour discovery works, but connectReceiver throws ImmersiveMediaRemotePreviewSession received invalid parameters (sometimes GKVoiceChatServiceErrorDomain 32032). The doc example leaves TLS as /* setup TLS security options */. What exact TLS configuration does the session require — a self-signed SecIdentity, TLS-PSK, a specific cipher/version? And should ImmersiveMediaRemotePreviewSender(networkParameters:) be nil (framework default) while only the NWBrowser/NWListener carry the TLS+framer params? A minimal working setupNWParameters() would unblock me. Thanks!

When we try to use AVPictureInPictureController with a AVSampleBufferDisplayLayer on tvOS 15 through tvOS 26 isPictureInPicturePossible never becomes true. The code works great on iOS, but it has never worked on tvOS. You can check this out for a repro: https://github.com/jazzychad/PiPBugDemo Feedbacks: FB9751461, FB14158567, FB14037110 DTS Case: 7999337

I want to know more about the latest technology from Apple and interesting hardware for me to know about.

Is FairPlay multi key encryption supposed to work in Safari 26 on macOS? It stopped working for us some time last year. The very same content works on iOS in AVPlayer and single key encryption works fine. On macOS, the multi key content sometimes plays, sometimes not. It is as if there was some race condition on how fast the KSM responds with content keys. Very often, I can see just one KSM request in network console (instead of multiple for each video profile and audio) and the playback fails with Video error: code=3 msg=Media failed to decode. We've filed a Code Level Support ticket (19025185) and a bug report (FB22353469), but haven't really heard back. Just that engineering is actively investigating this issue, and was able to reproduce it.

Following up on: https://feedbackassistant.apple.com/feedback/22501602 We have a downloaded .movpkg (via AVAggregateAssetDownloadTask) where we need to update #EXT-X-DATERANGE tag URLs in the manifest Apple Developer Technical Support (FB15965814) confirmed "it is perfectly fine to update the m3u8 playlist inside the movpkg if that works well for you." Can you confirm this is safe to rely on long-term and won't break in future OS updates? Is there anything we should watch out for (e.g., movpkg integrity checks, asset download storage manager interactions)?

If we are using an AVAssetResourceLoaderDelegate, and performing our own playlist requests using a URLSession, what are some best practices for responding to the resource loading requests with errors? In other words, how best to populate the NSError domain, code, and userInfo values when calling finishLoadingWithError? SImilarly, are there any things to look out for when the URLSession has caching enabled, and we receive HTTP 304s for live playlists? The URLSession appears to transparently handle the 304, and return a 200 with the cached data in the URLSession callbacks. But could there be edge cases where the URLSession’s cache is becoming invalid just as we get a 304?

To reduce latency in our live HLS service, we are experimenting with short segment durations (1–2 seconds). We have noticed that ABR switching occurs more frequently than expected. Looking at the console logs, variants appear to enter and leave what is referred to as a "penalty box" under conditions such as -12889 (a segment returning 0 bytes after 1.0 × target_duration) and -12888 (a playlist remaining unchanged beyond 1.5 × target_duration). Are there recommended practices to reduce this excessive switching? Specifically: Is there an API to control this penalty box behavior? Would preparing an LL-HLS stream with 1-second parts settle this down? Alternatively, would 4-second segments with a slightly smaller configuredTimeOffsetFromLive help stabilize this?

Hi, We currently deliver HDR10+ content within a composite HLS stream where Dolby Vision is signaled as a supplemental codec alongside HDR10+. Our testing on Apple TV 4K (3rd generation) indicates that playback succeeds, but we have not found a reliable way to determine whether playback is occurring in Dolby Vision or HDR10+ mode when connected to a display that supports both formats. We have also verified that the same stream plays correctly on displays that support HDR10+ but do not support Dolby Vision. However, on displays that support both HDR10+ and Dolby Vision, we are unable to determine which dynamic range format AVPlayer ultimately selects. Is there a recommended Apple API or mechanism to determine whether AVPlayer is rendering content as HDR10+, Dolby Vision, or another HDR format at runtime? For reference, below is an example variant from our master playlist: #EXT-X-STREAM-INF:BANDWIDTH=2851276,AVERAGE-BANDWIDTH=2030750,CODECS="hvc1.2.4.L90.90,mp4a.40.2",SUPPLEMENTAL-CODECS="dvh1.08.01/dv1p,hvc1.2.4.L90.90/cdm4",RESOLUTION=854x480,FRAME-RATE=24,VIDEO-RANGE=PQ,HDCP-LEVEL=TYPE-1,CHARACTERISTICS="com.dss.cbcs.hdr.hd",AUDIO="aac-128k",SUBTITLES="sub-main" Specifically, we would like to understand: How AVPlayer chooses between Dolby Vision and HDR10+ when both are available in the same variant. Whether there is a supported way to determine the selected HDR format during playback. Whether any other APIs expose this information. Any guidance would be greatly appreciated. Thank you.

Is there a way to attach a MusicUnderstandingSession to a MusicKit stream or audiofile?