On every iOS 27.0 beta, setExposureModeCustom has no effect on the front camera (.builtInTrueDepthCamera). exposureMode does change to .custom, but the sensor keeps auto-exposing: device.iso and device.exposureDuration report auto-exposure's values, not the requested ones, and frame brightness does not change. No error is thrown. The same code works on iOS 18.x and 26.x on the same devices. Device: iPhone 15 Pro, every iOS 27.0 beta. Also seen on iPhone 14 Pro Max, 16, 16 Pro Max and 17 Pro Max. Session: front camera, AVCaptureVideoDataOutput (BGRA) + AVCaptureDepthDataOutput. Format advertises ISO 20...1920, duration 0.00004...0.06667 s. isExposureModeSupported(.custom) is true. Repro: let auto-exposure settle, then try device.lockForConfiguration() device.setExposureModeCustom(duration: CMTime(value: 1, timescale: 15), iso: 1920, completionHandler: nil) device.unlockForConfiguration() then poll device.iso / device.exposureDuration (the completion handler never fires on this device) and measure frame luma. Readback, polled 0.8 s after the call: requested ISO 1920, 66.7 ms -> reported ISO 349, 60.0 ms requested ISO 20, 0.04 ms -> reported ISO 188, 66.5 ms Requesting the shortest exposure returns the longest, and the same ISO 1920 request returned 249, 349 and 450 on three consecutive runs, so these are auto-exposure's values. Frame luma stayed within 1% between the two phases. setExposureTargetBias, however, is honored on the same device: at +4 EV auto-exposure drives the sensor to ISO 1920 / 66.5 ms and at -4 EV to ISO 24 / 30.0 ms, moving mean luma from 49 to 232. So the sensor does reach the values setExposureModeCustom cannot set. Question: is this intentional or a regression, and how should an app detect that a custom exposure request was refused?

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?