So my timeline is this: Got MBP 16' in March with graphics options: AMD Radeon Pro 5500M 4 GB Intel UHD Graphics 630 1536 MB Up until 10.15.5 came out, I had zero problems/crashes and I always have the laptop closed and an external display connected with an official Apple A/V adapter using HDMI. As soon as I installed 10.15.5 the panics started happening. Reason:					 (1 monitored services unresponsive): checkin with service: WindowServer returned not alive with context: unresponsive work processor(s): WindowServer main thread	40 seconds since last successful checkin Literally after the update ended, I didn't touch the laptop for some time, the external monitor went to sleep and the laptop panic'ed and rebooted. I installed apps like Caffeine to prevent the external monitor from going to sleep and managed to continue working. Some days after this the crashes started happening even when the monitor was not going to sleep. Usually when using apps that put some strain on the video such as video conferencing apps. These crashes started to become more frequent. The display froze, for about 2 minutes, the laptop started getting very warm and the fans would not go faster, then after 2 minutes the fans go into turbo mode for about 1 second and the laptop reboots. After this I reverted to 10.15.4 and reset SMC, etc, and the panics when the display goes to sleep are gone, but the crashes when I'm using the computer continue. I tried ditching the adapter and using a usb-c displayport cable but the problem remained. As a final test, I unplugged everything from the laptop and disabled "automatic graphics switching" to force the AMD to be used even with no external display. Sure enough, I was able to reproduce the issue. So it seems not related to an external display, but the AMD card itself (which is always used when an external display is connected). Sad times.

Since iOS 27 beta we are seeing a behavior change in our video streaming app and I would like to know whether others can reproduce it. Behavior on iOS 27 beta: Fully opening the Notification Center pauses playback. Audio continues for about 5 more seconds, then the app is suspended. Closing the Notification Center leaves the player paused. On iOS 26 the same build keeps playing in this situation. Setup: AVQueuePlayer playing video with audio, not muted audiovisualBackgroundPlaybackPolicy = .automatic (default) AVAudioSession category .playback, UIBackgroundModes: audio entitlement AVPictureInPictureController attached with canStartPictureInPictureAutomaticallyFromInline = true Filed as FB23893965 Questions: Can anyone reproduce this on iOS 27 beta? Is this intentional or a regression?

Hello Apple Support Team, My app’s new version appears to be taking longer than usual in the review process, and I’d like to check whether there might be an issue with the submission. App Information App Name: Dora - AI Video Generator Apple ID: 1604739131 Item for Review: New App Version Timeline Submitted: Sep 29, 2026 at 5:34 PM As of today (Oct 5), the app version has remained “In Review” for 5 days. Our app versions are normally reviewed within 1–2 days, so this delay is unusual for us. Could you please check whether there are any issues with the submission? If possible, we would also greatly appreciate any assistance in expediting the review. Any guidance or assistance would be greatly appreciated. Thank you for your time and support. Best regards, Smart Widget Labs Team.

Trivial pass-through compositor fails on Xcode 27 (beta 2, beta 3); error code -11800 underlying error -12784. Repro included https://github.com/BugorBN/avplayer-custom-compositor-repro It works well on Xcode26 and lower

I'm trying to update my proprietary app but failed, I found there are 2 reasons blocking the app update video is playing in app the app is active in multitasking windowed mode anyone has similar issue and how you address this?

Hi everyone, I recently submitted a request for the CarPlay Video App entitlement (com.apple.developer.carplay-video) via Apple's CarPlay entitlement request form. I submitted the request about a week ago, but I haven't received any update yet — no approval, rejection, or request for additional information. About the app: It is a video player designed for user-provided M3U/M3U8 playlists and locally imported media files. The app does not host, provide, or stream any built-in content itself. It follows Apple's CarPlay Video APIs and is intended to support video playback only when the vehicle permits video playback, such as when parked. I've noticed recent discussions from developers who already hold the CarPlay Video entitlement, but details regarding the review timeline seem quite limited. For developers who have successfully obtained the CarPlay Video entitlement: Approximately how long did it take from submitting the request form to receiving the entitlement decision? Did Apple reach out for additional details or clarification during the review process? Did you need an active TestFlight build or App Store submission prior to receiving the entitlement? Is there any dashboard or portal to track the status of a CarPlay entitlement request, or is email the only channel? Any insights from your experience would be greatly appreciated! Thanks!

Hello Apple Support Team, I'd like to kindly request an update regarding our latest app submission, which has remained in Waiting for Review since July 30, 2026. As of today (August 5), it has been 6 days without entering the review process. App Information App Name: Dora - AI Video Generator 2 Apple ID: 1604739131 Item for Review: App Version This submission is a major UI/UX revamp that significantly improves the overall user experience. After a long period of maintaining and iterating on the product, we redesigned many core user flows to provide a much more seamless and intuitive experience for our users. Our app continues to receive a large number of daily active users, so having this build remain in Waiting for Review is preventing them from accessing these important improvements and new experiences. The prolonged delay is having a meaningful impact on our users as well as our product rollout. We completely understand that review times can vary, but given the circumstances, we would greatly appreciate it if the review could be prioritized or expedited whenever possible. Thank you very much for your time and support. We truly appreciate the work of the App Review team and look forward to your response. Kind regards,

I'm observing an interesting behavior on iOS when uploading edited videos from the Photos library. Scenario Device: iPhone Video: 4K, 60 FPS Original video size (Photos app): 660 MB Uploaded original asset: 660 MB After applying a simple edit (e.g., a filter) in the Photos app: Photos app still shows the edited video. When my app uploads the current/edited asset, the uploaded file size becomes 167 MB. So the edited version is approximately 75% smaller than the original (660 MB → 167 MB), even though the duration appears unchanged. Questions Is this expected behavior for edited videos in the Photos library? Does iOS automatically re-encode edited videos using a lower bitrate or a different codec (e.g., HEVC) when generating the current rendition? Does the Photos app continue to display the size of the original asset rather than the size of the edited rendition? I'm aware that PhotoKit allows retrieving both the original and the current (edited) versions of a PHAsset. In this case, I'm intentionally retrieving the current version, and this behavior is observed only for the edited asset.

Hi all! I'm maintaining a 3D video player, it's great to see we've developed MV-HEVC packed with great features that media industry love to use. This player uses macOS AV frameworks to decode MV-HEVC and plays time-interleaving signal on capable devices, such as DLP-Link projectors, 3D vision glasses syncing devices, etc. Previously, the player output was flickering, unstable when playing MV-HEVC, and I thought it was due to M1 didn't have hardware decoder for it, or 4K Dolby Vision decoding was too demanding for my Mac, but out of luck, I tried retrieving only 1 eye for each frame output during the DisplayLink call, and the flickering is gone. At least that's what I've seen with a 100Hz screen while testing. Why is the performance improvement so significant? And is there other ways I can improve the performance, and perhaps the energy consumption? The link to the change I've committed

I’m getting Auto Layout constraint conflict warnings related to AVPlayerController in my tvOS project. This issue can be reproduced in an empty tvOS project either by simply using an AVPlayerViewController as a initial view controller or by presenting it. tvOS 26.2 Simple empty project with only one controller: import UIKit import AVKit class PlayerViewController: AVPlayerViewController { override func viewDidLoad() { super.viewDidLoad() } } After presenting that view controller, the following Auto Layout constraint conflict warnings appear in the console: Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. ( "<NSLayoutConstraint:0x60000212f5c0 UIStackView:0x103222520.width >= 217 (active)>", "<NSLayoutConstraint:0x60000212f610 H:|-(>=95)-[UIStackView:0x103222520] (active, names: '|':UIView:0x103216630 )>", "<NSLayoutConstraint:0x60000212f660 UIStackView:0x103222520.trailing == UIView:0x103216630.trailing - 95 (active)>", "<NSLayoutConstraint:0x60000212f7a0 H:|-(0)-[UIView:0x103216630] (active, names: '|':_AVFocusContainerView:0x10333aea0 )>", "<NSLayoutConstraint:0x60000212f7f0 UIView:0x103216630.trailing == _AVFocusContainerView:0x10333aea0.trailing (active)>", "<NSLayoutConstraint:0x6000021309b0 '_UITemporaryLayoutWidth' _AVFocusContainerView:0x10333aea0.width == 0 (active)>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x60000212f5c0 UIStackView:0x103222520.width >= 217 (active)> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger. The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful. How can I fix this issue? Thanks.

We are developing an iOS application that uses the MobileVLCKit framework (version 3.7.3) for RTSP video streaming. We have encountered a critical performance issue that directly affects user experience. Problem Description When the app is granted the Local Network permission (the switch in Apps → OurApp → Local Network), the VLC media player takes 10–15 seconds to start playback after calling play(). If the user manually disables this permission, playback starts immediately (within 1 second). The issue is 100% reproducible on real devices and does not appear on the simulator. What we have tried Adjusting VLC options (network-caching, rtsp-tcp, clock-synchro, etc.) — no effect. Using different RTSP streams (both local and public) — same delay. Checking network logs: the delay occurs before any actual RTSP handshake (DESCRIBE/SETUP), suggesting the system is waiting for something network-related. Why this is critical We cannot instruct our users to turn off Local Network access, because the app also needs this permission for legitimate features (e.g., discovering cameras on the local network). Disabling it permanently is not a viable solution. Request We kindly ask for your guidance: Is there a recommended way to configure the app or the VLC instance to avoid this delay while keeping Local Network permission enabled? Could this be a bug in the permission-handling layer that causes unnecessary timeouts? Are there any entitlements, plist keys, or runtime flags we should use to optimise network access in this scenario? We are happy to provide detailed logs, a sample project, or any other information that could help identify and resolve this issue. Environment iOS: 16.0+ Device: Physical (all) VLCKit: 3.7.3 (integrated via CocoaPods) Xcode: 26.5 Thank you for your time. We look forward to your response.

Environment Device: iPhone (reproducible on multiple devices) OS: iOS 27 Beta 1, Beta 2 Video Format: MP4 (H.264 Main Profile) Playback Method: Apple basic player (HTML5 Video / AVPlayer) Issue We are experiencing video stuttering during playback of a specific MP4 file on iOS 27 Beta 1 and Beta 2. The video plays smoothly on previous iOS versions, but on iOS 27 Beta, playback becomes choppy with noticeable frame drops. Steps to Reproduce Prepare a device running iOS 27 Beta 1 or Beta 2. Open the video URL. https://pdst.mimacstudy.com/daesungmimacfree/CDN/MIMAC/PUBLIC/IPS/2026/P260529018_H.mp4 Start playback. Expected Result The video should play smoothly without visible frame drops. Actual Result The video stutters during playback and appears to drop frames intermittently. Additional Information The issue is consistently reproducible. The affected file is encoded as H.264 Main Profile in an MP4 container. No obvious AVPlayer or system error logs are generated during playback. Has anyone observed similar behavior on iOS 27 Beta, or is there any known change in H.264 decoding behavior that could explain this issue?

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?

Avplayer encapsulates a player. After connecting to an Apple Bluetooth headset, it immediately reports an error. Non-Apple Bluetooth headsets can be played, but currently the issue is that the player works normally in one app but not in another. We are an educational app.

We've discovered a regression in iOS 26 where AVMutableComposition silently drops audio when the source asset is streamed over HTTP/2. The same file served over HTTP/1.1 plays audio correctly through the same composition code. Direct AVPlayer playback (without composition) works fine on HTTP/2. This did not occur on iOS 18.x. It happens on physical devices only. It does not reproduce on a simulator or on macOS. Tested conditions (same MP4 file, different CDNs): CloudFront (HTTP/2) + Composition → ❌ Audio silent Cloudflare (HTTP/2) + Composition → ❌ Audio silent Akamai (HTTP/1.1) + Composition → ✅ Audio works Apple TS (HTTP/1.1) + Composition → ✅ Audio works Downloaded locally, then composed → ✅ Audio works Direct playback, no composition (HTTP/2) → ✅ Audio works The CloudFront and Akamai URLs serve the identical file — same S3 object, different CDN edge. CDN vendor doesn't matter; any HTTP/2 source triggers it. Minimal reproduction: let asset = AVURLAsset(url: http2URL) let videoTrack = try await asset.loadTracks(withMediaType: .video).first! let audioTrack = try await asset.loadTracks(withMediaType: .audio).first! let duration = try await asset.load(.duration) let composition = AVMutableComposition() let fullRange = CMTimeRange(start: .zero, end: duration) let compVideo = composition.addMutableTrack(withMediaType: .video, preferredTrackID: kCMPersistentTrackID_Invalid)! try compVideo.insertTimeRange(fullRange, of: videoTrack, at: .zero) let compAudio = composition.addMutableTrack(withMediaType: .audio, preferredTrackID: kCMPersistentTrackID_Invalid)! try compAudio.insertTimeRange(fullRange, of: audioTrack, at: .zero) let item = AVPlayerItem(asset: composition.copy() as! AVComposition) player.replaceCurrentItem(with: item) player.play() // Video plays, audio goes silent after a while Playing the same asset directly works fine: player.replaceCurrentItem(with: AVPlayerItem(asset: asset)) player.play() // Both video and audio work Filed as FB22696516 Sample project: https://github.com/karlingen/AVCompositionBug

I’m getting Auto Layout constraint conflict warnings related to AVPlayerView in my project. I’ve reproduced the issue on macOS Tahoe 26.2. The conflict appears to originate inside AVPlayerView itself, between its internal subviews, rather than in my own layout code. This issue can be easily reproduced in an empty project by simply adding an AVPlayerView as a subview using the code below. class ViewController: NSViewController { override func viewDidLoad() { super.viewDidLoad() let playerView = AVPlayerView() view.addSubview(playerView) } } After presenting that view controller, the following Auto Layout constraint conflict warnings appear in the console: Conflicting constraints detected: <decode: bad range for [%@] got [offs:346 len:1057 within:0]>. Will attempt to recover by breaking <decode: bad range for [%@] got [offs:1403 len:81 within:0]>. Unable to simultaneously satisfy constraints: ( "<NSLayoutConstraint:0xb33c29950 H:|-(0)-[AVDesktopPlayerViewContentView:0x10164dce0](LTR) (active, names: '|':AVPlayerView:0xb32ecc000 )>", "<NSLayoutConstraint:0xb33c299a0 AVDesktopPlayerViewContentView:0x10164dce0.right == AVPlayerView:0xb32ecc000.right (active)>", "<NSAutoresizingMaskLayoutConstraint:0xb33c62850 h=--& v=--& AVPlayerView:0xb32ecc000.width == 0 (active)>", "<NSLayoutConstraint:0xb33d46df0 H:|-(0)-[AVEventPassthroughView:0xb33cfb480] (active, names: '|':AVDesktopPlayerViewContentView:0x10164dce0 )>", "<NSLayoutConstraint:0xb33d46e40 AVEventPassthroughView:0xb33cfb480.trailing == AVDesktopPlayerViewContentView:0x10164dce0.trailing (active)>", "<NSLayoutConstraint:0xb33ef8320 NSGlassView:0xb33ed8c00.trailing == AVEventPassthroughView:0xb33cfb480.trailing - 6 (active)>", "<NSLayoutConstraint:0xb33ef8460 NSGlassView:0xb33ed8c00.width == 180 (active)>", "<NSLayoutConstraint:0xb33ef84b0 NSGlassView:0xb33ed8c00.leading >= AVEventPassthroughView:0xb33cfb480.leading + 6 (active)>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0xb33ef8460 NSGlassView:0xb33ed8c00.width == 180 (active)> Set the NSUserDefault NSConstraintBasedLayoutVisualizeMutuallyExclusiveConstraints to YES to have -[NSWindow visualizeConstraints:] automatically called when this happens. And/or, set a symbolic breakpoint on LAYOUT_CONSTRAINTS_NOT_SATISFIABLE to catch this in the debugger. Is it system bug or maybe someone knows how to fix that? Thank you.

Description Our app, Octory, allows users to create onboarding and communication workflows composed of slides containing various UI components, including embedded video players powered by AVPlayerView. Since macOS 26.4 Beta, the app crashes at launch whenever a workflow contains a video component. Workflows without video components load and render without issue, which points to a regression in AVKit's player control rendering pipeline. As anyone seen similar behaviour when using AVKit or is it something we do not do properly? Expected Behavior The app opens and renders the workflow, including the embedded video component. Actual Behavior The app briefly launches and immediately crashes with SIGABRT on the main thread. Crash Analysis Key takeaways for anyone investigating: Root cause — abort() inside NSImageSymbolConfiguration The crash occurs entirely within Apple frameworks, with no third-party code in the faulting call chain (aside from the app's entry point). The sequence is: AVPlayerItem finishes loading and fires a KVO notification that it is ready to play (_updateCanPlayAndCanStepPropertiesWhenReadyToPlayWithNotificationPayload:) This KVO chain propagates through NSKeyValueDidChange up to AVPlayerView, which calls _updateVideoGravityType AVPlayerControlsViewController responds by calling _updateZoomButtonImage, which asks AVPlayerControlsConfigurator for a configured SF Symbol via +[NSImage(AVAdditions) avkit_imageWithSymbolName:textStyle:scale:accessibilityDescription:] The symbol rendering hits -[NSImageSymbolConfiguration _getEffectivePointSize:glyphWeight:glyphSize:backfilledWithFont:scale:], which calls abort() The entire crash stack is in AppKit (NSImage / NSImageSymbolConfiguration) and AVKit — no application code is involved in the faulting path. The abort() suggests a precondition or assertion failure inside the symbol configuration logic, possibly due to an invalid or nil font/text style being passed during the zoom button image setup. This is triggered automatically the moment an AVPlayerItem becomes ready to play and AVKit attempts to render its transport controls. There is no way for the application to intercept or work around this. Relevant stack frames (Thread 0 — main thread) 3 AppKit -[NSImageSymbolConfiguration _getEffectivePointSize:glyphWeight:glyphSize:backfilledWithFont:scale:] + 440 ← abort() here 4 AppKit -[NSImageSymbolRepProvider _bestRepresentationForImage:hints:] + 404 11 AVKit +[NSImage(AVAdditions) avkit_imageWithSymbolName:textStyle:scale:accessibilityDescription:] + 332 12 AVKit -[AVPlayerControlsConfigurator configuredSymbolForImageName:] + 92 13 AVKit -[AVPlayerControlsViewController _updateZoomButtonImage] + 160 14 AVKit -[AVPlayerControlsViewController setVideoGravityType:] + 52 15 AVKit -[AVPlayerView _updateVideoGravityType] + 1056 28 AVFCore -[AVPlayerItem didChangeValueForKey:] + 56 29 AVFCore -[AVPlayerItem _updateCanPlayAndCanStepPropertiesWhenReadyToPlayWithNotificationPayload:updateStatusToReadyToPlay:] + 660 Additional Notes Removing the video component from the workflow (i.e. not instantiating AVPlayerView) resolves the crash entirely. The crash is 100% reproducible on every launch. This behavior was not present on macOS 26.3 or any prior release. The app was not recompiled — the same binary that works on 26.3 crashes on 26.4 Beta & 26.4. Environment Detail Value OS macOS 26.4 Hardware MacBook Pro M1 (MacBookPro17,1)

I'm building a Capacitor iOS app with a plain <video> element playing an MP4 file inline. I want Picture-in-Picture to activate automatically when the user goes home — swipe up from the bottom edge of the screen (on an iPhone with Face ID) or press the Home button (on an iPhone with a Home button). Fullscreen → background works perfectly — iOS automatically enters Picture-in-Picture. But I need this to work from inline playback without requiring the user to enter fullscreen first. Setup <video id="video" playsinline autopictureinpicture controls src="http://podcasts.apple.com/resources/462787156.mp4"> </video> // AppDelegate.swift let audioSession = AVAudioSession.sharedInstance() try? audioSession.setCategory(.playback, mode: .moviePlayback) try? audioSession.setActive(true) UIBackgroundModes: audio in Info.plist allowsPictureInPictureMediaPlayback is true (Apple default) iOS 26.3.1, WKWebView via Capacitor What I've tried 1. autopictureinpicture attribute <video playsinline autopictureinpicture ...> WKWebView doesn't honor this attribute from inline playback. It only works when transitioning from fullscreen. 2. requestPictureInPicture() on visibilitychange document.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden' && !video.paused) { video.requestPictureInPicture(); } }); Result: Fails with "not triggered by user activation". The visibilitychange event doesn't count as a user gesture. 3. webkitSetPresentationMode('picture-in-picture') on visibilitychange document.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden' && !video.paused) { video.webkitSetPresentationMode('picture-in-picture'); } }); Result: No error thrown. The webkitpresentationmodechanged event fires with value picture-in-picture. But the PIP window never actually appears. The API silently accepts the call but nothing renders. 4. await play() then webkitSetPresentationMode document.addEventListener('visibilitychange', async () => { if (document.visibilityState === 'hidden') { await video.play(); video.webkitSetPresentationMode('picture-in-picture'); } }); Result: play() succeeds (audio resumes in background), but PIP still doesn't open. 5. Auto-resume on system pause + PIP on visibilitychange iOS fires pause before visibilitychange when backgrounding. I tried resuming in the pause handler, then requesting PIP in visibilitychange: video.addEventListener('pause', () => { if (document.visibilityState === 'hidden') { video.play(); // auto-resume } }); document.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden' && !video.paused) { video.webkitSetPresentationMode('picture-in-picture'); } }); Result: Audio resumes successfully, but PIP still doesn't open. 6. Native JS eval from applicationDidEnterBackground func applicationDidEnterBackground(_ application: UIApplication) { webView?.evaluateJavaScript( "document.querySelector('video').requestPictureInPicture()" ) } Result: Same failure — no user activation context. Observations The event order on background is: pause → visibility: hidden webkitSetPresentationMode reports success (event fires, no error) but the PIP window never renders requestPictureInPicture() consistently requires user activation, even from native JS eval Audio can be resumed in background via play(), but PIP is a separate gate Fullscreen → background automatically enters Picture-in-Picture, confirming the WKWebView PIP infrastructure is functional Question Is there any way to programmatically enter PIP from inline playback when a WKWebView app goes to background? Or is this intentionally restricted by WebKit to fullscreen-only transitions? Any pointers appreciated. Thanks!