It's unclear if this is a bug or a new feature but I have noticed that my photos starting coming out looking more stylised than expected and worked out that it was because photographic styles were being applied even tho I was taking photos through a third party app. Is there a way to disable this behaviour if it is intended? I've raised a feedback report #FB23632714 Photographic Styles [OFF] Photographic Styles [ON] My settings:

I'm building a fixed-focus camera app (Bayer RAW, manual exposure, focus permanently locked at a known lens position) and need a full-power flash still that keeps that locked focus. On iPhone 17 Pro, iOS 26, any capture with flashMode = .on runs an autofocus-assist scan — visible lens hunt, assist lamp in low light — and the exposure happens at whatever the scan converged on (usually the far background), not my locked position. In low light it reproduces every time; bright-scene behavior varied by configuration (see matrix), and in my current build it hunts in daylight too. This follows https://developer.apple.com/forums/thread/724897 where DTS confirmed locked lens position + flash "is possible" in a test app, but the differentiating configuration was never identified. I've now exhausted every documented lever, with instrumentation, and would like guidance on whether this stage is bypassable at all. Session configuration session.sessionPreset = .photo // Plain wide camera (also reproduced on .builtInLiDARDepthCamera). let camera = AVCaptureDevice.default( .builtInWideAngleCamera, for: .video, position: .back )! session.addInput(try AVCaptureDeviceInput(device: camera)) session.addOutput(photoOutput) photoOutput.maxPhotoQualityPrioritization = .speed photoOutput.isZeroShutterLagEnabled = false photoOutput.isResponsiveCaptureEnabled = true // Pre-allocate flash capture resources up front. photoOutput.setPreparedPhotoSettingsArray( [makeFlashRawSettings()], completionHandler: nil ) Device configuration (before any capture) try camera.lockForConfiguration() camera.isSubjectAreaChangeMonitoringEnabled = false camera.isSmoothAutoFocusEnabled = false camera.autoFocusRangeRestriction = .near camera.automaticallyEnablesLowLightBoostWhenAvailable = false camera.automaticallyAdjustsFaceDrivenAutoFocusEnabled = false camera.isFaceDrivenAutoFocusEnabled = false // true is worse; see matrix camera.automaticallyAdjustsFaceDrivenAutoExposureEnabled = false camera.isFaceDrivenAutoExposureEnabled = false camera.setFocusModeLocked(lensPosition: 0.60) // ~1 m on this device let gains = camera.deviceWhiteBalanceGains( for: .init(temperature: 4000, tint: 0) ) camera.setWhiteBalanceModeLocked(with: gains) camera.setExposureModeCustom( duration: CMTime(value: 1, timescale: 125), iso: 400 ) camera.unlockForConfiguration() Capture func makeFlashRawSettings() -> AVCapturePhotoSettings { let bayer = photoOutput.availableRawPhotoPixelFormatTypes.first { AVCapturePhotoOutput.isBayerRAWPixelFormat($0) }! let settings = AVCapturePhotoSettings(rawPixelFormatType: bayer) settings.flashMode = .on settings.isAutoRedEyeReductionEnabled = false settings.isAutoStillImageStabilizationEnabled = false settings.isAutoVirtualDeviceFusionEnabled = false settings.isAutoContentAwareDistortionCorrectionEnabled = false settings.photoQualityPrioritization = .speed return settings } // Right before the request, exposure flips .custom → .locked (same // duration/ISO), one preview frame presents, then: photoOutput.capturePhoto(with: makeFlashRawSettings(), delegate: self) What I measure (KVO during the capture window) isAdjustingFocus goes true after the request: a scan runs despite focusMode == .locked (assist lamp on in low light). lensPosition moves from the locked 0.60 to a far position and stays there through willCapturePhotoFor — the exposure uses the scan's answer. When isAdjustingFocus falls back to false (before the metering preflash) I issue one setFocusModeLocked(lensPosition: 0.60). The call succeeds, yet the exposure still happens at the far position — something re-asserts the scan's focus before the strobe. With flashMode = .off, locked focus and custom exposure are honored perfectly (my app's normal path). Tried, all reproduced focusMode = .locked + setFocusModeLocked(lensPosition:): scan still runs. Exposure .custom → .locked for the flash window: no change. Plain wide vs LiDAR wide device: no change. Subject-area / smooth AF / face-driven AF+AE / low-light boost all off: scan still runs in low light. isFaceDrivenAutoFocusEnabled = true (steer scan toward faces): worse — scans in daylight too. Red-eye reduction, fusion, distortion correction off: no change. autoFocusRangeRestriction = .near: still converges far. photoQualityPrioritization = .speed everywhere: no change. Prepared photo settings (flash RAW): no change. Re-lock lens mid-scan: fights the scan; worse convergence. Re-lock lens after scan, before strobe: succeeds; exposure still at the scan's position. Torch lit at request time: scans even in bright daylight. The last two items seem diagnostic: the gate is not scene brightness. A torch adding no visible light in daylight still arms the scan, and face-driven AF arms it in bright scenes — the AF-assist stage runs whenever the sequence sees any reason to focus, and a client's .locked focus mode is never treated as that reason being absent. Questions Is the flash AF-assist stage skippable when focusMode == .locked? The earlier thread's DTS reply achieved a locked-focus flash photo — what configuration makes that true on current hardware/iOS? If not skippable: is there a supported way for the final exposure to honor the locked lens position — run the scan but not apply its result? Why does a successful setFocusModeLocked(lensPosition:) issued between scan end and strobe not stick? Is the sequence re-asserting its own focus at exposure time? Are the observed triggers (torch active at request; face-driven AF enabled — each arming the scan regardless of brightness) expected for flashMode = .on? Goal: full-power flash still + fixed focus + manual exposure, which flashMode = .off already delivers minus the flash. Any guidance — including "file a feedback, here's the rdar to duplicate" — appreciated. Happy to attach a focused sample project and sysdiagnose.

Hello, I am creating a simple camere app where I want to turn OFF the autofocus (and set the focus within the app) then take a picture with the flash. The only problem is as soon as i set the flash and take a photo, it auto focuses even though i have set the focus mode locked and lens position? Is this even possible? My av capture output settings:     photoOutput.isHighResolutionCaptureEnabled = true     photoOutput.isLivePhotoCaptureEnabled = false;     photoOutput.isDepthDataDeliveryEnabled = false;     photoOutput.isPortraitEffectsMatteDeliveryEnabled = false     photoOutput.isAppleProRAWEnabled = false;     photoOutput.setPreparedPhotoSettingsArray([buildPhotoSettings(flash: flash)]); my AVCapturePhoto Settings     let photoSettings = AVCapturePhotoSettings(rawPixelFormatType: availbleRaw[0]);     photoSettings.isAutoStillImageStabilizationEnabled = false;     photoSettings.flashMode = flash ?.on :.off;     photoSettings.isHighResolutionPhotoEnabled = true;     photoSettings.isAutoRedEyeReductionEnabled = false; my device input settings           //--white balance     let whiteBalanceValues = AVCaptureDevice.WhiteBalanceTemperatureAndTintValues(temperature: settings.whiteBalanceTemp, tint: settings.whiteBalanceTint);     let newWhiteBalance = videoDeviceInput.device.deviceWhiteBalanceGains(for:whiteBalanceValues);     let maxGain = videoDeviceInput.device.maxWhiteBalanceGain           if(newWhiteBalance.redGain > maxGain || newWhiteBalance.greenGain > maxGain || newWhiteBalance.blueGain > maxGain){       videoDeviceInput.device.unlockForConfiguration();       return (false, "WhiteBalance values are invalid (over maximum gain allowed)");     }           videoDeviceInput.device.setWhiteBalanceModeLocked(with: newWhiteBalance);           //--iso and exposure     let exposure = Float64(settings.exposure/1000);     let exposureTime = CMTime(seconds: exposure, preferredTimescale: 1000)     let iso = Float(settings.iso)           if(exposureTime > videoDeviceInput.device.activeFormat.maxExposureDuration || exposureTime < videoDeviceInput.device.activeFormat.minExposureDuration){       videoDeviceInput.device.unlockForConfiguration();       return (false, "Exposure out of bounds");     }           if(iso > videoDeviceInput.device.activeFormat.maxISO || iso < videoDeviceInput.device.activeFormat.minISO){       videoDeviceInput.device.unlockForConfiguration();       return (false, "ISO out of bounds");     }           videoDeviceInput.device.setExposureModeCustom(duration: exposureTime, iso: iso);           //--Lens focus     if(settings.lensPosition < 0 || settings.lensPosition>1){       videoDeviceInput.device.unlockForConfiguration();       return (false, "Lens position out of bounds");     }               if(videoDeviceInput.device.isFocusModeSupported(.locked)){       videoDeviceInput.device.focusMode = .locked;       videoDeviceInput.device.setFocusModeLocked(lensPosition: settings.lensPosition);             }           if #available(iOS 15.4, *) {       if(videoDeviceInput.device.isFaceDrivenAutoFocusEnabled){         videoDeviceInput.device.automaticallyAdjustsFaceDrivenAutoFocusEnabled = false;                 }               if(videoDeviceInput.device.isFaceDrivenAutoExposureEnabled){         videoDeviceInput.device.automaticallyAdjustsFaceDrivenAutoExposureEnabled = false;       }               if(videoDeviceInput.device.isLowLightBoostSupported){         videoDeviceInput.device.automaticallyEnablesLowLightBoostWhenAvailable = false;       }     } else {       // Fallback on earlier versions     }           //--Torch ON     videoDeviceInput.device.torchMode = settings.torch ? AVCaptureDevice.TorchMode.on :AVCaptureDevice.TorchMode.off;           if(settings.torch){       if(settings.torchLevel<0 || settings.torchLevel>1){         return (false, "Flash out of bounds");       }               try? videoDeviceInput.device.setTorchModeOn(level: Float(settings.torchLevel));     }                       //--Finish     videoDeviceInput.device.unlockForConfiguration();

We capture Apple Log video using AVCaptureVideoDataOutput with: AVCaptureDevice.activeColorSpace = .appleLog or .appleLog2 kCVPixelFormatType_422YpCbCr10BiPlanarVideoRange (x422) AVAssetWriter for the final ProRes/HEVC recording We need to bake spatial operations such as a centre crop and optional anamorphic desqueeze into the recorded raster. We want the result to remain Apple Log for subsequent grading; we do not want to display-transform or convert it to HLG. Core Image/Core Graphics does not appear to expose a public Apple Log or Apple Log 2 CGColorSpace. Core Video instead identifies the signal using kCVImageBufferLogTransferFunctionKey. Would this be the supported Core Image approach for spatial-only processing? let image = CIImage( cvPixelBuffer: sourceBuffer, options: [.colorSpace: NSNull()] ) let context = CIContext( mtlDevice: metalDevice, options: [ .workingColorSpace: NSNull(), .outputColorSpace: NSNull(), .cacheIntermediates: false ] ) let outputImage = image .cropped(to: cropRect) .transformed(by: spatialTransform) context.render( outputImage, to: destinationX422Buffer, bounds: outputBounds, colorSpace: nil ) We would then copy the source buffer’s Apple Log colour and Log-transfer attachments to the destination buffer and append it to an AVAssetWriterInputPixelBufferAdaptor. Could an Apple engineer clarify the following? Does CIImage(cvPixelBuffer:) natively interpret kCVImageBufferLogTransferFunctionKey, even though no public Apple Log CGColorSpace exists? When NSNull()/nil is supplied as above, does Core Image leave the Apple Log values unmanaged during crop and affine operations? When rendering x422 to x422, can Core Image preserve the Log signal apart from expected resampling/rounding, or does it internally perform a colour conversion such as YCbCr → RGB → YCbCr? For scaling or anamorphic desqueeze, is Apple’s recommended workflow to: resample the encoded Apple Log values with colour management disabled, or explicitly decode Apple Log to a linear working space, resample, and encode back using a custom Metal implementation? Is copying kCVImageBufferLogTransferFunctionKey and the related colour attachments from source to destination sufficient for AVAssetWriter, assuming the writer settings were obtained from recommendedVideoSettingsForAssetWriter(writingTo:)? Is there ever a supported reason to use HLG as an intermediate for Apple Log processing, or should that be avoided? This this part, we are concerned about preserving the captured Log signal in a recording pipeline, not applying a viewing LUT or displaying Apple Log. Next, we also support optional LUT processing with CIColorCube. Some LUTs are technical Apple Log-to-display transforms, while others expect linear or Rec.709 input. If the image is created with .colorSpace: NSNull(), we understand that the LUT receives unmanaged Apple Log code values and that the LUT itself must perform the required transfer-function and gamut conversion. Does Core Image synthesize an Apple Log-aware input color space from kCVImageBufferLogTransferFunctionKey, or must applications implement Apple Log/Apple Log 2 decoding explicitly before using ordinary Core Image filters? Is there a supported CGColorSpace, ColorSync profile, or Core Image conversion API for this? Additionally, what numeric range does CIColorCube receive when its source is an x422 video-range Apple Log buffer— normalized Log RGB values, or values requiring explicit video-range conversion?

Summary. iPhone 17 Pro Max + Blackmagic Camera ProDock, genlock BNC in from a generator confirmed at a true 30.00 fps. follow(_:videoFrameDuration:delegate:) reaches .activeSync in ~2 s. On one unit the lock then holds for 10+ minutes. On a second unit, same binary and same reference, it detaches 6 s to ~4 min after lock: .activeSync → .ready with input.externalSyncDevice == nil, no runtime error and no delegate error. Calling follow() again on the still-running session is rejected with -11800 every time, while unfollowExternalSyncDevice() plus a stopRunning()/startRunning() bounce recovers reliably. I am not looking for a fix. I want to know whether my call sequence is wrong, whether this transition is expected, and how a shipping app should be structured around it. Questions Is re-following a running session supported? Is the unfollow + bounce the intended reset sequence, or is there a lighter-weight way to clear whatever state the -11800 is keyed on? And once detached, is re-acquisition entirely the app's responsibility, or is the system expected to re-calibrate on its own while the reference is present? Is a hard detach a legal outcome for an already-calibrated input? The documentation describes .freeRunSync as the hold-over when a locked input loses sync. Is that hold-over guaranteed, or must an app also handle .activeSync → .ready with a nil externalSyncDevice? Is anything in my call sequence wrong (code in a reply below), and is polling input.externalSyncDevice the right signal to key recovery on, or is there a supported notification for detach? Setup. Video-only AVCaptureSession: one .builtInWideAngleCamera input, one AVCaptureVideoDataOutput. No multi-cam, no depth output, no synchronizer, no audio. Both frame durations set to CMTime(1, 30) before the input is created, never rewritten while a follow is live. Device A (iOS 26.0.1) holds: 601 s and 956 s runs, zero detaches. Device B (26.3.1, then 26.5.2) has 39 drops across 6 logs. The ProDock, cable and generator were swapped between units; the failure followed the phone. Caveat: n=2, and unit and OS build vary together. The detach. No AVCaptureSessionRuntimeError and no delegate error (-11892 has never been observed here, so this is not the documented frame-duration-mismatch path). The session keeps running and delivering frames. Status is .ready, not .unavailable — the ProDock stays enumerated, the reference unchanged. No confirmed drop has passed through .freeRunSync. PTS ground truth, independent of the follow state: while locked, every frame PTS sits exactly on the 1/30 grid, zero drift. At the drop there is exactly one teardown gap, 238–337 ms across 8 runs, after which the clock free-runs at ~30.013 fps (444 ppm) and never returns to the grid. On -11800. It surfaces through AVCaptureSessionRuntimeErrorNotification. The bounce recovers 3/3, with no activeFormat change. Caveat: -11800 is AVErrorUnknown and I see it in unrelated cases too, so I do not assume it is specific to retained follow state. Ruled out. Exposure duration — a run at ≤ 16.67 ms, within the recommendation in the follow() documentation, still drops. Reference drift — zero, by microsecond PTS. Accessory chain — full swap; the failure followed the phone. Another client — Final Cut Camera holds genlock on the fragile unit with the same ProDock and reference. Load and resolution — load changes time-to-drop, not whether it drops; with recording and audio off it still drops, and Device B drops at both 12 MP and 1080p. Code and supporting logs are in replies below; the length limit would not take them inline. Per-frame PTS CSVs, raw status logs, and a minimal Xcode project that still drops are available on request. Prior art read: forums/thread/799739 and thread/804594 — neither covers post-lock detach or re-acquisition.

Hello Apple Developer Team, We are currently developing an enterprise medical navigation application for Apple Vision Pro and would like to request clarification regarding the currently available visionOS Enterprise APIs related to camera access. Our application scenario involves real-time medical/surgical navigation and instrument tracking in a professional enterprise environment. We would like to better understand the following: How many cameras on Apple Vision Pro are currently accessible through the Enterprise APIs? Which specific cameras are accessible? For example: Main RGB cameras Passthrough cameras Tracking cameras Front-facing cameras Depth sensors LiDAR or structured-light related sensors Are simultaneous multi-camera streams supported? Does the Enterprise API provide: Real-time image frames Camera intrinsic/extrinsic parameters Stereo camera data Depth information Low-latency tracking-related data Are there any restrictions regarding the use of Vision Pro cameras for: Medical navigation Surgical guidance Instrument tracking Enterprise healthcare software Is Apple Vision Pro currently permitted or recommended for medical enterprise spatial-navigation workflows under the Enterprise APIs? We would greatly appreciate any official clarification regarding the current capabilities and limitations of camera access on Apple Vision Pro for enterprise medical applications.

I've been trying to implement the newly touted high resolution capture at 24MP from WWDC26: https://developer.apple.com/videos/play/wwdc2026/304/ However it seems it's only possible to capture 24mp photos if you enable autoDeferredPhotoDelivery? This is quite frustrating as my app wants to run the image output through shaders and effects before saving. Is there a way round this limiation?

From visionOS 2.0 we can access Apple Vision Pro's main camera but only for Enterprise account as it is enterprise API only, I have a normal Developer account and I want to use main camera and want to have a video call feature in app by using main camera of AVP, is it possible to do it using developer account only. Currently using that account I am not able to create entitlement certificate as there is no option.

Hi everyone, I’m working on a camera app as a learning project and have reached a point where I’m trying to better understand the intended architecture for Live Photo capture using AVCapturePhotoOutput. The app currently supports: Live Photos Depth data Location metadata Multiple lens presets on a virtual multi-camera device Everything is working well, but I’m now thinking about capture throughput and rapid shutter presses. Right now, my implementation is fairly conservative. I wait for a Live Photo capture to finish processing and importing before allowing another capture. This is reliable, but it doesn’t feel particularly camera-like when compared to Apple’s Camera app. One observation from field testing caught my attention: I took a Live Photo, immediately switched lenses, then took another Live Photo. When I viewed the first Live Photo later, the movie portion included the lens-switching actions that occurred after I pressed the shutter. That made me realize that I may be thinking about the capture lifecycle incorrectly. My questions are: When using AVCapturePhotoOutput with Live Photos enabled, what is the earliest point at which a capture can be considered “safely secured”? Is it expected that apps wait for PhotoKit import to complete before accepting another Live Photo capture request? If supporting rapid sequential shutter presses, is the recommended approach to queue capture requests and process them one at a time? Are there any best practices around lens changes or camera reconfiguration while a Live Photo is still being captured or processed? I’m not looking for details about the implementation of Apple’s Camera app. I’m mainly trying to understand the recommended approach when working with the public AVFoundation APIs. I’d appreciate any guidance, documentation references, or examples from developers who have worked through similar problems. Thanks!

I'm building a Wi-Fi captive portal (web page) that needs the camera to scan a boarding-pass barcode. Inside the iOS Captive Network Assistant (the sign-in pop-up that appears when you join Wi-Fi): getUserMedia() (live camera) doesn't work, and <input type="file" capture="environment"> opens only the photo library, not the camera. The same page works fine in full Safari on the same iPhone. Is camera access intentionally blocked in the CNA, or is there a supported way to use it? Has anyone gotten the camera working inside the captive portal on iOS? Thanks!

In WWDC26 video "Camera and Photo Technologies Group Lab", @14:17, Brad Ford mentions that we can use isCinematicVideoCaptureEnabled on videoDeviceInput to display depth blur on camera preview, even on a photo camera app. However, when I turn it on for depth mode, the API tells me that it is not supported with the current camera, which is Dual or Dual Wide cameras I use for depth. Since there are no other resources on this, I would love to get some guidance on how to do this. I just want to display depth blur on camera preview, that is it.

I want to: Run ARKit on the main rear camera, and while it's running shoot high resolution pictures on the wide camera, without disturbing the AR tracking. Is this possible?

I have created code for iOS that allows me to start and stop video acquisition from a proprietary USB camera using AVFoundation's AVCaptureSession and AVCaptureDevice APIs. There is a start and stop method. The start method takes an argument to specify one of two formats that I use for my custom camera application. I can start the session and switch between formats all day without any errors. However, if I start and then stop the camera three times in a row, on the third invocation of start, I get errors in the console output and the CMSampleBuffers stop flowing to my callback. Additionally, once I get AVFoundation into this state, stoping the camera doesn't help. I have to kill the app and start over. Here are the errors. And below these, the code. I'm hoping someone who has experience with these errors or an engineer from Apple who knows the AVFoundation image capture pipeline code, can respond and tell me what I'm doing wrong. Thanks. <<<< FigCaptureSourceRemote >>>> Fig assert: "! storage->connectionDied" at bail (FigCaptureSourceRemote.m:235) - (err=0) <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:558) - (err=-16453) <<<< FigCaptureSourceRemote >>>> Fig assert: "! storage->connectionDied" at bail (FigCaptureSourceRemote.m:235) - (err=0) <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:253) - (err=-16453) <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:269) - (err=-16453) <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:511) - (err=-16453) Capture session error: The operation could not be completed Capture session error: The operation could not be completed func start(for deviceFormat: String) async throws -> AnyPublisher<CMSampleBuffer, Swift.Error> { func configureCaptureDevice(with deviceFormat: String) throws { guard let format = formatDict[deviceFormat] else { throw Error.captureFormatNotFound } captureSession.beginConfiguration() defer { captureSession.commitConfiguration() } try captureDevice.lockForConfiguration() captureDeviceFormat = deviceFormat captureDevice.activeFormat = format captureDevice.unlockForConfiguration() } return try await withCheckedThrowingContinuation { continuation in sessionQueue.async { [unowned self] in logger.debug("Start capture session for \(deviceFormat): \(String(describing: captureSession))") // If we were already steaming camera images from a different mode, terminate that stream. bufferPublisher?.send(completion: .finished) bufferPublisher = nil captureDeviceFormat = "" do { // Re-configure with the new format; should be harmless if called with the currently configured format. try configureCaptureDevice(with: deviceFormat) // Return a new stream publisher for this invocation. bufferPublisher = PassthroughSubject<CMSampleBuffer, Swift.Error>() // If we are not currently running, start the image capture pipeline. if captureSession.isRunning == false { captureSession.startRunning() } continuation.resume(returning: bufferPublisher!.eraseToAnyPublisher()) } catch { logger.fault("Failed to start camera: \(error.localizedDescription)") continuation.resume(throwing: error) } } } } func stop() async throws { try await withCheckedThrowingContinuation { continuation in sessionQueue.async { [unowned self] in logger.debug("Stop capture session: \(String(describing: captureSession))") // The following invocation is synchronous and takes time to execute; // looks like a stall but you can ignore it as the MainActor is not blocked. captureSession.stopRunning() // Terminate the stream and reset our state. bufferPublisher?.send(completion: .finished) bufferPublisher = nil captureDeviceFormat = "" // Signal the caller that we are done here. continuation.resume() } } }

When scanning a FIDO QR code within an iOS app—whether using a custom AVFoundation (AVCaptureSession) implementation or DataScannerViewController—the system displays a native OS confirmation prompt. However, scanning the same QR code using the native system Code Scanner bypasses this prompt entirely. As a developer: Is there a way to suppress or avoid this native prompt when using custom in-app scanners? Alternatively, can I programmatically invoke the system Code Scanner directly from my app and have it deep-link back to the app once the scan is complete?

When switching from RealityView’s .spatialTracking camera mode to .virtual camera mode, the camera’s orientation relative to the scene is preserved permanently with no way to reset to default World-Up orientation. Since .spatialTracking’s camera mode will always have a non-default orientation, switching to .virtual camera mode ensures that the cameras’s ‘UP’ direction will never match the device display’s ‘UP’ direction as is default. This is especially noticeable when using .orbit camera controls, as the orbit’s UP direction matches the scene, not camera, and all rotation directions give unexpected results. Expected: When setting virtual camera mode after using spatialTracking camera mode, either 1. The Virtual Camera orientation returns to default (world up). Or 2. A 'content.camera.resetOrientation()' call is made available which resets the RealityView camera to default orientation. Reality: Switching from .spatialTracking -> .virtual camera mode permanently locks the .virtual camera’s orientation the final frame of the .spatialTracking camera’s rotation (relative to the RealityView content scene). One imperfect workaround is to reset / rebuild the entire RealityView after changing modes (by resetting .id() or otherwise. This is not ideal as it causes everything inside the make closure to rerun, which not only is a performance & time cost, visually incurs a flicker and can also be problematic with managing increasingly complicated views. Another imperfect alternative is to use more than one RealityView - which is not ideal as it incurs double the base ram usage, significantly increases code, and seemingly goes against the intent of being able to change the camera .virtual/.spatatialTracking mode at will. Code Sample: import SwiftUI import RealityKit struct RKSpatialVirtualToggle: View { @State var showAR: Bool = false var body: some View { RealityView { content in let cube = ModelEntity(mesh: .generateBox(size: 0.25), materials: [SimpleMaterial()]) cube.position.z = -1 content.add(cube) content.camera = showAR ? .spatialTracking : .virtual content.cameraTarget = cube } update: { content in content.camera = showAR ? .spatialTracking : .virtual } .realityViewCameraControls(.orbit) VStack{ Spacer() Button("Toggle AR"){ showAR.toggle() } .buttonStyle(.borderedProminent) } } } Xcode Version: Version 26.0 (17A324) iOS Version: iOS 26.5 (23F75) Tested on devices, iPhone 12 Pro, iPhone 15 Pro

I made CameraExtension and installed by OSSystemExtensionRequest. I got success callback. I did uninstall old version of my CameraExtension and install new version of my CameraExtension. "systemextensionsctl list" command shows "[activated enabled]" on my new version. But no daemon process with my CameraExtension is not running. I need to reboot OS to start the daemon process. This issue is new at macOS Sonoma 14.5. I did not see this issue on 14.4.x

I am working on a computational photography research project involving multi-exposure HDR reconstruction using Bayer RAW and Apple ProRAW captures. I would like to clarify the radiometric interpretation of Apple ProRAW and the availability of Bayer RAW capture through AVFoundation. My questions are: On current iPhone Pro devices, is it possible for third-party apps to capture and export true Bayer-pattern RAW DNG files through AVFoundation, rather than Apple ProRAW linear DNG files? If so, which availableRawPhotoPixelFormatTypes correspond to Bayer RAW, and what device or format restrictions apply? Apple ProRAW appears to be demosaiced and computationally processed, and may include multi-frame fusion. Is the decoded ProRAW image intended to be radiometrically linear and scene-referred? For a bracketed ProRAW sequence captured with fixed ISO, white balance, lens, and focus, but different exposure times, can one assume that the decoded linear pixel values Y_i(p) satisfy an exposure-proportional model in non-saturated regions, such as Y_i(p) ≈ t_i R(p), across brackets? This question is about radiometric consistency for algorithmic use, not about visual editing or tone mapping. Thank you for your help.

I’m seeing a reproducible system-level Camera crash/termination on iPhone Air running iOS 26.4.2. Steps to reproduce: Press Camera Control to launch the Camera app. Tap the lower-left thumbnail to enter the recent photo view. Browse photos, or tap Edit and start cropping a photo. The Camera/Photos flow unexpectedly exits and returns to the Home Screen or widget view. Additional detail: The issue can happen whether or not a new photo is taken after launching Camera with Camera Control. In other words, using Camera Control as a shortcut into Camera, then tapping the lower-left thumbnail to browse photos, can trigger the issue. Sometimes it happens while only browsing photos, without entering Edit. Expected result: The photo viewer/editor should stay open and allow normal browsing or cropping. Actual result: The flow exits unexpectedly. Mac Console evidence: Around 2026-05-12 21:53:59-21:54:00, Console showed SpringBoard/RunningBoard terminating com.apple.camera. Relevant log excerpt: Capture Application Requirements Unmet: "AVCaptureEventInteraction not installed" reportType: CrashLog ReportCrash Parsing corpse data for pid 94087 com.apple.camera: Foreground: false Storage is sufficient. Restart/reset-style support steps have already been tried and did not resolve the issue. This appears specific to the Camera Control launch path, not normal Photos app browsing. Has anyone else seen this on iOS 26.x, or is this a known Camera Control / AVCaptureEventInteraction regression? Already Filed as FB22766094.

Hi, I'm looking for some clarity around hardware implementation details for the Iphone 17 Pro / Pro Max's camera sync via SMPTE ST2139. Question 1 (Signaling) ST2139 specifies that on the USB connector, D+ (pin A6 and B6), D- (pin A7 and B7) SBU1 (A8) and SBU2 (B8) can be used for sync signals. Does the iphone 17 pro / pro-max support all of these per the standard, or only a subset of these pins for sync signaling? Question 2 (Frame rates) Does the Iphone 17 pro / pro-max support ST2139 sync at any / all of its video rates (24, 25, 30, 60, 100, 120 fps), or only a subset of those? Question 3 (Sync tolerances) What is the tolerance of these rates to sync variation (ie would the phone/camera accept 29.970 sync when the camera is set to 30 fps?) and what are the tolerances for jitter to maintain a good sync lock? Thanks

When interacting with RealityView’s realityViewCameraControls .orbit and setting a new RealityViewCameraContent .cameraTarget, the resulting camera target and camera orbit is incorrect. This can be demonstrated where one finger is orbiting the RealityView, and another pushes a button which changes the camera target. Instead of the camera facing the new target, some point in the scene is the new effective camera target and orbit point. This only occurs when an orbit interaction is currently taking place. If you stop interacting with the orbit, change target, then start orbit interacting again, everything works as expected. Though this example uses two-touches, any change of the camera target has this conflict with orbit interaction. This means interacting with orbit will result in the wrong camera view which is unexpected for users and difficult to reconcile or detect, for developers. Expected: Interacting (orbiting) the scene while setting a new camera target with the buttons on screen (at the same time), the camera’s new target shows centred in view the orbit revolves the new target and continues to match my gestures. Reality: Interacting (orbiting) the scene while setting a new camera target with the buttons on screen (at the same time), the camera’s new target is not centred in view, and camera is now orbiting an unexpected point in the scene, that is not my expected target. One imperfect workaround is to force a rebuild of the view after setting a new cameraTarget. This sets all targets correctly but results in a flicker, loss of orbit controls until re-touch and ultimately is a poor user experience, but is better than the wrong target being shown unexpectedly. Code Sample: import SwiftUI import RealityKit struct RKOribtTarget: View { @State private var target: Int = 0 @State private var rcContent: RealityViewCameraContent? @State private var rkID: UUID = UUID() let root = Entity() let center = ModelEntity(mesh: .generateSphere(radius: 0.05), materials: [UnlitMaterial(color: UIColor(.gray.opacity(0.5)))]) let red = ModelEntity(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .red, isMetallic: false)]) let blue = ModelEntity(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .blue, isMetallic: false)]) let green = ModelEntity(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .green, isMetallic: false)]) var body: some View { VStack{ RealityView { content in red.position.x = 0.5 blue.position.z = 0.5 green.position.y = 0.5 center.position = .init(repeating: 0.25) content.cameraTarget = target == 0 ? root : blue root.addChild(red) root.addChild(blue) root.addChild(green) root.addChild(center) content.add(root) } update: { content in switch target{ case 0: content.cameraTarget = root case 1: content.cameraTarget = blue case 2: content.cameraTarget = red case 3: content.cameraTarget = green default: content.cameraTarget = root } } .id(rkID) .realityViewCameraControls(.orbit) VStack{ Text("Target") Button("Default") { target = 0 // Force rebuilding view resets orbit target and rotation // But shows a flicker, interaction requires touch reset // Not an ideal workaround // rkID = UUID() } .buttonStyle(.bordered) Button("Blue") { target = 1 // rkID = UUID() } .buttonStyle(.bordered) .tint(.blue) Button("Red") { target = 2 // rkID = UUID() } .buttonStyle(.bordered) .tint(.red) Button("Green") { target = 3 // rkID = UUID() } .buttonStyle(.bordered) .tint(.green) } } } } Xcode Version: Version 26.0 (17A324) iOS Version: iOS 26.5 (23F75) Tested on devices, iPhone 12 Pro, iPhone 15 Pro