We're building a simple iPhone app that shows a live view from the rear camera in Picture in Picture while the user is in other apps. The camera feed is only displayed. It's never recorded, stored or transmitted, and the app has no network access. In testing on an iPhone 15 Pro (iOS 26.6.2) with Xcode 26.6, the camera keeps running behind PiP only when the app declares the voip background mode. Without it, as documented, isMultitaskingCameraAccessSupported is false and the capture session is interrupted with videoDeviceNotAvailableWithMultipleForegroundApps as soon as PiP starts. Our app isn't a calling app, so we don't want to rely on voip. Two questions: Is the com.apple.developer.avfoundation.multitasking-camera-access entitlement available to non-calling apps with a use case like this? If so, how should we request it? If not, is there any supported way for a non-calling app to keep a live camera preview running in PiP on iPhone? I'm happy to share a short screen recording of the prototype.

We are developing an iOS app that plays individual prerecorded spoken-audio files in response to background triggers. The user explicitly enables this functionality while the app is in the foreground. Subsequently, playback may need to start while the app is backgrounded or the device is locked, with silent intervals between files. For this question, please assume that the app is legitimately executing in the background when a trigger arrives. We are not asking how to wake a suspended app or keep it running artificially. Desired behavior Temporarily interrupt other media playback while an audio file is playing. Release the audio session afterwards, allowing the other app to resume. Repeat this for subsequent triggers without requiring foreground interaction. We do not need to override phone calls, Siri, or other higher-priority system audio. Current configuration try session.setCategory( .playback, mode: .voicePrompt, options: [.duckOthers, .interruptSpokenAudioAndMixWithOthers] ) try session.setActive(true) After playback finishes: try session.setActive( false, options: .notifyOthersOnDeactivation ) This provides ducking for other music playback. However, we would prefer non-mixing playback during each file. We are considering .playback with .spokenAudio and no mixing options, but Apple's documentation describes cannotInterruptOthers when attempting to activate a non-mixable session from the background. Questions Is there a supported audio-session lifecycle that allows this intermittent, non-mixing background playback after the user initially enables the feature in the foreground? If we deactivate the session between files, does the background activation restriction apply again to every subsequent file, regardless of the earlier user interaction? Does implementing a CarPlay audio app with the appropriate entitlement change these restrictions? In particular, is there a distinction between playback explicitly initiated through the CarPlay interface and later background-triggered playback? If this behavior is not supported, is ducking/mixing the recommended approach for this use case? We want to use public APIs and avoid silent playback or retaining an active audio session solely to prevent other apps from playing. Any clarification on the intended behavior and recommended configuration would be appreciated. Thank you for your time and guidance! regards, Carsten :-)

Hello, I am developing a non-commercial, web-based music intro quiz using MusicKit on the Web and Apple Music. Before proceeding with development and potentially making the application publicly available, I would like to clarify whether the following implementation complies with Apple’s MusicKit and Apple Music terms. Planned implementation: Each participant authenticates with their own Apple Music account and must have an active subscription. Music is streamed directly from Apple Music to each participant’s device through MusicKit. My server only sends Apple Music song IDs and playback control messages. No audio files are downloaded, stored, modified, redistributed, or transmitted through my server. When the host starts a question, the application triggers playback on each participant’s device. Playback automatically stops after approximately five seconds, allowing participants to guess the song. The application is initially intended for private, non-commercial use with approximately 5–10 participants. I may eventually make it publicly available for online multiplayer sessions. My questions are: Is it permitted for a host to remotely trigger MusicKit playback on other participants’ devices, provided each participant has authenticated with their own Apple Music account? Does automatically stopping playback after approximately five seconds violate any MusicKit playback requirements? Is using Apple Music playback as part of a music identification quiz or game permitted? Would sending song IDs and playback commands to multiple devices be considered prohibited synchronization of Apple Music content, even though each device streams the audio independently? If this implementation is not permitted, would requiring each participant to manually initiate playback make the application compliant, assuming all other requirements are satisfied? Are there any additional licensing requirements or permissions necessary before making this type of application publicly available? I understand that MusicKit has requirements concerning user-initiated playback, standard playback controls, and synchronization with other content. I would particularly appreciate clarification on how these requirements apply to this use case. If this forum is not the appropriate place for questions about MusicKit licensing and permitted use, could someone please direct me to the appropriate Apple team or contact point? Thank you for your time and guidance.

Hello, I am building a Windows desktop application that lets users migrate their own playlists between music services. Apple currently documents automatic Music User Token management for Apple platforms and web apps, and manual token management for Android. I could not find a documented native Windows authorization flow. My proposed architecture is: Windows desktop app → system browser → MusicKit on the Web authorization → return authorization to the same Windows desktop app. The desktop app would then call Apple Music API directly using a developer token issued by my backend and the user authorization obtained through MusicKit. My questions are: Is there a supported way for a Windows desktop app to obtain a Music User Token through MusicKit on the Web and then use that token from the desktop process? Is handing the token back from the browser to the same Windows device supported? If yes, is there a recommended handoff mechanism or lifecycle/refresh guidance? Is secure local storage of that Music User Token on Windows supported? I am not asking about playback. The intended usage is only reading the user’s playlists and creating playlists through Apple Music API. The Media Services private key would remain server-side and would never be shipped with the desktop application. Thank you.

I am building a personal iPhone prototype with an on-screen record platter. Before enrolling in the Apple Developer Program or developing the Apple Music integration further, I would like to establish whether the core interaction is supported by public APIs. The intended interaction is: Tap the platter to play or pause an Apple Music subscription song. Hold the platter to stop playback at its current position. Move the platter forward or backward to control the direction and speed of audible playback continuously. Change pitch together with speed, like a physical record, rather than preserving the original pitch. Release the platter to smoothly return to normal playback. Hold a separate control to listen continuously at a faster speed. A prototype using an AVAudioEngine-based renderer works with unprotected local audio. I have NOT verified these behaviors with Apple Music subscription content. I understand that this local renderer does not establish feasibility for MusicKit, and I am not seeking to extract protected audio or bypass content protection. MusicPlayer.State.playbackRate is documented as settable, with positive values for forward playback and negative values for reverse playback: https://developer.apple.com/documentation/musickit/musicplayer/state-swift.class/playbackrate For ApplicationMusicPlayer on iOS, is this vinyl-style interaction supported for full Apple Music subscription songs, rather than previews or user-owned unprotected files? In particular: What playback-rate range is supported for subscription songs? Do negative rates produce audible reverse playback, and how should zero-speed holding be implemented? Is there a documented public API to make pitch follow playback speed, or to disable pitch preservation? Are frequent rate and direction changes supported for interactive scratching? Are there documented limitations on update frequency, buffering, seeking precision or responsiveness? If this interaction is outside public MusicKit capabilities, is there an official channel where an individual developer can ask about eligibility for an approved Apple Music DJ integration? I am asking for the supported API path and its limitations, not implementation details of another app. If only ordinary variable-speed playback or seeking is supported, a clear distinction from continuous vinyl-style scratching would be very helpful. The initial goal is personal use; possible App Store distribution is undecided. I have an active Apple Music subscription but am not currently enrolled in the paid Apple Developer Program. Thank you.

For an AUv3 plug-in of type kAudioUnitType_MIDIProcessor how is the plug-in supposed to figure out the sample rate of the host? I think this might be an API limitation. For instruments and effects, we can read the AUAudioUnit's output bus format and check the sample rate. But MIDI FX plug-ins have no audio I/O. And even if I set them, Logic Pro, for example, doesn't update the AU if I change the sample rate in Logic. Looking at AVAudioSession.sharedInstance.sampleRate doesn't work either, because the host can have a different sample rate from the hardware. Is there a solution to this that I'm not aware of?

Question: Camera Permission Reset and NSInternalInconsistencyException on iOS 26 We’ve recently started seeing an issue in our production app: NSInternalInconsistencyException "Call must be made on the main thread" We were able to reproduce the issue by manually revoking/resetting the Camera permission so that its state changes back to notDetermined. This raises a few questions: Does iOS 26 automatically revoke or reset previously granted permissions in certain scenarios? Has Apple introduced any changes to the permission or privacy policy in iOS 26? Is there any known behavior where an existing Camera permission can unexpectedly return to the notDetermined state after an OS update? Has anyone else encountered a similar issue in production after updating to iOS 26? We couldn’t find any clear or recent documentation from Apple that explains a change in this behavior. Has anyone experienced this issue or found any relevant Apple documentation explaining the permission-state changes in iOS 26?

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?

In the old simulator you were able to simply drag a photo or video from your desktop into the photos app within the simulator in order to use it for testing. That doesn't seem to be working yet in Device Hub. Is there a workaround or are we just waiting on this to be fixed?

I'm building a podcast app (AVPlayer, .playback + .spokenAudio). When the user asks Siri a non-media question, such as "What is the capital of France?", our audio pauses as expected. But the interruption-ended notification with .shouldResume, and on iOS 27 the resumption recommendation, arrive only when the user dismisses Siri's answer card. If the card is left up, we stay paused indefinitely. Under the same conditions (same device, same question, card left up), these apps resume within a few seconds while the card is still visible: Apple Music Apple Podcasts Pocket Casts (its log shows interruption-ended with shouldResume 3–7 s after began) Overcast Our app, installed through TestFlight, and a minimal AVPlayer sample both wait for dismissal. What we've ruled out (each changed one variable, no effect): Mode .spokenAudio vs .default (with .default, playback continues but stays ducked until dismissal) Route-sharing policy .longFormAudio vs .default AVPlayer vs AVAudioEngine Calling pause() on interruption vs letting AVPlayer pause itself Now Playing registration on or off Calling setActive(false) 5 s after the interruption began SiriKit: Siri capability plus in-app INPlayMediaIntent handling (Siri found the app and started playback through our handler; no change) Our app responds within 0.05 s once the signal arrives, so the delay is entirely in delivery. AVAudioSession.promptStyle reads .short from Siri's answer until dismissal, then returns to .normal at the same moment our end notification arrives. Seen on iPhone with iOS 27.0 and 27.0.1, and on iPad with iPadOS 26.6, so it isn't new in iOS 27. Questions: What determines whether an interrupted session receives interruption-ended while Siri's answer card is still visible? Is this related to App Store vs TestFlight/development distribution, or is there something an app needs to adopt? A focused sample project is available. I also have an open DTS case on this.

Hello, I am an undergraduate student working on a non-commercial university capstone project. I would like to clarify whether it is permitted to: Temporarily stream the 30-second preview audio provided through the iTunes Search API and process it in memory using the Essentia audio analysis library to extract numerical audio features. Store only the extracted numerical audio features (such as BPM, key, energy, and timbre) in a database, while immediately discarding the original preview audio after analysis. Could you please confirm whether this use of the previewUrl is permitted under Apple's terms and guidelines? Thank you.

I want to hide only the Cancel button of a modally presented SwiftUI PhotosPicker, so I'm using .photosPickerDisabledCapabilities(.selectionActions) with the default selection behavior: .photosPicker(isPresented: $isPresented, selection: $selection, maxSelectionCount: 5, matching: .images, photoLibrary: .shared()) .photosPickerDisabledCapabilities(.selectionActions) Cancel goes away as expected, but Add (the checkmark) stops working. Tapping it does nothing, the picker stays up and isPresented never becomes false. Pulling the sheet down doesn't close it either, so there is no way out of the picker. Without the modifier, Add works. WWDC23 session 10107 says that without continuous selection only Cancel is hidden and Add stays, so I expected Add to keep working. Seen on both the simulator (iOS 26.1 and 27.0) and a physical device, with Xcode 26.1.1, with and without preselected items. Q1. On a modal PhotosPicker, .photosPickerDisabledCapabilities(.selectionActions) hides Cancel, but Add then does nothing and the picker cannot be dismissed, not even by pulling it down. Is this a bug, or am I misusing the API? Q2. This is about the default modal PhotosPicker with both X and Add shown, without .photosPickerDisabledCapabilities(.selectionActions). With preselected assets, the callback returns the same result whether the user taps Add, taps X, or pulls the sheet down. Are there plans to provide a way to tell them apart?

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?

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