This is a test test test

We develop software for video broadcasting, including for sporting events, where animated scoreboards play a key role. macOS offers excellent features for such animations—such as CAAnimations—but this holds true only as long as the animations run on visible screens. Distributing the video signal (e.g., via NDI) requires access to the CVPixelBuffers of the individual frames. Currently, we generate the animations on an external screen and create the pixel buffers using ScreenCaptureKit. We are unaware of any way to obtain these pixel buffers without relying on such—strictly speaking, unnecessary—external screens (or multiple screens). If the window is created offscreen, it updates only once per second, which is unusable. Are there alternatives to external screens? If not, why can’t we create a virtual offscreen device for such use cases—one where we specify the required frame rate and rendering frequency—to generate the necessary video frames? This would also be helpful for HTML-based overlays, which are becoming increasingly popular; currently, these are also rendered only once per second when offscreen.

I saw that the Broadcast extension is deprecated in iOS 28, as well as the ReplayKit with nothing mentioned on what is going to be used going forward. I found out that the Screen Capture Kit is mentioned as replacement but is available for macOS only, even though some methods now are marked with iOS 28+ (https://developer.apple.com/documentation/screencapturekit). Will the ScreenCaptureKit be used for screen sharing going forward and replace the Broadcast Extension?

I'm batch-transcoding a library of clips into downscaled editing proxies. If I kick off two hardware transcodes at once, the encoder reliably falls over, so right now I run everything serially: each clip gets fully decoded, encoded, and muxed before the next one starts. It works, but it's slow, and the decode and encode hardware are mostly idle waiting on each other. A few things I can't pin down from the docs: Is there an actual ceiling on how many VTCompressionSession / VTDecompressionSession instances can be live at once, and does it depend on the device, the codec, or the resolution? Can I query that ceiling at runtime? I'd rather size my concurrency up front than find it by crashing. Decode and encode are separate hardware blocks, so can I safely run a decode session for one clip while the previous clip is still encoding, or does VideoToolbox serialize them anyway? When I do go over the limit, what should I be checking so I can back off cleanly? Right now I just get a crash instead of an error I can catch. Anything that gets me off the fully-serial pipeline would help. Thank you

I have a streaming video app in the App Store. I would like to use the automatic sign in feature for tvOS that was introduced in WWDC '25. However, it requires the com.apple.developer.video-subscriber-single-sign-on entitlement. I'm told that I have to join the video partnership program to access that entitlement. I filled out the forms to join the partnership program, but was ghosted. Would you consider making this feature available to everyone, not just those in the video partnership program? It is frustrating that a new and useful feature isn't actually available.

What is the recommended way of showing a processed image from AVCaptureVideoDataOutput in a swiftUI view? Currently my chain is AVCaptureVideoDataOutput(SampleBuffer) -> CIImage -> CIFilters -> createCGImage from processed CIImage -> Create swiftUI 'Image' from CGIImage, that is in a view Is there a better way to go from AVCaptureVideoDataOutput to a swiftUI view, with image processing?

These are follow up questions for: https://feedbackassistant.apple.com/feedback/22779473 For a large AVQueuePlayer queue (50-100+ HLS items), does AVFoundation guarantee it only allocates video decode sessions for the active and next item? Our profiling suggests this is the case, but we want to confirm whether we can rely on this behavior or if we should implement an application-side sliding window to limit concurrent decoders.

Today we are on-boarded to using CMCD data to allow us to get more diagnostic data of our streaming. We would like to have the ability to upload our own custom headers, this is supported on other players, but not supported on AVPlayer. The workaround today that works is adding in custom query parameters then querying based on that, but we would like support explicitly in the headers.

In our app, users select many videos (10–100+) that we upload to our server in one batch. Two problems compound each other: Backgrounding: Users almost always leave the app while the batch is in flight. Uploads started with a regular URLSession get suspended. Pre-upload transcoding: To reduce upload duration and cellular data usage, we downscale/re-encode each video (via AVAssetExportSession) before upload. This is resource-intensive and unlike a background URLSession upload task can't continue once the app is suspended, so the pipeline stalls even if the uploads themselves could continue. What's Apple's recommended design here? Is the intended pattern a background URLSession with file-based upload tasks, fed by a BGProcessingTask that drains the transcode queue opportunistically? Are there APIs we're missing, e.g. AVAssetExportSession's background-friendly options, HEVC/preferredTranscoding export presets that are cheaper, or any way to get extended runtime for the encode step (beginBackgroundTask budgets seem too short for dozens of videos)? And is there guidance on the trade-off of just uploading originals and transcoding server-side instead?