We are building an accessibility-focused iOS app that uses a user-initiated ReplayKit broadcast to recognize visible text and provide an on-device translation. To keep the translated result visible while the user is in another app, the current prototype presents the translation UI with AVPictureInPictureVideoCallViewController. The problem is that ReplayKit includes this PiP window in the captured frames. Once the captured frame is rendered back into the PiP content, the PiP captures itself recursively, obscures the source text, and can significantly degrade performance. Reproduction: Start a system broadcast using RPSystemBroadcastPickerView. Present AVPictureInPictureVideoCallViewController with the app's translation UI. Leave the host app and place the PiP window over another app. Inspect the CMSampleBuffer frames received by the broadcast upload extension. The frames contain the PiP window itself, producing a repeated "window inside window" image. We need a public, App Store-safe architecture that: keeps a small user-controlled translation surface visible across apps; allows the user to move or collapse it; prevents that app-owned floating surface from appearing in ReplayKit capture; uses only explicit user activation and documented APIs. Questions: Is there a supported public API or entitlement that excludes an app-owned PiP window, UIWindow, view, or layer from ReplayKit capture? If not, is there a supported alternative to PiP for a compact cross-app accessibility controller that the system excludes from capture? Is the broadcast upload extension expected to receive any metadata identifying the PiP region so it can be masked without relying on visual heuristics? We are not requesting private API access. A focused Xcode reproduction project has already been provided to Apple Developer Technical Support under an active TSI, and the related enhancement request is FB24319994. Environment: Xcode 26.6 (17F113) iPhone / iOS 18 and later ReplayKit broadcast upload extension AVPictureInPictureVideoCallViewController Any documented approach or confirmation that this is currently unsupported would be very helpful.

The documentation for AVCaptureDevice.uniqueID states the following: Capture devices have a unique identifier that persists on one system across device connections and disconnections, application restarts, and reboots of the system itself. You can store the value returned by this property to recall or track the status of a specific device in the future. For UVC capture devices this documentation does not hold. The video uniqueID is a hex string of the form 0x<locationID><vendorID><productID>, and the identifying half is the locationID (bus number plus port path). Which identifies a port, not a device. I ran a suite of tests with three identical Elgato 4K X capture cards connected to a Mac Studio w/ M3 Ultra running macOS 26.5.2, and reproduced my findings on a MacBook w/ M3 Pro (same macOS version). See the script at the bottom of the post for how uniqueId & USB serial number are being retrieved. 1. The uniqueID follows the port. Swapping two cards between two built-in ports swaps their uniqueIDs: # Before swap. 4K X uid=0x2000000fd9009b serial=A7SNB50424UBQI 4K X uid=0x12000000fd9009b serial=A7SNB504219J0R # After swapping the cards between the same two ports. 4K X uid=0x2000000fd9009b serial=A7SNB504219J0R 4K X uid=0x12000000fd9009b serial=A7SNB50424UBQI An app that stored 0x2000000fd9009b to recall a specific capture card now silently opens another. 2. A reboot alone can swap uniqueIDs. External USB controllers (here, PCIe USB cards in two Thunderbolt enclosures) can race for bus numbers at boot, so with every cable left in place, a reboot swapped two of the cards: # Before reboot. 4K X uid=0x262000000fd9009b serial=A7SNB504219J0R 4K X uid=0x252000000fd9009b serial=A7SNB50423R73R # After reboot, no cables touched. 4K X uid=0x262000000fd9009b serial=A7SNB50423R73R 4K X uid=0x252000000fd9009b serial=A7SNB504219J0R This behavior is intermittent, a second reboot changed nothing, but a third caused another swap. Cards left alone in built-in ports retain their uniqueIDs across reboots in my testing; the failure requires dynamically enumerated external USB controllers. 3. Even the product ID tail can drift. One unit intermittently enumerates with idProduct 0x009c instead of 0x009b, same port (USB PCIe card in a Thunderbolt enclosure), cables untouched: # Before reboot. 4K X uid=0x222000000fd9009b serial=A7SNB50424UBQI # After reboot. 4K X uid=0x222000000fd9009c serial=A7SNB50424UBQI IOKit and AVFoundation agree each boot... So the change is upstream of both? I'm uncertain where to place blame for this specific issue (UVC device or macOS). Audio on the same physical units is unaffected. The audio uniqueID (AppleUSBAudioEngine:...:<serial>:...) embeds the USB serial and stayed stable through every test. So AVCaptureDevice can provide a stable per-device identifier, just not for UVC video devices. Questions: Is this a bug, or is the documentation overstating the persistence guarantee for USB video devices? What is the supported way to identify a specific physical UVC video device across reboots and port changes? The USB serial number is stable and is what I've fallen back on via IOKit, but there is no documented AVFoundation API to retrieve USB serial number from a UVC video AVCaptureDevice. Related: thread 803759, where the locationID-derived format is described. Script used for all output above (swift ./list-uvc.swift): import AVFoundation import IOKit func usbSerial(forLocation location: UInt32) -> String? { var iterator: io_iterator_t = 0 guard IOServiceGetMatchingServices(kIOMainPortDefault, IOServiceMatching("IOUSBHostDevice"), &iterator) == KERN_SUCCESS else { return nil } defer { IOObjectRelease(iterator) } var result: String? var service = IOIteratorNext(iterator) while service != 0 { var loc: UInt32 = 0 if let ref = IORegistryEntryCreateCFProperty(service, "locationID" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let num = ref as? NSNumber { loc = num.uint32Value } if loc == location, let ref = IORegistryEntryCreateCFProperty(service, "USB Serial Number" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let serial = ref as? String { result = serial } IOObjectRelease(service) if result != nil { break } service = IOIteratorNext(iterator) } return result } let session = AVCaptureDevice.DiscoverySession(deviceTypes: [.external], mediaType: .video, position: .unspecified) for device in session.devices { let uid = device.uniqueID let location = UInt32(truncatingIfNeeded: strtoull(uid, nil, 16) >> 32) let serial = usbSerial(forLocation: location) ?? "N/A" print("\(device.localizedName) uid=\(uid) serial=\(serial)") }

I’m developing a small macOS workflow utility for Final Cut Pro and I’d like to confirm whether there is a supported API for a particular project-management workflow before relying on macOS Accessibility automation. The utility is intended to take an existing Final Cut Pro project and create multiple native duplicates at different custom frame sizes — for example: 1920 × 1080 1080 × 1920 1080 × 1350 1080 × 1080 custom banner dimensions The desired operation is essentially the equivalent of Final Cut Pro’s Duplicate Project As… command: duplicate the selected project, assign a new name, set a custom video resolution, and optionally enable or disable Smart Conform. It is important that Final Cut Pro itself performs a native project duplication so that all existing project data is retained, including effects, grades, plug-ins, keyframes, compound clips, retiming and Magnetic Masks. I initially prototyped the workflow using FCPXML, which works very well for creating the differently sized projects. However, Apple’s documentation notes that Magnetic Masks are not included in XML exports, so an FCPXML round-trip is not suitable for this use case. I’ve reviewed the documentation for FCPXML, Workflow Extensions / ProExtensionHost, and programmatic communication with Final Cut Pro using Apple Events, but I haven’t found a documented API that allows an application to: Duplicate the currently selected Final Cut Pro project natively. Rename the duplicated project. Change its video format to an arbitrary custom width and height. Optionally control Smart Conform. I currently have a working proof of concept using the macOS Accessibility API to invoke and operate Final Cut Pro’s native Duplicate Project As… interface. Before developing that approach further, I’d like to confirm that I’m not overlooking a supported Final Cut Pro API or Workflow Extension capability that would accomplish the same thing more directly and robustly. Is there a supported public API for this workflow, either through the Workflow Extension SDK, ProExtensionHost, Apple Events, scripting support, or another Professional Video Applications framework? If not, is using macOS Accessibility to automate Final Cut Pro’s native project-duplication interface an appropriate approach for a third-party macOS workflow utility? Many thanks, James

I would like to understand how the L4S feature works with videocalls, specially with FaceTime, since it has been improved and made compatible with this capability. Even if it's just a qualitative comparison, I'd like to compare a video call under network congestion conditions between an iPhone with L4S enabled and one without (on a network that supports L4S). To do this: I would like to know if I could conduct this test using a single device with L4S enabled (in developer mode) and another without L4S, with the server located on the internet. Or both devices would need to have L4S enabled, because the client and server for L4S would then be the two devices themselves (point-to-point). Thank you.

The set bitrate is not respected when kVTCompressionPropertyKey_AverageBitRate is used. constant and variable bitrates seems to work, only average that is broken. All three modes works in iOS 26.

Summary. iPhone 17 Pro Max + Blackmagic Camera ProDock, genlock BNC in from a generator confirmed at a true 30.00 fps. follow(_:videoFrameDuration:delegate:) reaches .activeSync in ~2 s. On one unit the lock then holds for 10+ minutes. On a second unit, same binary and same reference, it detaches 6 s to ~4 min after lock: .activeSync → .ready with input.externalSyncDevice == nil, no runtime error and no delegate error. Calling follow() again on the still-running session is rejected with -11800 every time, while unfollowExternalSyncDevice() plus a stopRunning()/startRunning() bounce recovers reliably. I am not looking for a fix. I want to know whether my call sequence is wrong, whether this transition is expected, and how a shipping app should be structured around it. Questions Is re-following a running session supported? Is the unfollow + bounce the intended reset sequence, or is there a lighter-weight way to clear whatever state the -11800 is keyed on? And once detached, is re-acquisition entirely the app's responsibility, or is the system expected to re-calibrate on its own while the reference is present? Is a hard detach a legal outcome for an already-calibrated input? The documentation describes .freeRunSync as the hold-over when a locked input loses sync. Is that hold-over guaranteed, or must an app also handle .activeSync → .ready with a nil externalSyncDevice? Is anything in my call sequence wrong (code in a reply below), and is polling input.externalSyncDevice the right signal to key recovery on, or is there a supported notification for detach? Setup. Video-only AVCaptureSession: one .builtInWideAngleCamera input, one AVCaptureVideoDataOutput. No multi-cam, no depth output, no synchronizer, no audio. Both frame durations set to CMTime(1, 30) before the input is created, never rewritten while a follow is live. Device A (iOS 26.0.1) holds: 601 s and 956 s runs, zero detaches. Device B (26.3.1, then 26.5.2) has 39 drops across 6 logs. The ProDock, cable and generator were swapped between units; the failure followed the phone. Caveat: n=2, and unit and OS build vary together. The detach. No AVCaptureSessionRuntimeError and no delegate error (-11892 has never been observed here, so this is not the documented frame-duration-mismatch path). The session keeps running and delivering frames. Status is .ready, not .unavailable — the ProDock stays enumerated, the reference unchanged. No confirmed drop has passed through .freeRunSync. PTS ground truth, independent of the follow state: while locked, every frame PTS sits exactly on the 1/30 grid, zero drift. At the drop there is exactly one teardown gap, 238–337 ms across 8 runs, after which the clock free-runs at ~30.013 fps (444 ppm) and never returns to the grid. On -11800. It surfaces through AVCaptureSessionRuntimeErrorNotification. The bounce recovers 3/3, with no activeFormat change. Caveat: -11800 is AVErrorUnknown and I see it in unrelated cases too, so I do not assume it is specific to retained follow state. Ruled out. Exposure duration — a run at ≤ 16.67 ms, within the recommendation in the follow() documentation, still drops. Reference drift — zero, by microsecond PTS. Accessory chain — full swap; the failure followed the phone. Another client — Final Cut Camera holds genlock on the fragile unit with the same ProDock and reference. Load and resolution — load changes time-to-drop, not whether it drops; with recording and audio off it still drops, and Device B drops at both 12 MP and 1080p. Code and supporting logs are in replies below; the length limit would not take them inline. Per-frame PTS CSVs, raw status logs, and a minimal Xcode project that still drops are available on request. Prior art read: forums/thread/799739 and thread/804594 — neither covers post-lock detach or re-acquisition.

visionOS 26.5, xcode26.5 - app terminated with exit code 9 then crashed and rebooted the entire device (Apple Vision Pro). I was connected to the Xcode debugger when this happened, and it didn't crash in any of our code. Memory and CPU usage was low at the time. Any idea what could be causing the issue? Some logs: << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 ... Call start on AVKSDockingService before making requests. <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 SessionCore_NotificationHandlers.mm : 73 Server returned an error:. Error Domain=NSOSStatusErrorDomain Code=-50 "Session lookup failed" UserInfo={NSLocalizedDescription=Session lookup failed} <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 ... nw_read_request_report [C 1 ] Receive failed with error " No message available on STREAM " nw_protocol_socket_reset_linger [C1:2] setsockopt SO_LINGER failed 22 Debug session ended with code 9: Terminated due to signal 9 Program ended with exit code: 9 Thanks, bvsdev

So, in macos golden gate 27, there is this new live subtitles that happens in every video that i can't even turn off? (live captions is off) and also is there anyway from code we can turn this feature off, because making a background app, it exists whenever, and i can't seem to find a way to disable it from coding and the app.

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 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.

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?

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.

While working with VTCompressionSession, I noticed some profiles that were returned by the VTSessionCopySupportedPropertyDictionary but were not documented in header files (other than appearing in the VideoToolbox.tbd file). Specifically: kVTProfileLevel_HEVC_Main44410_AutoLevel kVTProfileLevel_HEVC_Main444_AutoLevel kVTProfileLevel_H264_High444Predictive_AutoLevel If I manually define these, they do seem to work OK (macOS/Xcode 26.4). I expect the answer will be that they are undocumented for a reason, but hasn't 4:4:4 encode been a feature for a while?

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.

Hello, We are investigating an issue with offline HLS playback using AVQueuePlayer and would like to know whether anyone else has experienced similar behavior. Issue We download HLS content using AVAssetDownloadURLSession and play it offline using AVQueuePlayer. For some titles (but not all), after several consecutive episode transitions, the player unexpectedly attempts a network request while the next episode is already queued and the current episode has approximately 60 seconds remaining. If the device is offline, playback fails with: NSURLErrorDomain Code = -1009 and the next episode never starts. Characteristics The issue only affects certain titles. It is fully reproducible for affected titles. For example, if it occurs between Episodes 5 and 6 after starting playback from Episode 1, it always occurs at the same point when replaying from Episode 1. If playback starts directly from Episode 5, the issue does not occur. The issue only occurs when using AVQueuePlayer. Replacing the current item (removeAllItems() + replaceCurrentItem(with:)) avoids the issue, although this is unfortunately not a viable workaround because it breaks our Picture in Picture episode transition behavior. We compared the downloaded packages (boot.xml, Master Playlist, and Stream configuration) between affected and unaffected titles, but so far have not identified any meaningful structural differences that explain the behavior. Questions Has anyone experienced similar behavior with: offline HLS (.movpkg) AVQueuePlayer unexpected network requests during queued playback NSURLErrorDomain Code=-1009 even though the content is downloaded for offline playback If anyone has seen a similar issue or has any information, observations, or suggestions for further investigation, I would greatly appreciate hearing from you. For reference, I have already submitted this issue through Feedback Assistant. Feedback ID: FB23487817 Thank you in advance for any information.

The documentation for AVCaptureDevice.uniqueID states the following: Capture devices have a unique identifier that persists on one system across device connections and disconnections, application restarts, and reboots of the system itself. You can store the value returned by this property to recall or track the status of a specific device in the future. For UVC capture devices this documentation does not hold. The video uniqueID is a hex string of the form 0x, and the identifying half is the locationID (bus number plus port path). Which identifies a port, not a device. I ran a suite of tests with three identical Elgato 4K X capture cards connected to a Mac Studio w/ M3 Ultra running macOS 26.5.2, and reproduced my findings on a MacBook w/ M3 Pro (same macOS version). See the script at the bottom of the post for how uniqueId & USB serial number are being retrieved. 1. The uniqueID follows the port. Swapping two cards between two built-in ports swaps their uniqueIDs: # Before swap. 4K X uid=0x2000000fd9009b serial=A7SNB50424UBQI 4K X uid=0x12000000fd9009b serial=A7SNB504219J0R # After swapping the cards between the same two ports. 4K X uid=0x2000000fd9009b serial=A7SNB504219J0R 4K X uid=0x12000000fd9009b serial=A7SNB50424UBQI An app that stored 0x2000000fd9009b to recall a specific capture card now silently opens another. 2. A reboot alone can swap uniqueIDs. External USB controllers (here, PCIe USB cards in two Thunderbolt enclosures) can race for bus numbers at boot, so with every cable left in place, a reboot swapped two of the cards: # Before reboot. 4K X uid=0x262000000fd9009b serial=A7SNB504219J0R 4K X uid=0x252000000fd9009b serial=A7SNB50423R73R # After reboot, no cables touched. 4K X uid=0x262000000fd9009b serial=A7SNB50423R73R 4K X uid=0x252000000fd9009b serial=A7SNB504219J0R This behavior is intermittent, a second reboot changed nothing, but a third caused another swap. Cards left alone in built-in ports retain their uniqueIDs across reboots in my testing; the failure requires dynamically enumerated external USB controllers. 3. Even the product ID tail can drift. One unit intermittently enumerates with idProduct 0x009c instead of 0x009b, same port (USB PCIe card in a Thunderbolt enclosure), cables untouched: # Before reboot. 4K X uid=0x222000000fd9009b serial=A7SNB50424UBQI # After reboot. 4K X uid=0x222000000fd9009c serial=A7SNB50424UBQI IOKit and AVFoundation agree each boot... So the change is upstream of both? I'm uncertain where to place blame for this specific issue (UVC device or macOS). Audio on the same physical units is unaffected. The audio uniqueID (AppleUSBAudioEngine:...:<serial>:...) embeds the USB serial and stayed stable through every test. So AVCaptureDevice can provide a stable per-device identifier, just not for UVC video devices. Questions: Is this a bug, or is the documentation overstating the persistence guarantee for USB video devices? What is the supported way to identify a specific physical UVC video device across reboots and port changes? The USB serial number is stable and is what I've fallen back on via IOKit, but there is no documented AVFoundation API to retrieve USB serial number from a UVC video AVCaptureDevice. Related: thread 803759, where the locationID-derived format is described. Script used for all output above (swift ./list-uvc.swift): import AVFoundation import IOKit func usbSerial(forLocation location: UInt32) -> String? { var iterator: io_iterator_t = 0 guard IOServiceGetMatchingServices(kIOMainPortDefault, IOServiceMatching("IOUSBHostDevice"), &iterator) == KERN_SUCCESS else { return nil } defer { IOObjectRelease(iterator) } var result: String? var service = IOIteratorNext(iterator) while service != 0 { var loc: UInt32 = 0 if let ref = IORegistryEntryCreateCFProperty(service, "locationID" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let num = ref as? NSNumber { loc = num.uint32Value } if loc == location, let ref = IORegistryEntryCreateCFProperty(service, "USB Serial Number" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let serial = ref as? String { result = serial } IOObjectRelease(service) if result != nil { break } service = IOIteratorNext(iterator) } return result } let session = AVCaptureDevice.DiscoverySession(deviceTypes: [.external], mediaType: .video, position: .unspecified) for device in session.devices { let uid = device.uniqueID let location = UInt32(truncatingIfNeeded: strtoull(uid, nil, 16) >> 32) let serial = usbSerial(forLocation: location) ?? "N/A" print("\(device.localizedName) uid=\(uid) serial=\(serial)") }

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?

I have an application which records video along with some custom metadata and a chapter track. The resultant video is stored in the Camera Roll. When sharing the video via the Share Sheet or AirDrop, the metadata track is stripped entirely (the chapter markers are preserved) Sharing via AirDrop with the "All Photos Data" option does include the metadata track, as does copying from the device with Image Capture but this is a bad user experience as the user must remember to explicitly select this option, and the filename is lost when sending this way. I have also tried various other approaches (such as encoding my metadata in a subtitle track, which I didn't expect to be stripped as it's an accessibility concern) but it's also removed. Essentially I am looking for a definitive list of things that are not stripped or if there's a way to encode a track in some way to indicate it should be preserved. The metadata is added via AVTimedMetadataGroup containing one AVMutableMetadataItem which has its value as a JSON string. I took a different approach with the Chapter Marker track (mainly because I did it first in a completely different way and didn't rework it when I added the other track). I post-process these after the video is recorded, and add them with addMutableTrack and then addTrackAssociation(to: chapterTrack, type: .chapterList) but I don't think that's the reason the chapter track persists where the custom metadata does not as other tests with video files from other sources containing subtitles etc also had their subtitle data stripped. tl;dr I record videos with metadata that I want to be able to share via Share Sheet and AirDrop, what am I doing wrong?

TLS + connectReceiver connect successfully, but the sender fails to negotiate the immersive video stream: VCVideoRuleCollectionsImmersiveVideoMac initSupportedPayloads: Empty supported payload: supportsMVHEVCEncode=0 Failed to create immersive video rules! AVCMediaStreamNegotiator … Failed to init … for mode=15 hardwareSettingsModeFromFeatureListStringType: Unexpected featureListStringType=0 connectReceiver failed … GKVoiceChatServiceErrorDomain 32032 Host: MacBook Pro M3 (Mac15,3), macOS 26/27. VTIsStereoMVHEVCEncodeSupported() returns true, and I set preferredVideoWidth/Height/FrameRate. Is immersive MV-HEVC encode in this API gated by an entitlement, a specific M-series tier (Pro/Max), or a known beta issue? What populates the "immersive video rules" feature list?