Hi, I'm working on a project that uses the AVSpeechSynthesizer and AVSpeechUtterance. I discovered by chance that the AVSpeechSynthesizer automatically completes some words instead of just outputting what it's supposed to. These are abbreviations for days of the week or months, but not all of them. I don't want either of them automatically completed, but only the specified text. The completion transcends languages. I have written a short example program for demonstration purposes. import SwiftUI import AVFoundation import Foundation let synthesizer: AVSpeechSynthesizer = AVSpeechSynthesizer() struct ContentView: View { var body: some View { VStack { Button { utter("mon") } label: { Text("mon") } .buttonStyle(.borderedProminent) Button { utter("tue") } label: { Text("tue") } .buttonStyle(.borderedProminent) Button { utter("thu") } label: { Text("thu") } .buttonStyle(.borderedProminent) Button { utter("feb") } label: { Text("feb") } .buttonStyle(.borderedProminent) Button { utter("feb", lang: "de-DE") } label: { Text("feb DE") } .buttonStyle(.borderedProminent) Button { utter("wed") } label: { Text("wed") } .buttonStyle(.borderedProminent) } .padding() } private func utter(_ text: String, lang: String = "en-US") { let utterance = AVSpeechUtterance(string: text) let voice = AVSpeechSynthesisVoice(language: lang) utterance.voice = voice synthesizer.speak(utterance) } } #Preview { ContentView() } Thank you Christian

I'm looking for a supported way to show occasional contextual information over a FairPlay-protected video in system PiP (Picture in Picture) on iOS and macOS. For example, I'd like to briefly display a small icon or image and a short text label to give the viewer useful context. I want to leave the video stream unchanged and keep normal protected playback, with the additional information displayed as a separate UI layer. Standard protected playback in PiP works. My question is how to include that extra UI in the actual system PiP window, rather than only in the player view inside the app. Does AVKit provide a supported way to display and update image/text overlays on top of an AVPlayer-based PiP presentation while preserving FairPlay playback? If not, is this a general limitation of system PiP, or an additional restriction for protected video? What would be the recommended approach for this use case, including images as well as text?

We are developing CameraDirector, an iPhone application that controls external professional cameras through documented vendor APIs and reads back native recording state. We want an AirPods camera-remote press to request record start/stop on the selected external camera, then provide audible confirmation only after the camera reports its state. In external-camera control mode, the app would be in the foreground but would not be capturing video from an iPhone camera. The WWDC25 session 'Enhancing your camera experience with capture controls' states that AVCaptureEventInteraction (or SwiftUI's onCameraCaptureEvent) requires an active AVCaptureSession and does not receive events when the app is backgrounded: https://developer.apple.com/videos/play/wwdc2025/253/ Is there a supported configuration for receiving AirPods capture events in this external-camera mode without running a local iPhone camera capture? Does an active audio-only AVCaptureSession qualify, or does event delivery require an active video-camera input? If this is outside the intended API contract, is there another supported input path for this use case, or should we file an enhancement request? We have not yet established an on-device AirPods result for this configuration. We would appreciate guidance on the intended architecture or a relevant sample and can provide a focused reproducer for an implementation issue. Related capture-event implementation discussion: https://developer.apple.com/forums/thread/740616 Thank you, Eddie DaRoza ACTION Cinema Technologies

I'm seeing a camera preview rotation issue on iPadOS 27 that depends only on the SDK the app is linked against. I've filed it as FB25106148 and wanted to share it in case others hit the same problem. Sample project: https://github.com/bc-lee/avfoundation-rotation-coordinator-discrete-resizing-poc Setup Portrait-only iPad app with UIRequiresFullScreen = YES Front camera AVCaptureVideoPreviewLayer, rotated with AVCaptureDevice.RotationCoordinator, as in the AVCam sample: let coordinator = AVCaptureDevice.RotationCoordinator(device: device, previewLayer: previewLayer) // On every change of videoRotationAngleForHorizonLevelPreview: previewLayer.connection?.videoRotationAngle = coordinator.videoRotationAngleForHorizonLevelPreview iPad Pro 11-inch (4th generation), iPadOS 27.0.1, Stage Manager on, Rotation Lock off What happens after rotating the iPad from portrait to landscape Xcode 26.5 (iOS 26.5 SDK) Xcode 27.1 RC (iOS 27.1 SDK) App UI Stays upright for the user, letterboxed Stays in portrait and lies on its side with the device (discrete resizing, TN3192) videoRotationAngleForHorizonLevelPreview 180° 180° Camera preview Upright Sideways The source code and Info.plist are the same for both builds. interfaceOrientation, effectiveGeometry, window and screen bounds, and isInterfaceOrientationLocked are also identical between the two builds, so I couldn't find a public value that tells the two presentations apart. In the iOS 27 SDK build, applying videoRotationAngleRelative(toDeviceOrientation:) (new in iOS 27) for the scene's interface orientation, which gives 90°, instead of the horizon-level preview angle restores an upright preview. Questions Is videoRotationAngleForHorizonLevelPreview expected to reflect the discrete resizing presentation in iPadOS 27? Until that is resolved, is using videoRotationAngleRelative(toDeviceOrientation:) with the scene's interface orientation, only when linked against the iOS 27 SDK and running on iOS 27, a reasonable workaround? Has anyone else seen this, or found a better approach?

How can I tell which DNG opcode belongs to which OpcodeList for a RAW image captured by AVPhotoOutput? I couldn't find any of the OpcodeList1, OpcodeList2 or OpcodeList3 tags in the DNG metadata inside AVCapturePhoto.metadata, but when exporting the photo into a DNG file to disk and extracting that DNG file's metadata using exiftool on a computer, I could see the opcodes in their respective opcode lists. Can I get the opcode lists without exporting into DNG data representation and then parsing the DNG file?

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?

My App announces a place name aloud via AVSpeechSynthesizer (through expo-speech) while a background location task detects the user has entered a new town. This works correctly in the foreground. In the background, with the device screen locked, speech that has already started reliably pauses mid-utterance the moment the screen locks, and resumes and completes the moment the screen is unlocked — even though: The app has UIBackgroundModes: ['audio', 'location'] declared. A genuinely active, native-confirmed AVAudioSession is already running continuously in the background (a looping AVAudioPlayer via expo-audio, separate from the speech itself). AVSpeechSynthesizer.usesApplicationAudioSession is at its default (true), so the synthesizer shares that same active session rather than managing its own. This is not a crash, and AVSpeechSynthesizer never reports onError, the utterance simply stalls and then continues later, which looks exactly like a pause/resume cycle tied to the screen lock event itself rather than any audio session interruption we can detect. What is implemented app.config.js declares the audio and location background modes, and expo-audio's config plugin with enableBackgroundPlayback: true. At app launch, expo-audio's setAudioModeAsync is called once with: { playsInSilentMode: true, shouldPlayInBackground: true, interruptionMode: 'duckOthers' } (We also tested interruptionMode: 'doNotMix' see below.) For the duration of a tracked journey, a silent/near-silent AVAudioPlayer-backed loop is started via expo-audio's createAudioPlayer(), specifically so the app has genuine continuous audio output (not just a configured session) for the whole background session. The player is also registered as the active Now Playing session via setActiveForLockScreen() (expo-audio's wrapper around MPNowPlayingInfoCenter / MPRemoteCommandCenter). When a new place is detected (from a background expo-location task), we call Speech.speak() with the place name. onStart, onDone, onStopped, and onError callbacks are all logged for diagnostics. 5. We listen to the player's native playbackStatusUpdate event to know, from real OS-reported status (not just "the .play() call didn't throw"), whether the keep-alive loop is actually playing. Observed behavior: field test evidence Device log example (stationary repeated test): 08:29:01.948 onStart 08:29:02.092 keep-alive loop confirmed playing (native status) 08:29:07.666 onDone That's a 5.7s onStart-to-onDone gap for a phrase that normally takes under 2s — consistent with the utterance pausing mid-speech when the screen locked, then resuming on unlock. A separate test that stayed unlocked completed the same kind of phrase in 1.9s. On a real 68-minute drive, locked cycles showed 9.4-12.5s gaps; some builds with more aggressive session-reactivation never completed at all (onStart with no onDone/onStopped/onError). Throughout, the background AVAudioPlayer loop's native status still reports playing: true, and Control Center shows the app as Now Playing. So the AVAudioSession is confirmably alive — only the speech utterance itself stalls on lock. What we've ruled out: usesApplicationAudioSession already defaults to true (confirmed via WWDC 2020 session 10022), the synthesizer already shares our configured session, this isn't a missing option. Tried both doNotMix and duckOthers interruption modes. Neither stops the pause-on-lock. duckOthers additionally stops the app showing as Now Playing in Control Center (doNotMix does show it). Keep-alive liveness: native playback status confirms the background AVAudioPlayer reaches playing: true within 100-800ms every time — the session itself isn't failing to activate. We can't observe AVAudioSessionInterruptionNotification directly from our React Native audio libraries, only each library's own polled status — so we can't confirm whether a real interruption notification fires at the moment of lock. That's one of our questions below. Questions: Is it expected that AVSpeechSynthesizer, with usesApplicationAudioSession=true and an already-active background AVAudioSession (.playback category, UIBackgroundModes including audio), still pauses an in-progress utterance when the screen locks and resumes on unlock? If so, is there a supported way to prevent that for a navigation/voice-prompt app? Does locking the screen alone generate an AVAudioSessionInterruptionNotification for an app in this configuration, and if so what interruption type is reported? We can't observe this through our current libraries and want to know what native behavior to expect. Apple's "Audio Guidelines By App Type" doc gives two sets of guidance that both partly apply to us: navigation apps (activate the session only when a prompt is needed, deactivate after, use duckOthers) vs. playback apps (don't stream silence to avoid suspension, use a background task instead). Is there a recommended pattern for an app needing short, infrequent spoken prompts to continue through a locked screen, triggered by a background location task rather than continuous media playback?

TL;DR Requesting a system-level iOS feature or API to prioritize background audio over foreground app interruptions for enhanced neurodivergent accessibility. Granular Audio Session Priority and Control Center Override For users who rely on parallel cognitive processing - such as neurodivergent individuals managing attention through sensory layering like jumping across apps - abrupt audio interruptions are deeply disruptive. One scenario - a user is deep in cognitive flow listening to audio via Apple Music. They then switch to Instagram to check a text or post as natural neurodivergent attention switching and a video automatically fires up audio and instantly cuts the track playing on Apple Music. Regaining the audio stream requires manual intervention and therefore a breaking of focus. Proposal - I would love and suggest a native iOS feature or Control Center overlay allowing users to define audio hierarchy across apps, e.g. by locking background media as primary; open for ideas of course. This may as well be useful in therapeutical setups to easily silence potential notifications of lower priority over audio media designed to sensorically set guidelines for a session. Scope - while potentially helpful to users in the audio engineering and music playing scene running third-party-apps like Ableton and such, the feature request is intended to assist a basic and non-teh-savvy iOS user. Technical Question - is there any undocumented or upcoming capability within ⁠AVAudioSession⁠ categories/modes that could allow a developer to gracefully intercept or suppress automatic audio ducking/interruption from third-party foreground apps? PS First post. Nothing similar found on the forum. Nice request. Would love feedback or a technical review on feasibility.

We paint a looping 360° video on the inside of a sphere with VideoMaterial(avPlayer:): an AVQueuePlayer plus AVPlayerLooper, a ModelEntity with an inward-facing equirectangular mesh, inside a .mixed ImmersiveSpace. No shaders, no VideoPlayerComponent. We could not find an official Apple sample that puts a VideoMaterial on a 360° sphere; this is the plain pattern from the VideoMaterial(avPlayer:) reference and the one used in threads like 734081. On Apple Vision Pro hardware the video renders correctly. In the visionOS Simulator (27.0, 26.5 and earlier 26.x, Xcode 27.0) the whole frame has a strong purple/magenta cast. Audio and timing are fine. The video (which we cannot share, so here is its metadata, image sample of issue on simulator provided below): MP4, HEVC Main, 8-bit 4:2:0, 3840x1920, tagged BT.2020 primaries, HLG transfer (ARIB STD-B67), BT.2020 non-constant matrix, both in the colr atom and in the SPS VUI. ffprobe -show_format -show_streams (trimmed): [STREAM] index=0 codec_name=hevc profile=Main codec_type=video codec_tag_string=hvc1 width=3840 height=1920 pix_fmt=yuv420p color_range=tv color_space=bt2020nc color_transfer=arib-std-b67 color_primaries=bt2020 r_frame_rate=30000/1001 avg_frame_rate=679200/22663 duration=37.771667 bit_rate=25030607 [SIDE_DATA] side_data_type=Stereo 3D type=2D horizontal_field_of_view=360000/1000 [/SIDE_DATA] [/STREAM] [STREAM] index=1 codec_name=aac profile=LC codec_type=audio codec_tag_string=mp4a sample_fmt=fltp sample_rate=48000 channels=2 channel_layout=stereo duration=37.758333 bit_rate=128176 [/STREAM] [FORMAT] nb_streams=2 format_name=mov,mp4,m4a,3gp,3g2,mj2 duration=37.778333 bit_rate=25160348 TAG:major_brand=mp42 TAG:minor_version=1 TAG:compatible_brands=isommp41mp42 [/FORMAT] AVFoundation's view of the track, from CMFormatDescriptionGetExtension on the loaded video track: primaries=ITU_R_2020 transfer=ITU_R_2100_HLG matrix=ITU_R_2020 bitsPerComponent=8 The playback code, reduced to the essentials: let item = AVPlayerItem(url: fileURL) let looper = AVPlayerLooper(player: player, templateItem: item) // retained player.actionAtItemEnd = .advance let material = VideoMaterial(avPlayer: player) let sphere = ModelEntity( mesh: try equirectSphere(radius: 12), // lat/long grid, normals inward, materials: [material] // UVs (u, 1 - v), inward winding ) sphere.position = [0, 1.5, 0] rootEntity.addChild(sphere) // rootEntity was added in RealityView { } player.play() What we have ruled out in a minimal sample project: Apple's own 360° HLS example (360 Lighthouse, HEVC Main 10, 10-bit, BT.709 SDR) plays with correct colours in the same sphere, same code, same simulator session. Rewriting our file's colr atom to BT.709 (three bytes, no re-encode) is honoured by AVFoundation (the track's CMFormatDescription then reports ITU_R_709_2 for primaries, transfer and matrix) but the tint stays. So the remaining differences between the failing file and Apple's working stream are 8-bit Main vs 10-bit Main 10, HLG/BT.2020 in the bitstream VUI vs BT.709, and local MP4 vs HLS. The minimal sample project (without the video) is available on request. Is this a known limitation of the simulator's VideoMaterial path with 8-bit HLG content, and is there a recommended way to get device-equivalent colour in the simulator? Feedback filed as FB24997147. Here is a sample of the result on the simulator of a cement column, painted white, but rendered purple on simulator:

Hi Apple team, I’m developing Awaira, an iPhone app that runs real-time, on-device camera detection during a user-initiated support session. Its purpose is to help users notice hand-to-hair behavior. The user explicitly starts and stops the session; the camera indicator remains visible; camera frames are processed on-device; and the app does not record or transmit video. A common user request is to continue the session while using another app. On Android, this can be implemented with visible foreground-service behavior. On iOS, the capture session stops when Awaira is no longer foreground. I found AVCaptureSession.isMultitaskingCameraAccessSupported and isMultitaskingCameraAccessEnabled. The documentation says iOS 18 apps using UIBackgroundModes = voip may support multitasking camera access, and Apple’s PiP documentation discusses video-call apps. We do not provide a genuine person-to-person VoIP or video-calling service, and we do not want to misuse the VoIP background mode or create a fake call solely to keep camera detection active. Could Apple clarify: Is there any App-Review-approved API or entitlement for this kind of explicit, visible, user-initiated on-device camera session to continue while another app is foreground? Is declaring voip and using the multitasking-camera API permitted only for genuine VoIP/video-call apps? If no current approved path exists, is there a recommended design pattern for this accessibility/health-oriented use case? We will only ship an implementation that complies with the intended purpose of Apple’s APIs and App Review Guidelines. https://developer.apple.com/documentation/avfoundation/avcapturesession/ismultitaskingcameraaccesssupported Thank you.

I am testing a native Swift iPhone app that adds synthesized speech to an existing cellular call using: AVAudioApplication microphone injection permission AVAudioSession.setPreferredMicrophoneInjectionMode(.spokenAudio) AVSpeechSynthesizer CXCallObserver The audio background mode Device: iPhone 16 Pro Carrier: Vodafone Romania iOS version: [enter exact version] Both the system “Add Audio in Calls” setting and the app permission are enabled. Confirmed behavior: With the app in the foreground, the iPhone’s accessibility Auto-Answer Calls feature answers the call, and the remote caller hears the synthesized greeting. Problem: With the iPhone locked, the phone answers automatically, but the greeting does not start. Logs show ringing, connected, and ended events being processed together when the app returns to the foreground. This suggests the app was suspended. The app does not record the call or play continuous audio while waiting. Questions: Is there a supported public API that lets this app wake or execute when a cellular call connects while the iPhone is locked? Can microphone injection support this use case without keeping the app in the foreground? If supported, what audio-session configuration and background execution mechanism should be used? If unsupported, can you confirm this limitation? I can provide a minimal sample project and diagnostic logs.

We are developing a macOS application that tags local MP4/M4V movie and TV episode files for playback in the macOS TV app. We have encountered an intermittent artwork-display issue that we have been unable to explain from the file contents alone. The observed behavior The files contain embedded TV metadata and JPEG artwork. The files play correctly in the TV app. However, the TV app sometimes displays “No Artwork” for an episode even though the artwork is embedded in the file. More interestingly, the artwork can subsequently appear without modifying the file at all. For example, closing and reopening the TV app, or changing views, can cause artwork that was previously shown as missing to appear. This makes it difficult to determine whether the issue is related to the file itself, TV app indexing, or the TV app's metadata/artwork cache. Controlled experiment We created nine fresh files from three identical sets of TV episodes: 3 files tagged by our application (Flickis) 3 files tagged by a Python-based tagger 3 files tagged by iFlicks The same episodes were used across the three sets. The same artwork was used. All files were imported into the same macOS TV app environment. The artwork behavior was intermittent across all three groups. For example, some files initially displayed artwork and others displayed “No Artwork”. In several cases the artwork appeared later after restarting the TV app, without any modification to the media file. Container structure We also extracted the hierarchical atom structure of all nine files, without analysing payloads or attempting to interpret the results. The three pipelines produce clearly different container structures. The most notable recurring difference is: Flickis:
ftyp → moov → mdat Python tagger:
ftyp → [free] → moov → [free] → mdat iFlicks:
ftyp → free → mdat → mdat → moov Thus, the iFlicks files consistently have the moov atom after the media data, whereas Flickis and the Python tagger place moov before mdat. All three approaches contain embedded artwork (covr) and TV-related metadata. We are deliberately not assuming that moov placement is the cause. It is simply the most obvious systematic structural difference revealed by the experiment. What we would like to understand Does the macOS TV app have specific requirements or expectations regarding the container structure or metadata layout when indexing artwork for local MP4/M4V TV episodes? In particular: Does TV.app rely on a particular moov/mdat arrangement when indexing local media? Are there specific requirements for covr artwork that are not apparent from the public AVFoundation metadata APIs? Does TV.app impose requirements on the hierarchy or placement of iTunes/QuickTime metadata atoms? Are free atoms or padding relevant to artwork indexing? Is artwork indexing performed asynchronously or cached in a way that could explain artwork appearing later without the underlying file changing? Is there a recommended way to generate local MP4/M4V files that maximizes compatibility with TV.app's artwork indexing? We are particularly interested in whether there is a documented or recommended container/metadata layout for local TV episodes imported into the macOS TV app, rather than streamed or purchased content. Any guidance on the expected container structure or the TV app's indexing behavior would be greatly appreciated.

I am developing CineZoom, part of CameraControl, a remote camera-direction system (macOS app controlling an iPhone capture engine). Its core requirement is a smooth, repeatable cinematic zoom. On iPhone 17 Pro (iOS 26.5.1), using the physical Back Ultra Wide camera at 3840x2160, 60 fps, a single native ramp(toVideoZoomFactor:withRate:) from 1.7x to 2.1x over 5 seconds shows a visible stutter. I isolated it with a minimal diagnostic app (no networking) and analysed four tripod recordings frame by frame, in two locations with different lighting. The results are consistent across all four: Jitter below 2.0x: while the zoom factor is below 2.0, the image centre shifts about 2.8 px RMS between consecutive frames (peaks ~5 px), alternating almost every frame (26-28 Hz). Above 2.0x, during the same ramp at the same speed, it drops to 1.2-1.5 px. Sharpness step at 2.0x: centre-crop sharpness drops by 23-31% within a few frames exactly when the zoom factor crosses 2.0. There is no consistent effect at the reported secondaryNativeResolutionZoomFactors value (1.7838). The zoom command path itself is correct: the zoom measured from the image matches videoZoomFactor throughout, with no dropped or duplicated frames. Questions: Is this expected behaviour for the Ultra Wide camera in this zoom range? Is the jitter related to video stabilization or to how the sensor crop is positioned in this readout mode? Is there a public API that reports or controls the zoom factor at which this transition happens, so an app can plan around it? What configuration do you recommend for a smooth continuous video zoom across 1.7x-2.1x on this camera (format, stabilization mode, constituent-camera switching)? Are there existing APIs that would let an app detect or compensate this (per-frame stabilization/crop metadata, consistent processing during zoom, or a reduced-processing video stream)? I have a full technical report, per-frame measurements, charts and the original recordings, and I am happy to share them. Thank you!

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

Hello, We are seeing an issue where AVPlayer sometimes reports time values close to 95,443 seconds (~26.5 hours), even though the actual content duration is much shorter. For example, in normal cases we see: currentTime: ~355 seconds duration: 6958 seconds seekableTimeRange: 0...6958 seconds However, in some cases AVPlayer reports values around: currentTime: ~95443 seconds duration: ~95449 seconds We checked the underlying MPEG-TS segments with ffprobe. The video and audio PTS values are around 6426 seconds and are consistent with the HLS EXTINF durations, so we do not see a 95,443-second timestamp directly in the media segments. Could you please help us understand: 1- Why can AVPlayer expose values close to 95,443 seconds? 2- Could this be related to MPEG-TS PTS wrap-around or AVFoundation timeline mapping? 3- How does AVPlayer calculate currentTime and AVPlayerItem.duration for HLS MPEG-TS content? Interestingly, Audio Only / Now Playing mode shows the expected timeline, while video playback can expose the incorrect values. Thank you.

Since iPadOS 27, the 3.5 mm headphone output on iPad (9th generation) is 2.4 to 4.5 dB quieter than on iPadOS 26, depending on frequency, with the same content, system volume and headphones. It's still present in iPadOS 27.2 beta 2 (24B5089g). It isn't app-specific. It reproduces in Safari: Connect wired headphones to the 3.5 mm jack and set system volume to 100%. Open https://www.szynalski.com/tone-generator/, set 3000 Hz, set the generator volume to 50%, and play. Measure with a sound level meter. At 3 kHz we see 2.5 to 2.9 dB less on iPadOS 27 than on iPadOS 26, across three different headphone models. Audio settings are identical between the two OS versions and Bluetooth is off. The only session-level difference we found is AVAudioSession.outputLatency, which went from 97 to 65 frames. Filed as FB24980117.

Is there a supported public API on iOS/iPadOS 27 to apply SensitiveContentAnalysis to FairPlay Streaming-protected, on-demand HLS playback in AVPlayer, so that sensitive video is withheld before presentation, including after seeking or resuming, while preserving FairPlay protection? The intended behavior is on-device analysis of the actual protected presentation, with playback held until the required safety decision is available. This includes preventing the first sensitive frame from appearing and applying the corresponding audio intervention. The app must not obtain raw content keys or create a decrypted copy or clear proxy for analysis. I reviewed the public APIs and the iPhoneOS 27.0 SDK headers in Xcode 27.0 (27A266a): SCSensitivityAnalyzer's video-analysis entry point accepts a file URL; I have not found an entry point that attaches to an AVContentKeySession or a protected AVPlayerItem. SCVideoStreamAnalyzer is documented in terms of conference-call participants and incoming/outgoing streams. It accepts a capture-device input, a VTDecompressionSession, or individual pixel buffers. Its decompression-session path is documented to produce blank frames when sensitive content is detected, but I have not found a supported way to attach it to AVPlayer's FairPlay-protected decoding path. SCVideoStreamAnalyzer's initializer throws if both Communication Safety and Sensitive Content Warnings are off. Analysis would only be required when the relevant device policy is enabled. AVPlayer.h, lines 853–856, documents that allowsCaptureOfClearKeyVideo defaults to NO and has no effect on FairPlay Streaming content. I therefore cannot treat that property as a route to analyze protected frames through AVPlayerItemVideoOutput. Is SCVideoStreamAnalyzer supported for this protected on-demand use case? If so, which API connects it to the protected playback path, and what guarantees cover withholding sensitive frames and coordinating audio at initial playback, seek, and resume? If the requirement is unsupported with public APIs, confirmation of that limitation would help determine the product architecture. This is an API feasibility question based on documentation and header inspection. I do not yet have a focused reproduction project or a physical-device result, and I am not reporting a reproduced framework failure. References: https://developer.apple.com/documentation/sensitivecontentanalysis/scvideostreamanalyzer https://developer.apple.com/documentation/sensitivecontentanalysis/scsensitivityanalyzer/videoanalysishandler https://developer.apple.com/documentation/avfoundation/avplayer/allowscaptureofclearkeyvideo

On an iPhone 18 Pro running iOS 27, I’m seeing an interaction between locked frame timing and custom exposure. I configure the wide camera for 4K at 29.97 fps: input.activeLockedVideoFrameDuration = CMTime(value: 1001, timescale: 30000) With aperture and ISO fixed, I set exposure using the iOS 27 setExposureModeCustom(lensAperture:duration:iso:completionHandler:) API. A controlled comparison produced: 10 ms requested: timing lock ON → 10.000 ms; OFF → 10.000 ms. 16 ms requested: timing lock ON → 16.129 ms; OFF → 16.129 ms. 20 ms requested: timing lock ON → 16.667 ms; OFF → 20.000 ms. “OFF” means ordinary minimum and maximum frame durations both set to 1001/30000 seconds. These are exposure values from per-frame camera metadata after valid completion timestamps and a settling period. The behaviour occurs both idle and during recording. With the timing lock enabled, delivered frame timestamps show exact 30000/1001 pacing. Without it, fully manual capture measured approximately 29.964 fps. Separately, with shutter fixed at 20 ms but ISO automatic, the locked-timing configuration held 20 ms and exact 29.97. That suggests exposure ownership affects the behaviour. The documentation (https://developer.apple.com/documentation/avfoundation/avcapturedeviceinput/activelockedvideoframeduration) recommends exposure durations of half a frame or less to maintain full dynamic range, but doesn’t explicitly describe a duration clamp. Is this expected behaviour? Does fully manual exposure impose a half-frame ceiling when locked frame timing is active? Is there an API to query that effective limit? The format’s advertised exposure range includes 20 ms. Is there a supported way to retain exact fractional frame timing and a longer fully manual exposure? I can provide a minimal reproducer and device diagnostics.

Hi, I’m testing the new NowPlaying framework on iOS 27 using Xcode 27 and an iPhone 17 Simulator, and I’m seeing some behavior that I’m trying to determine is a Simulator issue or something incorrect in my implementation. I have a local AVPlayer playing an MP3 and a MediaSession conforming to MediaSessionRepresentable. The session publishes MusicContent with static artwork, AnimatedArtwork using the .tall aspect ratio, a MediaPlaybackSnapshot, and commands for play, pause, previous, next, and seek. The strange behavior is: I start playback and call requestToBecomeApplicationPrimary(). It succeeds and isApplicationPrimary becomes true, but isSystemPrimary remains false. I lock the Simulator for the first time. There is no Now Playing UI or metadata. I unlock it and return to the app. After recreating/re-registering the MediaSession and calling requestToBecomeApplicationPrimary() again, isSystemPrimary sometimes becomes true. When I lock the Simulator a second time, the Now Playing UI finally appears and the animated 3:4 artwork works correctly. However, the Lock Screen card still does not show the expected play/pause/previous/next buttons. It only shows the title, artist, progress bar, and volume control, despite those commands being included in commands. When the second session succeeds, the framework also starts requesting the artwork as expected: applicationPrimary: true systemPrimary: true Animated preview requested: (1206, 1608) ratio: tall Static artwork requested Animated video requested: (1206, 1608) ratio: tall Calling requestToBecomeSystemPrimary() directly has also consistently returned: internalFailure Playback itself continues correctly throughout all of this. So I’m trying to understand whether anyone else is seeing similar behavior with the iOS 27 Simulator: MediaSession becoming application-primary but not system-primary on the initial playback Now Playing metadata only appearing after a lock/unlock/re-registration cycle media commands being supplied but playback buttons missing from the Lock Screen requestToBecomeSystemPrimary() returning internalFailure I have not yet tested the same build on a physical iOS 27 device, so I’m particularly interested in whether this is currently a known Simulator limitation/bug or whether there is another step required when publishing a local playback MediaSession. Thanks!