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?

Hello, Apple currently does not provide any option to play MusicKit catalog videos through the standard Apple Music API nor any AVPlayer option on any platform. The only solution to play MusicKit videos is to use MusicKit on the Web through a WKWebView. This comes with a lot of constraints for developing native Apps and trying to perfectly integrate with the OS. tvOS do not support WebKit, meaning we can't use a WKWebView and MusicKit on the Web. We have no known way to develop an Apple TV App to play Apple Music videos. Is there any chance Apple will soon : integrate videos in Apple Music API ? or, at least, make WebKit at least available for use with MusicKit on the Web ? Thank you.

Does the iPhone Duo support spatial video recoding for playback on Apple Vision Pro?

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

Hello, I'm using the Get Recently Played Tracks endpoint and I need to know when each track was played. Is there a way to request a timestamp? Thanks!

Hi, I believe I have found a Core Audio regression in macOS 27. This exact hardware configuration worked correctly on macOS 26, and the issue started immediately after upgrading to macOS 27. Hardware: Mac mini M2 2 × MSI MP243X monitors Monitor 1 connected via HDMI Monitor 2 connected via DisplayPort Both monitors expose a 2-channel audio output to macOS On macOS 26: I used Audio MIDI Setup to create a Multi-Output Device containing both MSI MP243X audio outputs. Audio played simultaneously through both monitors without any issues. On macOS 27: Both audio devices are still detected correctly and both work perfectly when selected individually: HDMI only: WORKS DisplayPort only: WORKS HDMI + DisplayPort simultaneously: FAILS This is reproducible even immediately after a full reboot. When I create a new Multi-Output Device containing both MSI outputs and select it as the system output, audio playback cannot start. For example: afplay /System/Library/Sounds/Glass.aiff returns: Error: AudioQueueStart failed ('stop') I captured Core Audio debug logs while reproducing the problem. Core Audio initially reports that StartIO succeeded, but the physical display audio device then fails to establish a timeline. Relevant log messages include: HALS_IOEngine2::_StartIO succeeded Device 3669B540-0000-0000-2623-0104A5351D78 is not running. could not establish a timeline after waiting 10000000 microseconds stopping with error 1937010544 StartIOThread: the IO thread failed to start, Error: 1937010544 I have already tested the following: Both devices at 44.1 kHz / 24-bit Both devices at 48 kHz / 16-bit Recreating the Multi-Output Device from scratch Using the HDMI device as clock source Using the DisplayPort device as clock source Different drift correction configurations Restarting coreaudiod Full macOS reboot Testing both outputs individually immediately after reboot Alternative multi-device audio routing software The behavior is always reproducible. Each MSI MP243X audio endpoint works correctly by itself. The failure only occurs when both HDMI and DisplayPort audio endpoints are opened simultaneously. system_profiler correctly detects both devices at 48 kHz: MSI MP243X Output Channels: 2 Current Sample Rate: 48000 Transport: HDMI MSI MP243X Output Channels: 2 Current Sample Rate: 48000 Transport: DisplayPort This does not appear to be a problem with either monitor or connection individually, because both outputs continue to work independently. The important difference is the macOS version: macOS 26: HDMI + DisplayPort Multi-Output = WORKING macOS 27: HDMI only = WORKING DisplayPort only = WORKING HDMI + DisplayPort Multi-Output = FAILS with AudioQueueStart 'stop' / Core Audio error 1937010544 No hardware, monitor, cable, or connection changes were made between the working macOS 26 configuration and the macOS 27 configuration. This therefore appears to be a regression in the Core Audio/display-audio path introduced with macOS 27 when two display audio endpoints (HDMI + DisplayPort) are opened simultaneously. Has anyone else been able to reproduce this on macOS 27, particularly on Apple Silicon? I can provide the complete coreaudiod logs and run additional Core Audio diagnostics if needed. Additional isolation tests: Both monitors can remain physically connected to the Mac at the same time. With both HDMI and DisplayPort connected: Selecting the HDMI MSI MP243X as the only output works correctly. Selecting the DisplayPort MSI MP243X as the only output works correctly. Opening both audio endpoints simultaneously causes the failure. Therefore, simply having both displays connected does not trigger the issue. The failure appears specifically when Core Audio attempts to run both display-audio endpoints at the same time. I also tested this using third-party multi-device audio routing implementations instead of relying only on Audio MIDI Setup. The same behavior occurs: either MSI MP243X can be opened and used independently, but attempting to route audio to both devices simultaneously fails. This suggests that the issue is below the Multi-Output Device configuration itself and may be related to starting/synchronizing two display-audio IO engines simultaneously. During the failure, the Core Audio log sequence is particularly interesting: The physical device is detected normally. The audio format is configured successfully. Core Audio reports that StartIO succeeded. The device subsequently reports that it is not running. Core Audio waits 10 seconds for a timeline. Timeline establishment fails. The IO thread terminates with error 1937010544 ('stop'). One captured conversion path was: 2 ch, 48000 Hz, Float32, interleaved -> 2 ch, 48000 Hz, Int16, interleaved so both sides were operating at 48 kHz during this test. Another important observation is that restarting coreaudiod does not resolve the simultaneous-output problem. A complete reboot also does not resolve it: immediately after a fresh boot, before launching any third-party audio-routing software, both physical outputs work individually but a newly created Multi-Output Device still reproduces the failure. This makes the issue highly reproducible on this machine. Minimal reproduction: Boot macOS 27 with both MSI MP243X monitors connected. Open Audio MIDI Setup. Verify both MSI MP243X devices work independently. Set both devices to 48,000 Hz. Create a new Multi-Output Device. Select both MSI MP243X devices. Select the new Multi-Output Device as the system audio output. Run: afplay /System/Library/Sounds/Glass.aiff Expected result: The sound is reproduced simultaneously through both monitors, as it was on macOS 26. Actual result: Error: AudioQueueStart failed ('stop') Switching the system output back to either individual MSI MP243X restores audio playback. The problem can then be reproduced again by selecting the Multi-Output Device.

Hi everyone, I recently updated my MacBook Pro (14-inch, M1 Pro) to macOS 27, and I've noticed a significant drop in the built-in FaceTime HD camera quality. The video feed looks incredibly grainy and noisy, almost like it's struggling with digital artifacts, even in well-lit rooms where it used to look perfectly crisp. Here is what I've tried so far to fix it: • Restarted the Mac multiple times. • Cleaned the physical camera lens with a microfiber cloth. • Tested across multiple apps (FaceTime, Zoom, Google Meet, and Photo Booth) - the graininess happens everywhere, so it isn't isolated to just one app. The camera worked beautifully on previous macOS versions (26.x), so this definitely feels like a software processing bug or an issue with how macOS 27 handles the camera. Is anyone else experiencing this on their M1 Pro machine after the update? Are there any known workarounds, or do we just have to wait for Apple to push a supplemental software patch? Thanks in advance for any insights!

Apple please put the Walkie-Talkie app back on the WatchOS27 version

When playing TTS on a watchOS 27 device while AirPods or a Bluetooth headset are connected to both the Apple Watch and the iPhone: Playback begins by calling the setActive function of AVAudioSession. A successful response is received, but... ...AVAudioSession.currentRoute.outputs lists only the built-in speaker, with no entry for the Bluetooth headset or earphones. After a brief delay, an AVAudioSession.routeChangeNotification is received, and playback then switches to the AirPods. If TTS is stopped and playback is attempted again: Playback frequently fails. In this state, AVAudioSession.currentRoute.outputs still shows no Bluetooth headset or earphones. However, checking the Bluetooth settings on the Apple Watch confirms that the AirPods or Bluetooth headset are properly connected. If the app is restarted—or if you exit and re-enter the TTS playback screen—the first attempt succeeds (albeit with a delay), but subsequent attempts after stopping fail. Sometimes, playback fails right from the start. Even in this case, the AirPods remain properly connected. The issue is resolved if the AirPods are disconnected from the iPhone and connected solely to the Apple Watch. When connected only to the watch, AVAudioSession.currentRoute.outputs correctly includes the Bluetooth headset or earphones from the start, and playback issues do not occur when repeatedly stopping and restarting. Playback worked fine with simultaneous Bluetooth connections up to watchOS 26, but a strange issue has started occurring since watchOS 27. We suspect this is a bug or error introduced in watchOS 27; could you please fix it? The same issue persists even after the recent update to version 27.0.1. Alternatively, please let us know if there is a way to resolve this within the app itself. It seems impossible to fix this in the current code because there is no way to programmatically trigger a popup on the Apple Watch that forces the selection of a currently connected Bluetooth headset or AirPods. Also, it does not appear to be an issue with the TTS API.

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.

Hey everyone, I need to reorder a four-song Apple Music application queue while keeping the same selected occurrence, playback time, and playing/paused state. I reproduced two distinct failures in a standalone app without persistence or synchronization. I do not yet know whether these failures have a common cause. Device: iPhone 16 Pro, iOS 27.0.1 (24A446), built-in audio. Music authorization and catalog subscription checks succeed. Four distinct catalog songs resolve successfully in the Japanese storefront, in the order A, B, C, D. These letters are anonymized labels for the songs used in the measured runs; the actual catalog IDs are omitted from this public post. This does not establish that the issue occurs with every four-song selection. Repeat and shuffle are off. MusicKit reorder after a stable paused baseline Install ApplicationMusicPlayer.Queue once, starting at song D. Play once, then pause after several seconds; verify all four entries and unchanged Current/time for over ten seconds. Move the non-Current prefix in one operation: queue.entries.move(fromOffsets: IndexSet(integersIn: 0..<3), toOffset: 4) Expected: [A,B,C,D*] becomes [D*,A,B,C], retaining Current and elapsed time. RemotePlayerService instead terminates with SIGABRT during queue modification. The exception stack includes _componentsForContentItemID: and _qfa_performInsertPlaybackContext:atPosition:afterContentItemID:sectionIdentifier:actions:completion:. The client then hangs in synchronous XPC connection establishment on main. This also occurred with all app-initiated post-move SDK reads suppressed; the service report predates the first scheduled read. A direct Current move 3→0 produced a matching service exception stack in a separate run. MediaPlayer alternative fails before any reorder Using applicationQueuePlayer instead, set one MPMusicPlayerStoreQueueDescriptor for the same songs A–D with startItemID set to song D's actual catalog ID. Set repeat/shuffle off, activate an AVAudioSession playback/default session and call play once. Immediately call performQueueTransaction:completionHandler: with an empty transaction block. Completion is on main and error is nil. All queue access is synchronous inside that callback. The relevant Objective-C read order is: id raw = queue.items; NSUInteger currentIndex = player.indexOfNowPlayingItem; id current = player.nowPlayingItem; NSArray *items = raw; // raw was checked to be a nonnil NSArray NSUInteger count = items.count; for (NSUInteger i = 0; i < count; ++i) { id item = [items objectAtIndex:i]; if (!item) { /* record index and end observation */ break; } // Validate MPMediaItem and copy its nonempty playbackStoreID. } count was 4, currentIndex was 2, current was nonnil, and elements 0 and 1 validated. objectAtIndex:2 returned nil. No queue object escapes the callback. The guard ended the read with audio continuing and UI responsive. An earlier Swift queue.items.map observation crashed in Swift element dynamic casting. This newer result does not establish which song occupies returned index 2. There was no queue mutation or repeat read in this MediaPlayer trial. Both startup sequences logged "ping did not pong"; the MusicKit reorder trial subsequently reached the stable paused baseline. I cannot rule out startup's contribution. I have not established the behavior on another device/OS. Questions Is modifying entries the supported way to reorder the full application queue across Current while retaining its occurrence and continuous audio? For MediaPlayer, is a successful read-only transaction completion expected to provide a fully readable nonnull items array? Is there a documented readiness condition before enumeration that this sequence is missing? If MediaPlayer transactions are a suitable alternative, how should callers target duplicate occurrences (not just song IDs) for removal/insertion? I can provide a minimal project and the two separate failure reports through Feedback Assistant. Which component and additional diagnostics would be most useful? No Feedback ID exists yet.

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.

Android App Compatibility This app isn't 16 KB compatible. RELRO alignment check failed. This warning is showing because this is a debuggable app which is currently being tested. If you are not the developer, please report this to the developer and ask for a non-debuggable pp. This app isn't 16 KB compatible. Please follow the steps on https://developer .android.com/16kb-page-size. The following libraries are not 16 KB aligned: • lib/arm64-v8a/libappleMusicSDK.so : RELRO segment not aligned

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.

Hello, I'm building an iOS music quiz game. Players hear a song and answer a question about it, so the song itself is the content of the question, never background music. Each answer screen names the song and links to it on Apple Music. Non-subscribers would hear the catalog 30-second previews, and Apple Music subscribers the full songs through MusicKit (ApplicationMusicPlayer, with standard playback controls). Guideline 5.2.5 says previews "may not be used for their entertainment value (e.g. as the soundtrack to a game)", and the MusicKit terms say not to monetize access to Apple Music. Two questions: Is a preview that is the subject of a quiz question (not a soundtrack) an acceptable use for non-subscribers? Can such a game be a paid app or offer In-App Purchases, as long as the music is only previews or the player's own subscription? Any pointer to the right documentation or team would be appreciated. Thank you!

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.

Hello, I’m evaluating a possible MusicKit integration and would like to clarify whether the following use is permitted. With the user’s explicit and revocable consent, our iOS app would read the song currently playing in Apple Music while our app is active and display the song title and artist to other users of our application. Our app would not play, stream, host, download or redistribute Apple Music audio. Music playback would remain entirely within Apple Music. When our app is closed, it would stop accessing Apple Music. The last synchronized song may remain displayed until the user opens our app again, at which point the currently playing song would be refreshed. If a displayed song is tapped, the user would be redirected to Apple Music. We are happy to follow Apple’s required formatting, attribution and linking rules. Album artwork is not required and can be omitted if necessary. The Apple Music functionality itself would remain free. Any monetization would relate only to separate features of the application. Could someone clarify: Is this use permitted under the MusicKit / Apple Music requirements? May the current song title and artist be displayed to other users in this way? Which official Apple framework/API is recommended for detecting the song currently playing in Apple Music while our app is active? Are there specific attribution or linking requirements for this use? 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.