Moff, I confirm that on my side the unreleased reference also comes from _UIFloatingTabBarItemView. Richard, as to why my hack didn't work for Moff, it is definitely related to the version of iPadOS. iPadOS 18.7.1 (physical iPad): there is an additional unreleased reference to the tab bar view controller from a _UIFloatingTabBarItemCell. However my hack works. iPadOS 26.2 (simulator): there's only one reference from a _UIFloatingTabBarItemView, exactly as you described (same memory graph as yours). And indeed my hack doesn't work I hope the issue will be fixed for both versions of iPadOS. Please keep us posted here.

I've just run into this issue and I can confirm that the memory leak does not occur on iPhone (iOS 18.7.1 and iOS 26) even when using UITabs occurs on iPad (iOS 18.7.1) only when using UITabs. It does not occur when setting the tab bar controller children the old way (setViewControllers(:animated:)). A work around is to use a custom TabBarController inheriting from UITabBarController and override viewDidDisappear(:) as follows: override func viewDidDisappear(_ animated: Bool) { super.viewDidDisappear(animated) // HACK: clear the tabs property to prevent memory leaks when using UITabs if #available(iOS 18, *) { setTabs([], animated: false) } } It effectively triggers the children view controllers deinit. App build with Xcode 26.2 on macOS 26.2.

Thanks Quinn for your answer. Everything makes sense now and we are relieved that you confirmed that the arguments evaluation is done in the logging call thread.

Some of our end-users experience the same issue with offline content keys. We had to disable content key persistence support until we fix the issue. I even reproduced it once myself with a valid (ie. not expired) offline content key: once providing the offline content key to the AVKeyRequest, the system immediately fails the AVPlayerItem (no automatic retry at AVContentKeySession level) with error CoreMediaErrorDomain:-42650. It is systematic and can only be solved by deleting the offline content key from the app content key store (which forces the app to retrieve a new content key from the KSM). Unfortunately, offline content keys lease duration being 30 days, it is not easy to reproduce the issue and provide logs. Could Apple provide more information on this error specifically and on CoreMediaErrorDomain errors in general? The lack of documentation is very annoying and developers can only empirically list errors when they occur (examples: https://developerinsider.co/fairplay-streaming-error-codes/, https://developer.bitmovin.com/playback/docs/system-error-codes-ios).

I have reported the issue with Feedback assistant: https://feedbackassistant.apple.com/feedback/17172515 I have also included a sample project allowing to easily reproduce the issue.

Actually the problem is even worse: the AVPlayer.currentTime() does not change anymore after the playback transitions from AirPlay (to an Apple TV) to local despite the playback still ongoing. Also, it's worth noting that when the issue occurs, AVPlayer.currentDate() is properly updated. So the problem is probably not related to the periodic time observation but rather to the AVPlayer.currentTime() not being updated anymore when switching from AirPlay to local playback.

Sure: https://feedbackassistant.apple.com/feedback/16902752

Thanks for your response. I filed a bug report on Feedback Assistant with the following id: FB16047318 (CoreMediaErrorDomain -12035 error when playing a Fairplay-protected HLS stream on iOS 18+ through the Apple lightning AV Adapter).

Have you received any feedback from Apple or even found out what was the problem? It may not be related but I'm currently having a CoreMediaErrorDomain -12035 error using the same AV adapter when streaming FairPlay-protected content but only on iOS 18+. It works fine on iOS 17.7. https://developer.apple.com/forums/thread/770159

Same logs when opening the share sheet on iOS 17.

Many thanks for your reply. I indeed ended up with the two changes: For HTTP 1.1 requests, I added the "Connection: close" request header For HTTP 2 requests, I implemented the (empirical) detection of such errors and a one-time retry Both changes allow the app to either avoid the issue (1) or seamlessly handle it (2). Unfortunately, it does not help with the related issue (which is fortunately far less systematic) as the requests fail several (tens of) seconds after the dataTask is sent, time during which the user waits for his action to be performed or information to be displayed. But maybe this related issue is not as related as I think...

Apple documentation indicates that it is supported (https://developer.apple.com/documentation/mediaplayer/handling_external_player_events_notifications) but I haven not found any sample code nor been able to make it work my self. My goal is to allow the user to control the GoogleCast playback from the CommandCenter.

Turns out the Xcode "Validate App" action does not provide an explicit error whereas the "Distribute App" action does. And I've been able to fix my issue: the TV Top Shelf executable name in its Info.plist did not match the bundle folder name.