We develop Donuts, an AUv2 MIDI processor (aumi), using JUCE 8.0.12 on Apple Silicon. Test environment: Logic Pro 12.4 (6707), macOS 27.0.1 (26A434). Instances within one Logic project need to share an editable chord chart automatically, while retaining independent voicing/output settings. Instances in different open projects must keep separate charts, without manual pairing. Is there a supported Logic/AU API that supplies a project-scoped identity or ownership context to an AU MIDI FX instance? If not, does Logic guarantee that an AUHostingService process cannot contain live instances from different projects, including during project switching, loading and recovery? Can one project's instances be distributed across more than one hosting process? Do these guarantees depend on Logic version or hosting configuration? We completed labelled native captures on 18 October 2026 using a diagnostic observer at the AudioUnitSDK AUMethodSetProperty entry dispatcher, after the original setter returns. This includes properties handled by AUBase before the JUCE SetProperty override. It records status, selected property metadata and top-level restored state key names/types; it does not dereference opaque host client data. Automatic AU sharing remains disabled. Observed in the corrected 0.2.40 probe: Original track and duplicate in project A were both in PID 27015. Each received a different HostCallbackInfo.hostUserData value and a different ContextName. We compare process-local hashes, not dereferenced pointers. Both received all four transport callback functions; AUHostIdentifier matched within the process. No NickName assignment was observed before the captures. There were no recorded capture losses. Keeping A's project window open and opening a separate project B unloaded both A processors at 18:12:27, reaching a live count of zero. B's fresh instance loaded in PID 27146 at 18:12:50. A previous labelled project-switch test also unloaded the original processors and loaded the new project's instance in a different process. These observations do not establish a general isolation guarantee. Restored state in A contained data, jucePluginState, manufacturer, name, subtype, type and version. B was a fresh insertion with no state restore. Payload contents were not recorded. Saved plug-in IDs alone cannot distinguish ownership when tracks, presets or projects are duplicated. ContextName and hostUserData equality do not group the original and duplicate in this test. We have not established a project-ownership contract for either. The application identity also does not distinguish projects. Please advise on the supported mechanism or hosting-process ownership and lifetime guarantees for this use case. Our aim is automatic discovery without ever combining charts from different projects. Local evidence: context-evidence-0.2.40/01-original-and-duplicate and context-evidence-0.2.40/02-separate-project contain raw captures, lifecycle logs, SHA-256 hashes and observations. Nothing has been submitted externally.

I am looking for the documented observability boundary of Audio Unit version 3 MIDI output in Logic Pro. When an Audio Unit submits events through AUMIDIOutputEventBlock, is there a supported public interface or documented ordering guarantee that can establish that all events accepted for a particular output route and stopped session have been processed, with none still pending for later delivery? I mean that component's route, not unrelated tracks or every queue in the host. I have reviewed the public documentation for AUMIDIOutputEventBlock, scheduleMIDIEventBlock/AURenderEvent, render observers, transportStateBlock, contextPresentationLatency, tailTime, and AUMessageChannel. I have not found a route-completion acknowledgment. A successful submission callback, stopped transport, received event list, or finite silent recording seems to describe a different observation point from completion of all pending delivery. Does Logic support a documented AUMessageChannel protocol or other public mechanism for this purpose? If so, which Logic/macOS versions support it, what is the completion notification's scope and clock domain, and what are its ordering and caller-thread requirements? In particular, does it remain available if transport stops and no final render callback occurs? If receiving every expected event at a downstream Audio Unit can establish completion instead, what documented guarantee rules out later delivery or duplicates from the same stopped session? Instrument processing, effects tails, and actual hardware playback are separate observation boundaries; I am not treating their completion as implied by MIDI receipt. Confirmation that this internal state is not exposed by a supported public interface would also be useful. This is an API-capability question, not a report of an observed Logic defect. I am not seeking private APIs, confidential implementation details, queue flushing, process instrumentation, virtual drivers, or audio-device reconfiguration. No project source, logs, recordings, or account information are included.

We all know the state of MusicKit SDK for Android is catastrophic - it's buggy, it's lacking features and it has not been updated in ages. It's sad though, as on Android there is (and this came as quite a surprise to me) no real alternative if you want to build an app with music content from a streaming service. So why, really why, does Apple not do anything in this area? Just give us an updated version of the SDK and we can continue on building apps that work on iOS and on Android.

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!

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

Hi all,  Apple dropping on-going development for FireWire devices that were supported with the Core Audio driver standard is a catastrophe for a lot of struggling musicians who need to both keep up to date on security updates that come with new OS releases, and continue to utilise their hard earned investments in very expensive and still pristine audio devices that have been reduced to e-waste by Apple's seemingly tone-deaf ignorance in the cries for on-going support.  I have one of said audio devices, and I'd like to keep using it while keeping my 2019 Intel Mac Book Pro up to date with the latest security updates and OS features.  Probably not the first time you gurus have had someone make the logical leap leading to a request for something like this, but I was wondering if it might be somehow possible of shoe-horning the code used in previous versions of Mac OS that allowed the Mac to speak with the audio features of such devices to run inside the Ventura version of the OS.  Would it possible? Would it involve a lot of work? I don't think I'd be the only person willing to pay for a third party application or utility that restored this functionality. There has to be 100's of thousands of people who would be happy to spare some cash to stop their multi-thousand dollar investment in gear to be so thoughtlessly resigned to the scrap heap.  Any comments or layman-friendly explanations as to why this couldn’t happen would be gratefully received!  Thanks,  em

I am a private individual working on a personal panorama viewing and reprojection project. I have been investigating the geometry of panoramas produced by the iPhone Camera app, with extensive analytical and research assistance from OpenAI's ChatGPT. My goal is to determine the physical viewing direction (longitude and latitude, or equivalently a 3-D viewing ray) corresponding to each pixel in a finished iPhone panorama. I have been able to recover much of this geometry from information contained in the panorama itself. Controlled tests on several iPhone models indicate that I can accurately determine the effective focal length of the perspective source camera, camera rotation during capture, endpoint geometry, horizontal field of view, and gravity-relative camera orientation. The remaining problem is the absolute vertical/latitude mapping in the finished panorama. The gravity/orientation information allows me to determine where a known physical latitude—for example, the true horizontal plane (0° latitude)—falls in the individual source-camera frames. However, I have not found a documented way to determine exactly where those source-frame viewing rays are placed vertically in the final panorama bitmap. My investigation suggests that the Camera app performs additional geometric processing during panorama assembly, including geometric/perspective correction and the selection, cropping and/or rotation of image slices before they are blended into the panorama. What I have not been able to determine is whether the information needed to reconstruct that source-ray-to-finished-pixel mapping is retained anywhere in the finished panorama or is available through a supported Apple API. My primary question is therefore: Is there a documented or supported way to determine the physical viewing ray corresponding to each pixel in a panorama produced by the iPhone Camera app, including its absolute vertical/latitude mapping? More specifically: Is the projection used for the finished Camera panorama documented? Is the gravity-relative orientation or vertical reference of that projection available through supported metadata or an API? Is sufficient information retained in the panorama to reconstruct the geometric correction and placement applied to source images/slices during panorama assembly? If that information is not retained in the finished image, is there another supported framework or API that provides it during or after panorama capture? I am not trying to reproduce Apple's image blending or other proprietary image-processing algorithms. I simply want to interpret the geometry of the finished image accurately enough to reproject it—for example, to cylindrical or equirectangular coordinates—and assign physical longitude and latitude to its pixels. I have controlled test panoramas from multiple iPhone generations and considerably more technical detail about the investigation. I would be happy to provide example files, measurements, or additional information if that would be helpful. Even confirmation that the required vertical-placement information is not retained or exposed would be very useful.

The documentation for AVAudioSession.Mode.measurement says that this mode will "minimize the amount of system-supplied signal processing to input and output signals" https://developer.apple.com/documentation/avfaudio/avaudiosession/mode-swift.struct/measurement Is there any documentation regarding specifically what processing is applied in the .default or .videoRecording modes and how it is different in .measurement mode? If my app adds its own signal processing, is it best practice to always use .measurement mode? What should I use for an app that applies its own signal processing to the audio in a video recording? Is it possible to "minimize system-supplied signal processing" while recording a video?

Our iOS app plays Apple Music catalog videos using MusicKit JS v3 in WKWebView. We use a WebView, with the current video visible. Tests are on an iPhone 16e running iOS 26.6.2, built with SDK 27.1. Inline playback and PiP are allowed, background audio is enabled, and the system’s automatic PiP setting is on. A real button click calling video.requestPictureInPicture() successfully opens PiP, which continues playing when returning to the Home Screen. However, leaving the app without opening PiP manually produces audio only. We tested both public video PiP APIs, including an early request from UIScene.willDeactivateNotification. In the latest trace, AVKit reports a visible, supported and eligible source, then reads ForegroundInactive and immediately reports “Failed to start picture in picture.” The video briefly reports PiP mode before returning inline; no PiP window appears. Our WebKit audio session also changes from ambient to auto on deactivation; its contribution has not been isolated. Is automatic inline PiP supported for MusicKit JS videos in WKWebView? Is there a supported configuration or initialization hook to prepare it while the scene is still active? We do not own WebKit’s underlying controller to set canStartPictureInPictureAutomaticallyFromInline. What lifecycle and audio-session setup does Apple recommend? If this behavior is unexpected, which minimal reproduction and diagnostics would help DTS investigate?

With a joined PTChannelManager channel and setAccessoryButtonEventsEnabled(true) completing successfully, what supported condition makes a classic Bluetooth headset's AVRCP Play event start PTT transmission instead of routing to a media app? The headset microphone and physical Stop button work. The next physical Start press produces no didBeginTransmittingFrom callback, while an on-screen Start request works again. Tested environment Observed on 3 October 2026: iPhone 13 Pro Max, iOS 26.6.1. Xcode 26.6, macOS 26.5.2. boAt Rockerz 255 Pro+, classic Bluetooth A2DP/HFP. Push to Talk capability, microphone permission, and audio/push-to-talk background modes enabled. Default half-duplex transmission mode and Ready service status retained. Isolation and setup The reproduction uses an independent UIKit controller initialized before the host app runtime. No React Native, Expo audio module, Live Activity, MPRemoteCommandCenter, Now Playing metadata, audio player, transcription, or backend participates. The controller retains its channel manager, leaves a restored channel before joining a fresh channel, and enables accessory button events in didJoinChannel. The revised test configures the audio session at launch, before manager initialization: let session = AVAudioSession.sharedInstance() try session.setCategory(.playAndRecord, mode: .voiceChat, options: [.allowBluetoothHFP]) The relevant join callback is: func channelManager(_ channelManager: PTChannelManager, didJoinChannel channelUUID: UUID, reason: PTChannelJoinReason) { channelManager.setAccessoryButtonEventsEnabled(true, channelUUID: channelUUID) { error in // The test logs successful completion here. } } PTT owns audio activation/deactivation; the diagnostic never calls setActive. In didActivate, it reapplies the same category/mode/options, clears a speaker override, selects an available HFP input, waits for the route to settle, and starts an AVAudioEngine input tap. It verifies HFP input/output and incoming frame counts; samples are discarded. It removes the tap and stops the engine on Stop/deactivation. The full focused sample was already supplied privately to DTS. Its controller was tested on the physical phone through the native-only launch path. The standalone Xcode project packaging passed an unsigned iPhoneOS build, but has not independently been installed on the phone. Reproduction Connect the headset, launch the diagnostic, grant microphone permission, and join a fresh PTT channel. Confirm that enabling accessory events succeeds. Tap on-screen Start, which calls requestBeginTransmitting(channelUUID:). Wait for HFP input/output and incoming audio frames to be verified. Press and release the headset multifunction button. The delegate reports didEndTransmittingFrom with handsfree/headset source (raw 3); PTT deactivates audio and the channel remains joined. Press and release the same headset button again. Expected: PTT begin callback and microphone activation. Observed: no begin callback; Console shows AVRCP Play routed to Music. Tap on-screen Start again: transmission works. Headset Stop works again. Selected evidence The revised launch-configuration test produced this native trace on 3 October (UTC): 04:32:10 launch: native-only; launch audio configuration v2 04:32:10 category=PlayAndRecord; mode=VoiceChat; options=4 04:32:11 fresh channel joined 04:32:11 accessory mapping accepted 04:32:19 app start requested 04:32:19 BEGIN source=2 04:32:20 available inputs=MicrophoneBuiltIn,BluetoothHFP 04:32:20 discard engine running 04:32:21 HEADSET VERIFIED: BluetoothHFP input/output; frames=4096 04:32:22 END source=3 04:32:23 audio deactivated No physical-headset BEGIN appeared in the native event snapshot copied at 04:32:49 UTC. Selected Console observations from the same run, converted from IST to UTC: 04:32:30.529053 AVRCP Play routed to com.apple.Music 04:32:30.535720 Music launch failed: NotFound 04:32:35.852134 the same command timed out after 5.326288 seconds Music had been removed during troubleshooting. Before removal, the user observed Music opening; the supplied timestamped excerpts were captured after removal. Removal explains the launch failure, but does not explain why the joined PTT channel is bypassed. An earlier native-only fresh-channel control also showed Play routing to Music before any app-requested transmission, with no BEGIN or audio activation in the callback trace. That earlier control configured the category in didActivate; it was not a fresh-start test of the revised launch-configuration variant. The revised test above establishes that configuring the category at launch did not fix the post-Stop failure. Questions I reviewed the accessory mapping explanation in https://developer.apple.com/forums/thread/804205 and the launch audio configuration guidance in WWDC22 session 10117. Is a discrete AVRCP Play command from this type of consumer headset supported for PTT Start in this state, or is a different command form required? Does the playback-mode qualifier in that forum guidance require an additional supported setup step? Could the category/route sequence described above bypass accessory mapping despite successful completion? What targeted diagnostic or controlled configuration would distinguish accessory-command compatibility from an iOS routing defect? The observations establish a routing/callback mismatch in this tested configuration; I am not assuming an iOS defect or that the headset is unsupported.

As a reminder, the recommended approach to monitor camera rotations, including on upcoming hardware, is to use the AVCaptureDevice.RotationCoordinator / AVCaptureDeviceRotationCoordinator API. In many common scenarios on iPhone Duo, proper use of the rotation coordinator is the only way to ensure that your camera previews and captures use the orientation expected by the user. AVCaptureVideoOrientation has been deprecated as of iOS 17.0 and iPadOS 17.0. When switching cameras in your app, make sure to create a rotation coordinator for that device. To ensure that your app has implemented the rotation coordinator API correctly, you should test different orientations and sizes of your app on an iPad with Stage Manager enabled. Additional information: Sample Code: Supporting device rotation in your camera app Tech Talk: Build a great camera experience for iPhone Duo WWDC23 session: Support external cameras in your iPadOS app

Hello, I need guidance on diagnosing an intermittent audio failure on an iPhone 12 running iOS 26.6.2. My app, Timer Workout Fitness, plays short bundled MP3 voice recordings for countdowns, repetition numbers and workout announcements. It uses React Native / Expo SDK 57 and expo-audio. The native playback implementation uses AVQueuePlayer, AVPlayerItem and AVURLAsset. Users can listen to Spotify while the app plays spoken cues, with ducking of the background music. Observed behavior: Playback can work correctly for an entire workout. Audio sometimes fails after background/foreground transitions, pausing Spotify, or completing one workout and starting another. The exact sequence is not consistently reproducible. The app may remain navigable while recorded audio becomes unavailable. Force-quitting does not always restore reliable playback. Restarting the iPhone has restored it in our tests. Speech-based voices have generally behaved more reliably before the failure. Evidence from a device Console capture: At 15:03:35 on October 12, the kernel reported termination of audiomxd with reason "per-process-limit" and a recorded footprint of 66866 KB. ReportSystemMemory confirmed the jetsam termination. Shortly before this, the Console contained AudioConverter construction messages associated with our app through mediaplaybackd. Our app subsequently reported media-services loss/reset and errors including: "Server was dead" OSStatus 1836282486 We have not established whether our playback implementation causes an accumulation of native resources, a temporary peak, or another issue. We do not assume that this is an iOS defect. The implementation originally retained up to 56 players for individual recordings and loaded them concurrently. We recently changed it to load only the recordings required by a workout: 15 players for 10 repetitions and 35 for 30 repetitions. Failures have still occurred in development testing, but we have not measured the corresponding native memory footprint. We also have a custom native patch affecting activation/deactivation and handling of media-services loss/reset. Current Expo Go tests do not include that patch; our TestFlight builds do. We can provide the patch for review. What is the recommended way to: Attribute audiomxd memory usage to our app’s playback resources? Verify that AVQueuePlayer items and associated decoding resources are released? Capture useful diagnostics for this service termination? Choose an appropriate playback architecture for frequent short local voice clips alongside background music? We have device Console logs and application diagnostic traces. We do not yet have a minimal native Xcode reproduction project and would appreciate guidance on what it should include.

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 am testing an audio-only MediaDeviceExtension on an iPhone 17 Pro, with Xcode 27.0 (27A266a). The same application build reproduces this on iOS 27.0 (24A437), after a full reboot, and on iOS 27.0.1 (24A446). The extension advertises .realtimeAudioStreaming, one stable device UUID and a reachable, nonzero-port endpoint. It connects to the receiver before reporting activatedDevice. From startRealtimeSampleDelivery(session:), it calls AudioServerPlugInRegisterMediaDeviceExtension. The plug-in exposes one output device with the same UID and kAudioDeviceTransportTypeRemoteStreaming. The driver interface lives for the extension process and is registered on each delivery start. Stop/deactivation closes the transport and stops forwarding samples; it does not terminate the extension or register a null interface. Reproduction: start audio, select the extension's route, confirm audio flows, switch to iPhone Speaker, then reselect the same route while the source keeps playing. First selection works; subsequent selections briefly deliver audio before reverting to Speaker with AVOutputContextDeviceConnectionFailureReasonMDERouteRevertedToLocal. Pausing the source before route selection, waiting five seconds and resuming worked repeatedly in the same extension process; uninterrupted reconnection is the required behavior. The normal test uses Spotify and a separate receiving app. A diagnostic control on iOS 27.0 also reproduces first-success/reconnect-failure using a native AVAudioPlayer PCM source and a separate Mac receiver that counts/discards the samples. That control has no Spotify, DSP processing, local receiver playback session or same-phone transport endpoint. Stored device logs on 27.0.1 show two failed reconnects: Observation Reconnect 1 Reconnect 2 System policy chooses fallback before startRealtimeSampleDelivery 11.103 ms earlier 26.956 ms earlier MusicVAD reported present after fallback decision 364.019 ms later 409.215 ms later Driver registration result OSStatus 0 OSStatus 0 New captured frames before system stops delivery 52,224 47,104 Time from fallback decision to Speaker selection 1,507.218 ms 1,507.904 ms The policy logs identify the active, non-video source as not supporting the extension's protocol, then attempt AirPlay fallback. On the first successful connection, MusicVAD is already present and the policy explicitly permits that same source. On reconnect, successful driver publication and subsequent I/O do not cancel the earlier fallback decision. Transport reports show zero drops and socket errors; StartIO/StopIO counts balance, the stream-active setter is honored, and callback session IDs match. No registration interruption is captured during these attempts. Creating a media device extension directs publication from startRealtimeSampleDelivery. The registration API describes the interface, UID and transport requirements, but I have not found the supported teardown/re-registration contract for this retained-process case. Between stopRealtimeSampleDelivery / deactivation and the next delivery start, should the extension retain and re-register the same driver interface, recreate it, or withdraw the audio device through a documented operation? How should an audio-only extension using the documented publication callback ensure the system's compatibility check waits for its audio device? Is there a supported readiness or completion signal that the implementation must provide? The evidence identifies an ordering difference; I am not assuming it proves an OS defect. Guidance on the required lifecycle, or a reference implementation demonstrating uninterrupted reconnects, would help isolate the remaining driver-versus-system boundary.

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 trying to play consecutive Apple Music videos in Picture in Picture from a native iOS app. Our minimal reproduction uses one WKWebView, one MusicKit JS v3 instance and one preloaded queue. There are no parallel players or transitions implemented by our app. Setup: Inline playback enabled; allowsPictureInPictureMediaPlayback reads true. UIBackgroundModes includes audio. Initial PiP is opened through a user gesture and works correctly. Reproduced on iOS 26.6.2 and iOS 27.0; failure details vary between runs. await music.setQueue({ musicVideos: ["1445284008", "1258705880", "290361007"] }); await music.play(); The user opens PiP, goes to the Home screen and lets the first video finish naturally. At the queue boundary, MusicKit replaces its HTMLVideoElement. The existing PiP window closes, and the next video does not inherit the presentation. We also tested requesting PiP once on the new element, after it becomes ready, including a variant waiting for playing. In affected background runs, the element briefly reports the WebKit PiP mode, then receives leavepictureinpicture without enterpictureinpicture. The standard requestPictureInPicture() promise remains pending during observation. Native logs report a failed new PiP start while the source scene is backgrounded. The equivalent explicit handoff succeeds in the foreground. In one background configuration, the next video continued audibly, while the PiP window still closed. Explicit native playback audio-session configuration did not resolve the continuity issue. Is there a supported way to: Preserve the underlying media element/PiP presentation across MusicKit queue items? Transfer an existing PiP session to the replacement element while backgrounded? Obtain a reliable error or rejection when native PiP startup fails but the JavaScript promise remains pending? We can provide a minimal reproducer and correlated JavaScript/native logs.

Our music player plays library and Apple Music catalog content with MusicKit's ApplicationMusicPlayer. On the Mac, we want a volume slider that changes only our app's playback level, like the slider in Music.app. We found no supported way to do this: ApplicationMusicPlayer and MusicPlayer have no volume property. The audio plays in com.apple.MediaPlayer.RemotePlayerService, not in our process, so we cannot change the stream level. MPVolumeView and the deprecated MPMusicPlayerController.volume control the system output volume, not the app's level. AVPlayer cannot play Apple Music catalog content. Questions: Is there a supported API to set the playback volume of ApplicationMusicPlayer on macOS or Mac Catalyst? If there is none, what does Apple recommend for Mac apps that need an app-level volume control for MusicKit playback?

We are developing a voice call application that uses AVRoutePickerView, allowing users to switch between an iPhone, a speaker, and Bluetooth earphones. However, we have encountered an intermittent issue: when switching from the speaker to Bluetooth earphones, the earphones remain in a loading state, and the audio channel subsequently switches back to the speaker. How can we resolve this issue? Here is the sample code: let session = AVAudioSession.sharedInstance() do { try session.setCategory(.playAndRecord, mode: .default, options: [.allowBluetooth]) try session.overrideOutputAudioPort(isBluetoothConnected ? .none : .speaker) try session.setPreferredSampleRate(48000) try session.setPreferredIOBufferDuration(0.02) try session.setActive(true, options: []) INFO(" >>> start: hasBluetooth=\(isBluetoothConnected), inputs: \(session.currentRoute.inputs.map { $0.portType }) outputs: \(session.currentRoute.outputs.map { $0.portType })") } catch { ERROR("(error.localizedDescription)") }

Hello Apple Support, I am experiencing a reproducible Continuity Camera issue on my Mac mini M4 running macOS 27. Problem description My iPhone 17 works as a Continuity Camera when a USB webcam is connected to my Mac mini. However, when I disconnect the USB webcam, the iPhone disappears as an available camera from all applications, including FaceTime and OBS. The issue appears to be related to how macOS publishes or registers the Continuity Camera device, rather than the Mac being unable to discover the iPhone. I would like to use my iPhone 17 as a wireless Continuity Camera without having to keep a USB webcam connected. System information Mac: Mac mini M4 Operating system: macOS 27 iPhone: iPhone 17 Third-party application tested: OBS Apple application tested: FaceTime Troubleshooting performed I have already tried the following: Verified that the iPhone is detected by macOS using: system_profiler SPCameraDataType The output lists both devices: WEB CAMER: Model ID: UVC Camera VendorID_19530 ProductID_19029 iPhone 17 Camera: Model ID: iPhone18,3 Unique ID: CA29F0DB-099C-4589-AF19-CE9500000001 Checked the relevant Continuity and camera processes: launchctl list | grep -Ei 'continuity|camera|avconference|cameracapture' The output included: com.apple.mediacontinuityd com.apple.cmio.ContinuityCaptureAgent com.apple.ptpcamerad com.apple.videoconference.camera Inspected the Continuity Capture agent using: launchctl print gui/$(id -u)/com.apple.cmio.ContinuityCaptureAgent The agent was running, with PID 652. Inspected mediacontinuityd. It was initially not running in the user GUI session: state = not running runs = 0 Attempted to restart the Continuity Capture agent: launchctl kickstart -k gui/$(id -u)/com.apple.cmio.ContinuityCaptureAgent macOS returned: Could not kickstart service "com.apple.cmio.ContinuityCaptureAgent": 150: Operation not permitted while System Integrity Protection is engaged Attempted to refresh the Continuity service: launchctl kickstart -k gui/$(id -u)/com.apple.mediacontinuityd The command completed without an error, but the issue remained. Attempted to refresh device discovery: sudo killall -HUP rapportd This did not resolve the issue. Checked for camera helper processes: killall VDCAssistant killall AppleCameraAssistant Neither process was found under my user account. Checked the system logs: log show --last 2m --style compact --predicate 'process == "ContinuityCaptureAgent"' 2>/dev/null | grep -E 'magic:|skip headless|present' | tail -8 The logs repeatedly show that the iPhone is discovered, but its camera is not published. Relevant log messages: Device ... name iPhone 17 present magic:0 (usable:0 nearby:1 wired:0 skipNearByCheck:0) reported magic:0 skip headless device publishing in non magic, non wired state These messages appear repeatedly while the iPhone is detected over Rapport. Restarted the Mac and tested with the USB webcam disconnected. The problem persisted. Tested the iPhone in different physical positions and orientations. This did not resolve the issue. Confirmed that the iPhone disappears from FaceTime and OBS when the USB webcam is disconnected. Expected behaviour The iPhone 17 should remain available as a wireless Continuity Camera when the USB webcam is disconnected. Actual behaviour The iPhone is discovered by the Continuity Capture agent, but the logs show: skip headless device publishing in non magic, non wired state The iPhone camera disappears from all applications when the USB webcam is disconnected. Connecting the USB webcam makes the iPhone camera available again. Questions for Apple Engineering Is this a known issue in macOS 27 affecting Mac mini M4 or other Macs without a built-in camera? What does skip headless device publishing in non magic, non wired state mean in this context? Why does ContinuityCaptureAgent discover the iPhone but refuse to publish it as an available camera? Is there a supported way to refresh or re-register the Continuity Camera service without disabling System Integrity Protection? Is there a known workaround or a planned fix for this issue? I would appreciate help identifying the underlying cause and a permanent solution that allows Continuity Camera to work wirelessly without a USB webcam connected. Thank you.

On an iPad Pro 11-inch (M4) running iPadOS 27.0 (24A437), ScreenCaptureKit delivers a maximum of 60 frames per second when capturing the entire screen, even while an app is rendering at 120 fps (confirmed with the Metal Performance HUD). What I tested: Default configuration: exactly 60 fps, with every frame timestamp spaced 16.67ms apart. Setting minimumFrameInterval to 1/120 and queueDepth to 8, both before starting the stream and through updateConfiguration after it started: the values are accepted and read back correctly, but delivery stays at exactly 60 fps. Smaller output sizes (1/4 and 1/8 of native resolution): still 60 fps. ReplayKit broadcast upload extension: also exactly 60 fps. Also, minimumFrameInterval and queueDepth are documented as available on iOS/iPadOS 27, but the iOS 27 SDK marks them as unavailable. Request: please allow ScreenCaptureKit to capture at the display's full refresh rate (up to 120 fps) on ProMotion devices when minimumFrameInterval asks for it, and make minimumFrameInterval available in the iOS SDK.