A regression has been introduced with SwiftUI Menu in iOS 27 betas (still present in beta 6). This regression prevents objects whose properties are bound to contained Menu items from being correctly deallocated. In the example below, Player was immediately deallocated when the surrounding ModalView was dismissed on iOS 26 (or below): import Observation import SwiftUI @Observable final class Player { var playbackSpeed: Double = 1 } struct ModalView: View { @State private var player = Player() var body: some View { Menu { Picker(selection: $player.playbackSpeed) { ForEach([0.5, 1, 1.5, 2], id: \.self) { speed in Text("\(speed, specifier: "%g×")").tag(speed) } } label: { Text("Speed") } .pickerStyle(.inline) } label: { Text("Menu") } } } This is not the case anymore on iOS 27 beta. The Player instance is not deallocated anymore. A dedicated feedback (FB24486991) has been opened.

For information I stumbled upon a regression with SwiftUI Slider on iOS 26. Its onEditingChanged closure might be called twice when interaction ends, with a final Boolean incorrect value of true provided to the closure. As a result apps cannot reliably rely on this closure to detect when an interaction with the slider starts or ends. I filed a feedback under FB20283439 (iOS 26.0 regression: Slider onEditingChanged closure is unreliable).

Hi, We have found a nasty issue with SwiftUI List and Equatable reference types. In such scenarios List might resurface stale objects from some internal cache when inserting new equal instances, which can lead to outdated cells on screen. Detailed information can be found in our bug report (FB23923342). Since List is quite a widespread component we thought dropping a few lines here in addition to our report could be helpful, especially if you have been bitten by this issue in the past.

Errors related to media playback, whether received from AVPlayer directly or read from an AVPlayerItem access log, usually lack information about the root cause of a playback issue. Most errors we receive in the CoreMediaErrorDomain are namely associated with undocumented error codes and non-explicit error messages. Here are a few examples: Error Domain=CoreMediaErrorDomain Code=-12927 "(null)" Error Domain=CoreMediaErrorDomain Code=-16012 "(null)" Error Domain=CoreMediaErrorDomain Code=-12685 "The operation couldn’t be completed." Error Domain=CoreMediaErrorDomain Code=-12648 "The operation couldn’t be completed." It would be helpful that Core Media: Provides a public constant for the CoreMediaErrorDomain. Provides public constants for the error codes within this domain. Ensures each error is associated with a meaningful human-readable description. If not possible having at least a documented list of error codes (as is done in the FairPlay programming guide PDF, for example) would allow us to better classify errors and understand playback errors experienced by our users. I opened a FB17673165 feedback with this suggestion as well. Thanks in advance for considering this improvement request.

Starting with iOS 26.4 and the iOS 26.4 SDK, the .pauses audiovisual background playback policy is not correctly applied anymore to an AVPlayer having an attached video layer displayed on screen. This means that, when backgrounding a video-playing app (without Picture in Picture support) or locking the device, playback is not paused automatically by the system anymore. This issue affects the Apple TV application as well. We have filed FB22488151 with more information.

Hi, We identified massive amounts of leaked memory with the tvOS 26 standard player user interface as soon as chapters (navigation markers) are involved. Artwork images associated with chapters are not correctly released anymore, leaking memory in chunks of several MiBs. Over time apps will be terminated by the system due to excessive memory consumption. The issue was reported to Apple as tvOS 26 regression: Huge memory leaks associated with navigation marker artworks displayed in the tvOS standard user interface, filed under FB21160665.