The iOS 27 SDK newly exposed PHLivePhotoRequestOptions.preferHDR. Its documentation states: For best results, only enable this when you intend to display an HDR experience in PHLivePhotoView — for example, when the view’s preferredImageDynamicRange is greater than standard (SDR). PHLivePhotoView has no preferredImageDynamicRange property. How is this API to be used then?

On every iOS 27.0 beta, setExposureModeCustom(duration:iso:completionHandler:) on the front TrueDepth camera (.builtInTrueDepthCamera, position .front) no longer has any observable effect on the video stream. Frame brightness continues to track continuous auto exposure. The same code applies exposure correctly on iOS 26.x and iOS 18.x on the same devices. Reproduced on iPhone 14 Pro Max, iPhone 16, iPhone 16 Pro Max, and iPhone 17 Pro Max running iOS 27.0 betas. Not reproducible on any earlier iOS on the same hardware. Configuration: AVCaptureSession with the TrueDepth device as video input AVCaptureVideoDataOutput (BGRA) plus AVCaptureDepthDataOutput connected Session running, auto exposure settled Repro: Start the session above and wait ~2 s for AE to settle. Apply a custom exposure that should visibly overexpose the image: try device.lockForConfiguration() let format = device.activeFormat device.setExposureModeCustom( duration: CMTime(value: 1, timescale: 15), iso: format.maxISO, // device reports ISO ran completionHandler: nil ) device.unlockForConfiguration() Observe mean luma of delivered frames. Expected: frames become heavily overexposed (max ISO at 1/15 s). Actual: frame brightness is unchanged and keeps adapting with call never happened. No error is thrown, lockForConfiguration succeeds, and isExposureModeSupported(.custom) returns true. The device als custom range (ISO 20...1920, duration up to 1/15 s), so there is no API-visible signal that the command was not applied. [READBACK RESULT: state her device.exposureMode / device.iso / device.exposureDuration reflect the requested values after the call.] Possibly related: on earlier releases the completionHandler f fired on builtInTrueDepthCamera (https://developer.apple.com/forums/thread/770566), while the exposure values themselves were still applied. On i longer applied either. Questions: Is this an intentional change (for example, the system ret while the TrueDepth/depth pipeline is active), or a regression? If intentional, what is the supported way for an app to de refused, and is custom exposure still possible while an AVCaptureDepthDataOutput is connected?

I’m seeing a repeatable first-party cameracaptured crash on an iPhone 14 Pro (iPhone15,2) running iOS 27 beta 5 (24A5424a). The single-camera AVCaptureSession configuration is: Front wide camera 3840×2160 at 30 fps, SDR/420f Two AVCaptureVideoDataOutput connections: Main recording output: 3840×2160 Auxiliary preview output: approximately 2096×1178 Both connections request and activate .standard video stabilization Within roughly two minutes, cameracaptured crashed three times—once during recording and twice during idle preview. The application receives AVErrorMediaServicesWereReset (-11819) after each crash. All three reports have the same faulting queue and underlying stack: com.apple.coremedia.capture.videodata-stabilization.front FigCFDictionaryGetCGRectIfPresent -[BWVISNode _transformRectanglesInMetadata:pts:] -[BWVISNode _stabilizeMetadataForSampleBuffer:] -[BWVISNode _tallyAndEmitSampleBuffer:] VideoStabilizationV2 The first two crashes are: EXC_BAD_ACCESS / EXC_ARM_PAC_FAIL address: 0x00000000dac11a30 termination: PAC_EXCEPTION, code 261 The third reaches the same stabilization stack but terminates with: EXC_BAD_ACCESS / SIGSEGV KERN_INVALID_ADDRESS at 0x30 App-side frame analytics were disabled, system pressure remained nominal, and neither audiomxd nor bluetoothd restarted. The first crash report also shows two front- stabilization worker threads, consistent with the two stabilized video outputs. I have filed Feedback Assistant report FB24553011 with the complete log archive and all three cameracaptured reports. With the iOS 27 public release approaching, waiting for an OS-side fix is not a viable shipping strategy; an app-side workaround is effectively the only option available for our release. Is this a known issue? In particular: Is it safe to leave .standard stabilization on the main recording connection while forcing the auxiliary preview connection to .off? Would disabling/removing the auxiliary AVCaptureVideoDataOutput reliably reduce this to one stabilization pipeline? If a single stabilized front output remains affected, is disabling front-camera stabilization entirely the only supported containment? Is there any public API for disabling the rectangle-metadata processing performed by BWVISNode? The current field workaround is to use the front camera with stabilization Off, or use a rear camera when stabilization is required.

In WWDC20 it was mentioned that missing compileTime/renderTime (or no intermediate image with the dump-intermediates option) can indicate a cached intermediate. I have also seen renderTime=cacheHit on passes that are clearly rendering intermediates, and an actual renderTime is only properly shown on the final pass which always seems to equal the final time render time. In compileTime it says cacheMiss. Which fields should be considered authoritative for tracking intermediate cache hits versus actual rendering? Thanks!

While developing a gallery app, I noticed that the iCloudId can change between devices Phone1 and Phone2, on which iCloud is active. First, I know the assetId is unstable, but the iCloud ID ( How it can be? I thought it was stable and I could use it for sending, for example as a UUID for a items on BE to prevent duplication. Could you please explain to me in which cases the iCloudId can change, and what I can use for stable UUID for my internal item to prevent duplication on the BE side? Additional info: Phone1: - assetId part = B01B27D9-10BE-4C95-BE35-C9A03DBA4006 - iCloudId part = 39E0E3A6-6A37-4E8E-83E9-C1B837E2E973 - iCloudId full = 39E0E3A6-6A37-4E8E-83E9-C1B837E2E973:001:ARUcJ2AQQ/nM6BIRu2dq/NSPi61u Phone2: - assetId part = F51B272C-1BE6-41B3-AB54-39E6BDE1C984 - iCloudId part = F51B272C-1BE6-41B3-AB54-39E6BDE1C984 - iCloudId full = F51B272C-1 BE6-41B3-AB54-39E6BDE1C984:001:ARUcJ2AQQ/mM6BIRu2dq/NSPi61u

Thanks for adding CoreML into the Apple RAW decoder. I'm excited with what it can bring. But I'm having a number of issues with it. My code base is written in Objective-C, and I'm using my custom MTKView. Now when I enabled RAW 9 support, the render is extremely slow (instant vs seconds). The UI would appear to hang with a spinning color wheel. It feels like CoreML processing is being delegated in the rendering thread, which runs on the main queue. How can I improve performance? As someone has reported, there is a black horizontal line in the middle of the image. The image that I was testing came from Fuji X-T5. If I enable EDR (Extended Dynamic Range), RAW 9 stops rendering, and will return ANE error. My app does HDR rendering of RAW files. I cannot get something like Sony A7R IV ARW image to load. Same ANE error. Is there a memory setting I need to tweak? When I render the X-T5 image, the colors appear to be overly saturated, which is different from the result of RAW 8. I cannot speak for the color rendering of other types of RAW files. I was told code base with Catalyst (and perhaps Swift) works without issue, other than being slow (except for large RAW files), but there seems to be an issue with Objective-C?

When building apps, how can I maximize my camera features while using an app to scan and analyze textiles? Is there an integration that has to be inputted that catalogs every fabric type or AI models are able to learn fabric type from every scan? also what is the process/code of including visionOS to scan fabric types to catalog on devices such as smartphones and computers?

Hello, I am developing an iOS app that uses MusicKit and ApplicationMusicPlayer to create automatic transitions between songs from Apple Music. The app already analyzes tracks using BPM, musical key and danceability, orders them for compatible transitions, and uses MusicPlayer.Transition.crossfade for playback. With the public MusicKit APIs, however, I have reached a limitation. ApplicationMusicPlayer manages the playback queue and crossfade internally. I cannot independently control the outgoing and incoming Apple Music tracks as two decks, which would be required for DJ-style transitions (for example, starting the incoming track while independently controlling the outgoing track, choosing precise mix points, and managing the two playback positions during the overlap). I experimented with MusicPlayer.Queue.Entry startTime and endTime, but changing the end point is not equivalent to having independent deck control and can result in the current track ending before the desired transition. I understand that Apple Music content is protected and that direct access to decoded audio samples may intentionally not be available through the public MusicKit APIs. I am not looking to download, extract, record, or export Apple Music audio. My use case is real-time playback only, for authenticated Apple Music subscribers. My questions are: Is there a public API that allows two Apple Music tracks to be independently controlled and mixed in real time? If not, is there a restricted entitlement, API, or developer program available for DJ/mixing applications? If this capability requires a commercial or technical partnership with Apple Music rather than a public API, is there an official channel through which a developer can request or discuss such access? I am aware that some third-party DJ applications provide real-time mixing with Apple Music, so I would like to understand whether there is an officially supported integration path for other developers, rather than trying to work around the limitations of ApplicationMusicPlayer. Thank you.

I have not seen any issues with didActivateAudioSession not getting called by iOS in many many years with many thousands of devices. However with iOS27 beta code I have seen a few times that when making an outgoing call it never gets called. All subsequent outgoing calls fail until I dismiss and relaunch the App.

I’m seeing a device/OS-specific AVFoundation issue on iPhone 14 Pro running iOS 26.6. A secondary AVCaptureVideoDataOutput is used to provide an unstabilized monitoring feed while the main recording connection is stabilized. During continuous zoom changes, frames from the secondary output continue arriving and scene motion remains live, but its visible zoom/crop/FOV intermittently remains unchanged and then catches up. The saved recording remains smooth and reflects the requested zoom correctly. Minimal configuration: Device: iPhone 14 Pro iOS: 26.6 Physical Ultra Wide camera 1920×1080 at 30 fps SDR, 8-bit YUV Main VDO: 420v Main connection stabilization: .cinematicExtendedEnhanced Auxiliary VDO: 420f Auxiliary connection stabilization: explicitly .off automaticallyConfiguresOutputBufferDimensions = false deliversPreviewSizedOutputBuffers = true alwaysDiscardsLateVideoFrames = true Deferred start disabled Both outputs use a serial delegate queue The auxiliary output is displayed directly without image processing. During continuous videoZoomFactor updates: AVCaptureDevice.videoZoomFactor advances correctly. The UI zoom value advances correctly. The main recorded output zooms smoothly. Frames from the auxiliary output continue arriving and scene motion remains live. Only the auxiliary output's visible zoom/crop/FOV intermittently holds at an older value and then catches up. This is not a complete preview-frame stall: camera movement remains visible during the periods when zoom does not visually advance. The problem occurs with any non-Off stabilization tier in the production app because that configuration installs the unstabilized auxiliary output. Stabilization Off removes the auxiliary topology, and zoom then appears smooth on the main preview feed. A standalone capture sample reproduces the problem without the application’s writer or rendering pipeline. Current device matrix: iPhone 14 Pro, iOS 26.6: reproduces. iPhone 13 Pro, iOS 18.6.x, same released application version: does not reproduce. iPhone 17 Pro, iOS 26.6, isolated sample: does not reproduce. iPhone 14 Pro, iOS 27 beta 5: testing in progress — result to be added. The issue was initially reported with HEVC/Apple Log capture, but it remains reproducible after reducing the graph to 1080p30 SDR8. Questions: Is using two video-data-output connections with different stabilization modes—Extreme on the recording output and Off on the monitoring output—a supported configuration? Is delayed propagation of zoom geometry/crop to a secondary video-data output known on iPhone 14 Pro/iOS 26 when another output connection is stabilized? Is there a recommended AVFoundation topology for obtaining a low-latency, unstabilized monitoring feed while separately recording stabilized video? Are there output or connection properties that must be set to make videoZoomFactor geometry changes propagate synchronously to both outputs? I can provide the standalone sample project, screen recordings, connection-mode logs, buffer PTS/arrival cadence, and a sysdiagnose. EDIT: Issue seen on iOS 27 beta 5 devices as well. No such issue is seen in iOS 18 devices.

Hi, I'm currently experiencing issues with HLS streams created by FFmpeg running on Safari. When I pass the stream to the mediastreamvalidator tool and then run hlsreport on the output, I get a critical error reported: Media Entry discontinuity value does not match previous playlist for MEDIA-SEQUENCE 1 If I let the stream finish (it's a live stream from an IoT device) and then perform the stream validation again I no longer receive the critical error. My assumption is that this critical error is contributing to the HLS stall on iOS. I have also noticed that if I let the stream continue and then re-load the video control in Safari the stream starts Is there a resource with explanations or remediation paths relevant to the possible output of the hlsreport? My m3u8 output looks like this (I have redacted the server host) #EXTM3U #EXT-X-VERSION:6 #EXT-X-TARGETDURATION:2 #EXT-X-MEDIA-SEQUENCE:1 #EXT-X-PLAYLIST-TYPE:EVENT #EXT-X-INDEPENDENT-SEGMENTS #EXT-X-DISCONTINUITY #EXTINF:2.000000, https://redacted.com/segment-00001.ts #EXTINF:2.000011, https://redacted.com/segment-00002.ts #EXTINF:2.000011, https://redacted.com/segment-00003.ts #EXTINF:2.000011, https://redacted.com/segment-00004.ts #EXTINF:2.000011, #EXT-X-ENDLIST Thanks for any advice or guidance possible - if I can provide isolated code snippets I will do. Andy

We are building an accessibility-focused iOS app that uses a user-initiated ReplayKit broadcast to recognize visible text and provide an on-device translation. To keep the translated result visible while the user is in another app, the current prototype presents the translation UI with AVPictureInPictureVideoCallViewController. The problem is that ReplayKit includes this PiP window in the captured frames. Once the captured frame is rendered back into the PiP content, the PiP captures itself recursively, obscures the source text, and can significantly degrade performance. Reproduction: Start a system broadcast using RPSystemBroadcastPickerView. Present AVPictureInPictureVideoCallViewController with the app's translation UI. Leave the host app and place the PiP window over another app. Inspect the CMSampleBuffer frames received by the broadcast upload extension. The frames contain the PiP window itself, producing a repeated "window inside window" image. We need a public, App Store-safe architecture that: keeps a small user-controlled translation surface visible across apps; allows the user to move or collapse it; prevents that app-owned floating surface from appearing in ReplayKit capture; uses only explicit user activation and documented APIs. Questions: Is there a supported public API or entitlement that excludes an app-owned PiP window, UIWindow, view, or layer from ReplayKit capture? If not, is there a supported alternative to PiP for a compact cross-app accessibility controller that the system excludes from capture? Is the broadcast upload extension expected to receive any metadata identifying the PiP region so it can be masked without relying on visual heuristics? We are not requesting private API access. A focused Xcode reproduction project has already been provided to Apple Developer Technical Support under an active TSI, and the related enhancement request is FB24319994. Environment: Xcode 26.6 (17F113) iPhone / iOS 18 and later ReplayKit broadcast upload extension AVPictureInPictureVideoCallViewController Any documented approach or confirmation that this is currently unsupported would be very helpful.

The Apple Music Recently Played API appears to have changed its behavior on 2026-08-05/2026-08-06. The endpoint no longer reports songs that are saved in a user's library. This impacts music tracking applications that rely on this API to retrieve listening history. Currently, tracks only appear in the Recently Played response when users stream them directly from the Apple Music catalog. If a user plays a song from their personal library, the playback is not reported by the endpoint and cannot be tracked. This is a breaking change that significantly affects existing integrations, but we could not find any announcement in the release notes or updates to the documentation regarding this behavior change. Could you please confirm whether this change is intentional? If so, we would appreciate updated documentation or guidance on how apps should handle tracking playback from a user's library.

Keywords: FairPlay, FairPlay Streaming, FPS Certificate, DRM, Certificate Limit, License Server Hello Apple Developer Forums Team, We are seeking guidance regarding a FairPlay Streaming (FPS) certificate issue that is currently blocking our production DRM infrastructure. We previously generated FairPlay Streaming deployment credentials and have been using FairPlay Streaming for our protected video content. Unfortunately, our old server infrastructure crashed, and the private keys/credentials associated with the previously generated FairPlay Streaming certificate were permanently lost. As a result, we need to generate replacement FairPlay Streaming deployment credentials. However, when attempting to create a new FairPlay Streaming certificate, our Apple Developer account now displays the following error: “Maximum number of certificates generated.” The main issue is that the existing FairPlay Streaming certificates do not provide any option in the Apple Developer portal to revoke or delete them. Therefore, we are unable to remove obsolete or inaccessible certificate records and cannot generate replacement credentials. Our current situation is: We have reached the maximum number of FairPlay Streaming certificates allowed for our Developer Team. The Apple Developer portal does not provide a revoke or delete option for the existing FPS certificates. The private keys associated with our old FairPlay Streaming credentials were permanently lost after our previous server infrastructure crashed. We cannot recover or reuse those old credentials. We are unable to generate replacement FairPlay Streaming deployment credentials because the certificate generation limit has been reached. This is currently blocking our ability to restore and maintain our FairPlay-protected production streaming service. We have already contacted Apple Developer Support and submitted multiple follow-ups regarding this issue, but we have not yet received a solution that allows us to generate replacement credentials. We would like to understand the official Apple-supported process for the following situation: What is the supported procedure when a Developer Team reaches the maximum number of FairPlay Streaming certificates? If existing FPS certificates cannot be revoked or deleted through the Developer portal, is there an Apple-supported process to remove obsolete or inaccessible FPS certificate records? Can Apple reset or restore the FairPlay Streaming certificate generation capacity for a Developer Team when the old credentials and private keys are permanently unavailable? Is there another supported method for generating replacement FairPlay Streaming deployment credentials in this situation? We are not requesting general instructions on how to generate a FairPlay Streaming certificate. We understand the standard certificate generation process. Our issue is specifically related to an exhausted FPS certificate generation limit combined with the absence of a self-service revoke/delete option for the existing certificates. We would greatly appreciate guidance from Apple or the FairPlay Streaming team on how to resolve this issue and restore our ability to generate replacement FPS deployment credentials. Thank you for your assistance.

I am developing DOWNBEAT, a paid macOS Audio Unit plugin for Logic Pro live playback control. The plugin reads marker, tempo, and time signature data from a user-selected Logic Pro project and lets performers build a stage setlist. During live use, the performer needs to click a song in DOWNBEAT and have Logic Pro move the playhead directly to that song’s marker position. The current reliable method uses Logic Pro controller assignments mapped to “Go to Marker Number 1” through “Go to Marker Number 20.” This works for markers 1-20, but Logic Pro does not appear to expose direct “Go to Marker Number 21” or higher commands. I need to know whether Apple provides any supported public API, control-surface API, MIDI Device Script capability, Audio Unit host interaction, Apple Event, or other documented mechanism that allows a third-party macOS app/plugin to move Logic Pro’s playhead directly to a bar/beat position or marker position without opening a modal window. This is for live performance, so reliability is critical. Methods that open the “Go to Marker” or “Go to Position” window and type values are not acceptable, because they create visible UI interruptions during a show. What I have already tested: Logic Pro controller assignments: “Go to Marker Number 1” through “Go to Marker Number 20” work. “Go to Marker Number 21” does not appear to exist as a direct assignable command. Logic Pro MIDI Device Script / Lua control-surface script: I created a temporary MIDI Device Script that mapped a test control to “Go to Marker Number 1.” That worked. I then mapped another test control to “Go to Marker Number 21.” That did not work. I also tested “Go to Marker Number...” and it did not provide a usable direct non-modal workflow. MIDI Machine Control / SMPTE Locate: Logic received incoming MIDI, but location behavior was not reliable enough for live use. In multi-tempo projects, locate results could land incorrectly or cause visible playhead jumps. Logic Environment meta events: Tested incoming MIDI through the Logic Environment. MIDI was visible, but it did not provide reliable direct marker navigation. Mackie Control / MCU direction: Research suggests MCU marker commands do not provide direct absolute marker selection beyond the limited marker/function range. Specific questions: Is there a supported public way for a third-party macOS app, Audio Unit plugin, MIDI Device Script, or Logic Pro control-surface integration to set Logic Pro’s playhead directly to a specific bar/beat position? Is there a supported public way to trigger direct marker navigation beyond “Go to Marker Number 20” without opening a modal window? If the answer is no, is the recommended Apple-supported approach for this use case to limit direct marker navigation to the first 20 markers? Is there any supported Logic Pro control-surface API or developer program path that would allow this kind of direct live-performance marker navigation?

PHAssetExtendedMetadata has the following API: /// The original file name of this asset. open var originalFilename: String? { get } And PHAssetResource has the following API: @available(iOS, introduced: 9, deprecated: 27, message: "Use filename instead") open var originalFilename: String { get } /// The filename associated with this asset resource (if any) @available(iOS 27, *) open var filename: String? { get } I'm confused why PHAssetExtendedMetadata (iOS 27+) has originalFilename while PHAssetResource originalFilename was deprecated and replaced with filename. I would have expected PHAssetExtendedMetadata's property be named filename to match. Are all 3 of these all the exact same name or can there be differences?

Here is a natural, professional English translation suitable for a bug report (such as filing via Apple's Feedback Assistant): Title / Summary Photos app defaults to creation time instead of EXIF date when region and time format are mismatched Bug Description Photos saved or received in the system Photos app (via downloads, AirDrop, etc.) use the saving timestamp as their capture date instead of preserving the photo's original metadata/EXIF timestamp. Steps to Reproduce Go to Settings > General > Language & Region. Set a Region whose default time format differs from your custom toggle (e.g., set Region to Japan, which defaults to a 24-hour clock, but manually switch the time format toggle to 12-Hour Time). Save or receive an image via AirDrop/download. Observe that the photo's original date metadata is ignored and replaced by the current timestamp. Root Cause Analysis The bug occurs when the device's custom time format (12/24-hour) mismatches the default time format of the selected Region, causing date metadata parsing to fail in the Photos app. Workaround Resetting the time format back to match the Region's default setting resolves the issue. Expected Result The system should correctly parse and preserve original image creation dates regardless of custom region or time format overrides. This issue should be resolved in a future software update. Affected OS Versions iOS 17+ iPadOS 17+ macOS 14 (Sonoma)+

Is there an expected date for Canon R5 Mark II raw 9 support?

We keep live playback at a consistent distance from the live edge using small playback rate adjustments, with a target range based on recommendedTimeOffsetFromLive. Since the live edge is not exposed by AVPlayer, we currently fall back to seekableTimeRanges.end as our best approximation. What should be treated as the live edge, and how should the current live latency be measured? Is rate adjustment the appropriate way to hold a target latency? While playing above 1.0x, the playhead can reach the seekable end, at which point AVPlayerItemDidPlayToEndTime fires and halts the live stream. How can we guard against ? Does any of this differ between regular HLS and LL-HLS? A clear statement of the intended contract here would resolve a lot of uncertainty. Thanks in advance.

Hi there, I recently launched a dj app to the mac app store, and was wondering how I could access songs for mixing purposes via Apple Music just like how serato, rekordbox, djay, and other DJ apps do? Thanks, Gunek