When using rounding methods (rounded(), rounded(toPlaces:), round(_: CGFloat)) on CGFloats with the simulator, the returned value is not rounded at all or sometimes makes no sense at all. (lldb) po (398.0 / 165.0).rounded()e-321 The expression may even crash when called from an attached debugger (the following expression returns 2.4121212... when no debugger attached): (lldb) po (availableWidth / (cellRatio * (tileType.sectionHeight - 50))).rounded() error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0x7c). The process has been returned to the state before expression evaluation. The same operations are OK on a real device or in a playground on a Mac. It's also OK when converting the CGFloat to a Float and calling roundf() as follows: (lldb) po CGFloat(roundf(Float(availableWidth / (cellRatio * (tileType.sectionHeight - 50)))))0 Finally here are the results when passing various rounding rules to the rounded() method: .toNearestOrAwayFromZero: crash in debugger .toNearestOrEven: 2.412121212121212 (unchanged value) .up: inf .down: 2.412121212121212 (unchanged value) .towardZero: 2.412121212121212 (unchanged value) .awayFromZero: inf Is there something wrong with computing rounded values of CGFloats on a simulator?

The Context I'm using the HTML video element to play HLS+Fairplay streams (VOD and live) in Safari. My application is a Netflix-like. You can watch a video, stop, and watch another one. Concretly, the <video> tag is created upon each play and destroyed when the player exits. The Problem Sometimes, after exiting the player, launching a new video causes a MEDIA_ERR_DECODE error without anymore explanation. I can trace in my code that the Fairplay certificate and the CKC have been correctly retrieved and that the media session has been created and updated (with the CKC). In fact, when I log everything, I see the exact same logs as when it works. Except the final MEDIA_ERR_DECODE error. When I get this error, if I immediately retry to play, the same error happens, but if I wait about 5~10 seconds, it successfully plays. It's like some resource is waiting to be garbage-collected. What I tried I tried playing non-DRMed videos and it works perfectly: I could play, stop, play, etc. without any issue. So my guess is something is happening at the EME level. I've browsed the whole Internet (twice) and couldn't come up with a clear explanation. Most of the hints I found couldn't explain my issue (e.g. bad DRM-encryption, but how could it work the first time?) or solve it (e.g. videoElement.src = ""). I'm throwing a bottle into the sea, here... Thanks for your help!

Our iOS and AppleTV apps regularly send requests to various endpoints during their lifetime. Requests are sent using URLSession dataTask. Problem: On AppleTV, when the app enters foreground again, it tries to send a request to one of these servers but the request often immediately fails with the following error: Task <1F891A2A-727D-4AE5-A7D1-85099FFBCE5B>.<297> finished with error [-1005] Error Domain=NSURLErrorDomain Code=-1005 "La connexion réseau a été perdue." UserInfo={_kCFStreamErrorCodeKey=53, NSUnderlyingError=0x282a262b0 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={_kCFStreamErrorCodeKey=53, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <1F891A2A-727D-4AE5-A7D1-85099FFBCE5B>.<297>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <1F891A2A-727D-4AE5-A7D1-85099FFBCE5B>.<297>" ), NSLocalizedDescription=La connexion réseau a été perdue., NSErrorFailingURLStringKey=https://entitlementvitis.gemtv.cloud/api/entitlement/get, NSErrorFailingURLKey=https://entitlementvitis.gemtv.cloud/api/entitlement/get, _kCFStreamErrorDomainKey=1}  The error occurs even if the app only remains several seconds in background. It looks like the system closes the socket when the app enters background and tries to reuse one when it enters foreground. The HTTP protocol can either be HTTP/1.1 or HTTP2 (depending on the endpoint the app sends the request to). But for endpoints using HTTP/1.1, adding the header "Connection: close" to the request sent before entering background seems to prevent the issue from occurring. However this is not a fix, especially it does not solve the problem for HTTP2. Finally I've not been able to reproduce the issue while profiling the app with Network Instrument. I've filed a feedback regarding this issue: https://feedbackassistant.apple.com/feedback/11990344 Related issue: This issue seems similar to another one we've always experienced: during the app lifetime (again iOS and tvOS), some requests reach a seemingly random timeout, sometime far less than the URLRequest timeoutInterval we usually set at 30s. It looks like the system sends a request through a socket it thinks is still open, but finds out later on that the socket was actually closed on the other side. When these error occurs, the system may log the following: [connection] nw_read_request_report [C1] Receive failed with error "Socket is not connected" [quic] quic_conn_send_frames_for_key_state_block_invoke [C1.1.1.1:2] [-056706ee9dedb1d86333a78c850bed80e55d70ee] unable to request outbound data [] nw_endpoint_flow_fillout_data_transfer_snapshot copy_info() returned NULL nw_connection_copy_connected_local_endpoint_block_invoke [C13] Connection has no connected path Your help would be much appreciated (Eskimo)

While setting up our premium video-on-demand workflow in AWS, using AWS MediaConvert and MediaPackager and licence delivery from drmToday we encountered an issue with HLS+FairPlay playback (only) in Safari on macOS. The issue is that sometimes (more than 50% on the same video) the videoplayer initialization fails (with simple event of type=”error” in onerror callback). We are using Shaka player in our web application, so we first assumed that this (random) issue could be due to Shaka. However, we also tested with direct playback via the player and we observed the same issue, with same frequency. Since we have some content for which this problem does not occur and other content when the problem occurs very frequently, we tried to understand what could explain this difference. We noticed that for assets where the problem never occurs the order of the video submanifest was increasing, whereas for assets where the problem occurs frequently the order is decreasing. To isolate the issue we created a standalone page for a 2-minute asset and we are able to demonstrate that on this asset, when the bitrates are in decreasing order the playback with Safari on macOS fails more than 50% of the time. Test page using tag: KO: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-video.html OK: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-video.html?ok=1 Test page using Shaka: KO: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-shaka.html OK: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-shaka.html?ok=1 Notes: the issue is only reproducible with Safari on macOS (not with Safari on iOS) same HLS content + FairPlay plays OK 100% on tvOS the issue is only reproducible for HLS content with FairPlay (OK if no DRM)

We develop a video playback app on Apple TV which has the two following features: Its content browsing screen has installed a gesture recognizer for presses on the PlayPause Siri remote button in order to directly launch a playback. The gesture recognizer is attached to the content browsing UIViewController view. It presents its own custom playback UI with an AVPlayerLayer for the video and supports MPNowPlayingSession in order to publish current playback information and respond to remote commands. It also supports switching between fullscreen and Picture in Picture playback. Both features work fine, ie. the playback is launched when pressing the PlayPause Siri remote button and, during playback, the playback info are properly advertised on other devices and remote commands are also triggered as expected. However, when pressing the PlayPause Siri remote button while the video is playing in PiP, the "pause" remote command is sometimes triggered instead of the .playPause gesture recognizer. The issue may not occur the first time but for subsequent PlayPause presses. Navigating a bit in the app UI seems to help preventing the issue to occur. Finally, the issue only occurs if the video is playing. If the video is paused, the PlayPause Siri remote button gesture is always recognized instead of the remote command. Please note that, before using MPNowPlayingSession (and the corresponding MPRemoteCommandCenter), the app was using the default MPRemoteCommandCenter to support remote commands and the issue did not occur. We don't reproduce this issue with the Apple TV app so there's probably something we are not doing right. Has someone any clue?

Context We develop an iOS/Apple TV app that allows to play HLS+FP Live streams (custom playback UI), some of which use the same FairPlay content key id. All FairPlay content keys are requested to the same content key server. Implementation Despite Apple documentation warning to not reuse AVContentKeySessions, we use only one AVContentKeySession for all channels which allows the system to reuse the content key when a content key id is met again. As seen in another thread, people seems to think this is OK. Issue When reusing the AVContentKeySession and the user quickly tunes channels multiple times (up to 2 or 3 times per second using gestures), an inconsistency may occur where the content key request for a previous streams is asked to the delegate after a new stream is already being prepared and its AVURLAsset already assigned as the content key session AVContentKeyRecipient. Note that the previous content key recipient is removed before the new one is added. We also have been reported for crashes (though I haven't experienced it myself) when performing multiple channels tunings which makes us think that the AVContentKeySession should definitely not been reused. Note: On the other hand if a new AVContentKeySession is used for each stream, the system systematically requests a content key even if previous streams have used the same content key id. In this case, neither the crash nor the inconsistency issue are observed but it dramatically increases the number of calls to the content key server. Questions Should AVContentKeySessions definitely not be reused? Otherwise, how to handle the inconsistency issue described above?

Our Apple TV provides UIImages with renderingMode forced to .alwaysTemplate (the images are also configured with "Render As" to "Template image" in the Asset catalog) to UIActions as UIMenuElement when building a UICollectionView UIContextMenuConfiguration. Problem: these images are not displayed with vibrancy effect by the system. The issue does not occur with system images (SVG from SF Catalog). Here is a screenshot showing the issue with custom images ("Trailer" and "Remove from favourites"): I don't know the underlying implementation of the context menu items image but UIImageView already implements the tintColorDidChange() method and the vibrancy should work if the UIImage is rendered as template. According to my tests, the vibrancy is correctly applied when using Symbols sets instead of Images sets but I understand that custom images rendered as template should support it as-well, shouldn't they?

The app registers a periodic time observer to the AVPlayer when the playback starts and it works fine. When switching to AirPlay during playback, the periodic time observation continues working as expected. However, when switching back to local playback, the periodic time observer does not fire anymore until a seek is performed. The app removes the periodic time observer only when the playback stops. I can see that when switching back to local playback, the timeControlStatus successively changes to .waitingToPlayAtSpecifiedRate (reason: .evaluatingBufferingRate) then to .waitingToPlayAtSpecifiedRate (reason: .toMinimizeStalls) and finally to .playing But the time observation does not work anymore. Also, the issue is systematic with Live and VOD streams providing a program date (with HLS property #EXT-X-PROGRAM-DATE-TIME), with or without any DRM, and is never reproduced with other VOD streams.

One of our customers subscribed to a monthly plan on August 16 but the server-to-server notification seems to have been sent on August 18. What could be the reasons for such a delay between the purchase and the server-to-server notification which are usually sent right after the purchase? The receipt sent along with the notification seems to confirm that the receipt has only been created 2 days after the purchase. Here is an extract: { "environment": "Production", "receipt": { "receipt_type": "Production", "bundle_id": "fr.gaumontvideo.gaumontclassique", "application_version": "613", "receipt_creation_date": "2025-08-18 13:00:16 Etc/GMT", "receipt_creation_date_ms": "1755522016000", "receipt_creation_date_pst": "2025-08-18 06:00:16 America/Los_Angeles", "request_date": "2025-08-25 13:08:27 Etc/GMT", "request_date_ms": "1756127307346", "request_date_pst": "2025-08-25 06:08:27 America/Los_Angeles", "original_purchase_date": "2022-05-11 06:14:37 Etc/GMT", "original_purchase_date_ms": "1652249677000", "original_purchase_date_pst": "2022-05-10 23:14:37 America/Los_Angeles", "original_application_version": "265", "in_app": [ { "quantity": "1", "product_id": "fr.gaumontvideo.gaumontclassique.subscription.monthly.apple", "transaction_id": "270002386706194", "original_transaction_id": "270002386706194", "purchase_date": "2025-08-16 08:02:06 Etc/GMT", "purchase_date_ms": "1755331326000", "purchase_date_pst": "2025-08-16 01:02:06 America/Los_Angeles", "original_purchase_date": "2025-08-16 08:02:08 Etc/GMT", "original_purchase_date_ms": "1755331328000", "original_purchase_date_pst": "2025-08-16 01:02:08 America/Los_Angeles", "expires_date": "2025-09-16 08:02:06 Etc/GMT", "expires_date_ms": "1758009726000", "expires_date_pst": "2025-09-16 01:02:06 America/Los_Angeles" } }

What follows is about tvOS 15 but may also apply to iOS 15. Our app may display several types of UICollectionView cells and it depends on the content sent by our backend. Prior to tvOS 15, we used to lazily instantiate UICollectionView cell registrations when needed for the first time while building a UICollectionViewDiffableDataSource. Eventually, each cell registration is only instantiated once (or never). Now tvOS 15 throws an exception when doing so, pretending to prevent the app from creating a new cell registration each time. And it does not care whether it's actually a new cell registration each time or one that is lazily instantiated once. Here is the exception: *** Assertion failure in -[UICollectionView dequeueConfiguredReusableCellWithRegistration:forIndexPath:item:], UICollectionView.m:7413 *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Attempted to dequeue a cell using a registration that was created inside -collectionView:cellForItemAtIndexPath: or inside a UICollectionViewDiffableDataSource cell provider. Creating a new registration each time a cell is requested will prevent reuse and cause created cells to remain inaccessible in memory for the lifetime of the collection view. Registrations should be created up front and reused. Registration: <UICollectionViewCellRegistration: 0x6000000f8c60>' I understand the concern but lazy instantiation is a thing and it should not be for forbidden for the sake of best practices that are not related to it. In my humble opinion, this assert should be removed and apps should be allowed to create cell registrations on the fly.

I'm able to build and run the TV app with the TVTopShelf extension on simulators and physical Apple TVs but I get an error when I try to validate (or distribute) the archive built from XCode. The error says: App Store Connect Operation Error - Asset validation failed The log files don't provide more information: "Error Domain=ContentDelivery Code=90362 "App Store Connect Operation Error" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedDescription=App Store Connect Operation Error, NSLocalizedRecoverySuggestion=Asset validation failed}" As far as I know the certificate, the identifiers and the provisioning profiles for both the tvOS app and the TVTopShelf extension are OK. When I choose to manually select signing options, I can set the provisioning profiles for both the app and the extension and XCode does not complain about them. Is there something specific to know when distributing an app with an extension app? Is there some configuration to set on AppStoreConnect side? Or common pitfalls to avoid? Thanks for your help.

Our iOS/AppleTV video content playback app uses AVPlayer to play HLS video streams and supports both custom and system playback UIs. The Fairplay content key is retrieved using AVContentKeySession. AirPlay is supported too. When the iPhone is connected to a TV through the lightning Apple Digital AV Adapter (A1438), the app is mirrored as expected. Problem: when using an iPhone or iPad on iOS 18.1.1, FairPlay-protected HLS streams are not played and a CoreMediaErrorDomain -12035 error is received by the AVPlayerItem. Also, once the issue has occurred, the mirroring freezes (the TV indefinitely displays the app playback screen) although the app works fine on the iOS device. The content key retrieval works as expected (I can see that 2 content key requests are made by the system by the way, probably one for the local playback and one for the adapter, as when AirPlaying) and the error is thrown after providing the AVContentKeyResponse. Unfortunately, and as far as I know, there is not documentation on CoreMediaErrorDomain errors so I don't know what -12035 means. The issue does not occur: on an iPhone on iOS 17.7 (even with FairPlay-protected HLS streams) when playing DRM-free video content (whatever the iOS version) when using the USB-C AV Adapter (whatever the iOS version) Also worth noting: the issue does not occur with other video playback apps such as Apple TV or Netflix although I don't have any details on the kind of streams these apps play and the way the FairPlay content key is retrieved (if any) so I don't know if it is relevant.

When playing an HLS/FairPlay VOD content, the playback position sometimes jumps to 0 during the transition between local and external playback (and the other way around). The app does nothing during the transition, apart from responding to ContentKeySession key requests. It is not systematic but occurs quite often. When the issue occurs, the playback sometimes resumes to the position where it was before the transition but usually it does not. Most of the time, when the issue occur, the iOS app periodic time observer gets triggered and the AVPlayerItem currentTime() has the specific value 0.001s. Here is an extract of our iOS app logs with the value of AVPlayerItem.currentTime() when the AVPlayer PeriodicTimeObserver is triggered: 📘 [8:21:54.520] Did update playback time: 4512.001719539 📘 [8:21:55.472] Did update playback time: 4512.958677777778 📗 [8:21:55.497] Player external playback active changed to: true 📘 [8:21:57.674] Did update playback time: 4512.001897709 📘 [8:21:57.779] Did update playback time: 4511.974062125 📘 [8:21:57.800] Did update playback time: 4511.995523418 📘 [8:21:57.805] Did update playback time: 4512.001181626 📘 [8:21:58.806] Did update playback time: 4513.001841876 📘 [8:21:59.794] Did update playback time: 4514.001132625 📘 [8:22:00.795] Did update playback time: 4515.001653707 📘 [8:22:01.562] Did update playback time: 4515.766148708 📗 [8:22:01.679] Player external playback active changed to: false 📘 [8:22:01.683] Did update playback time: 0.001 📘 [8:22:01.700] Did update playback time: 4510.0 📘 [8:22:01.737] Did update playback time: 4510.0 📘 [8:22:01.988] Did update playback time: 4509.956132376 📘 [8:22:01.990] Did update playback time: 4509.958216834 📘 [8:22:03.033] Did update playback time: 4511.0015079 📘 [8:22:04.033] Did update playback time: 4512.001688753 📘 [8:22:05.033] Did update playback time: 4513.001998495 📘 [8:22:06.033] Did update playback time: 4514.001205557 📘 [8:22:06.045] Did update playback time: 4514.0325555555555 📗 [8:22:06.080] Player external playback active changed to: true 📘 [8:22:06.800] Did update playback time: 0.0 📘 [8:22:06.814] Did update playback time: 0.0 📘 [8:22:08.168] Did update playback time: 0.002258708 📘 [8:22:08.218] Did update playback time: -0.075460416 📘 [8:22:08.237] Did update playback time: -0.063310916 📘 [8:22:09.298] Did update playback time: 1.001932292 📘 [8:22:10.295] Did update playback time: 2.003054584 📘 [8:22:11.302] Did update playback time: 3.001831125 📘 [8:22:12.301] Did update playback time: 4.001488001 Local -> AirPlay: no issue AirPlay -> Local: the issue occurs temporarily and the playback approximately returns to its position before the transition Local -> AirPlay: the issue occurs permanently and the playback continues from the beginning of the stream. I've filed a feedback for this issue with both iOS device and AppleTV sysdiagnoses: https://feedbackassistant.apple.com/feedback/11990309

We've been using our own logging system for quite a long time but we are interested in the benefits offered by Logger/OSLog and plan to migrate to it. Before modifying thousands of logging calls, we want to understand a bit more how, when and where (ie. from which thread/queue) OSLog strings interpolation is performed. More specifically, we are concerned by simultaneous access to properties from different threads. Our app usually handles that using DispatchQueues (single or concurrent) and calls to our logging system is safe as the log string is built synchronously. On the other hand, when using Logger/OSLog, the provided string is in fact an OSLogMessage which keeps a reference to values and properties in order to build the final String later (asynchronously). If it is correct, the "later" part concerns us. Example Let's consider the following class property profile (instance of Profile class which implements CustomStringConvertible): private var profile: Profile? With our own logging system, we used to log the profile property at the time the logging method is called (and when the access to profile is safe): Log.debug(logModule, "Current profile: \(profile)") Now moving to Logger/OSLog, the following error appears: logger.debug("Current profile: \(profile)") // Reference to property 'profile' in closure requires explicit use of 'self' to make capture semantics explicit Our understanding is that the property profile is not accessed synchronously but later, possibly after or even worse while the property is being mutated from another thread (-> crash). In which case fixing the error using "Current profile: \(self.profile)" instead would be a very bad idea... The same goes with class instance properties used in the implementation of CustomStringConvertible.description property. If the description property is built asynchronously, the class instance properties may have been mutated or may be being mutated from another thread. TL;DR We have searched for good practices when using Logger/OSLog but could not find any dealing with the thread-safeness of logged objects. Is it a good idea to capture self in Logger calls? Is it safe to log non value-type objects such as class instances? Thanks for clarifications.

During the video playback with the AVPlayer, our iOS and AppleTV apps set AVPlayerItem externalMetadata. Additionaly, the iOS app also sets the default MPNowPlayingInfoCenter nowPlayingInfo. The apps also register to MPRemoteCommands. What works: The iOS NowPlayingInfo center is properly filled with the metadata, the remote commands work well and on AppleTV, using the AVPlayerViewController, the info tab shows the content metadata. Problem: when AirPlaying the content to an AppleTV, the stream is properly played but no metadata are displayed on the AppleTV. I've tried to set nowPlayingInfo on the avPlayerItem or using an MPNowPlayingSession (new with iOS/tvOS 16) but with no luck. Can someone help me display the playerItem metadata on the AirPlay device?