Update: I have now tested the same demo version (0.1.0, build 1) on a physical iPhone 17 Pro Max running iOS 26.4.1 (23E254). Two independent probe runs succeeded in all four tested configurations. The app configures only activeLockedVideoFrameDuration; it does not call follow(_:videoFrameDuration:delegate:) or configure any external synchronization device. This is a test of the standalone lock, with no external genlock reference. Capture setup: one physical rear .builtInWideAngleCamera, one AVCaptureSession, one AVCaptureVideoDataOutput, 8-bit SDR 420v, manual exposure approximately 2 ms, auto video frame rate disabled, no multicam or spatial-video output. The following are actual public-API readbacks after configuration and a settling period: Format FPS Supports Locked Active duration Frames R1 / R2 1920 x 1080 30 true true 1/30 s 32 / 33 1920 x 1080 60 true true 1/60 s 64 / 64 3840 x 2160 30 true true 1/30 s 32 / 33 3840 x 2160 60 true true 1/60 s 64 / 65Both runs have the displayed support, lock state and active duration. The requested duration was 1/30 s for 30 fps or 1/60 s for 60 fps, matching the active-duration readback. Common log values for all eight results: input.isLockedVideoFrameDurationSupported = true device.minSupportedLockedVideoFrameDuration = CMTime(value: 1, timescale: 60) input.activeLockedVideoFrameDuration = requested duration (exact rational readback) device.isVideoFrameDurationLocked = true device.isAutoVideoFrameRateEnabled = false targetAllowed = true configurationError = nilFrame counts above only demonstrate delivery during the scheduled diagnostic window; they are not precise frame-rate measurements. These probes establish that the standalone API can be enabled and frames are delivered. They do not establish long-term locked capture timing, optical exposure accuracy, or synchronization between phones. A separate short recording was in ordinary mode, so I am not using that recording's timestamps to claim locked-mode precision. For comparison, the earlier iPhone 16 Pro / iOS 26.2 (23C55) tests with the same demo version and four capture configurations returned: input.isLockedVideoFrameDurationSupported = false device.minSupportedLockedVideoFrameDuration = kCMTimeInvalid input.activeLockedVideoFrameDuration = kCMTimeInvalid device.isVideoFrameDurationLocked = falseBoth the phone model and OS version differ in this comparison, so these results alone cannot determine whether the iPhone 16 Pro restriction is hardware-dependent or OS-dependent. Could Apple clarify whether this is the expected model boundary, and whether any released OS version enables the standalone lock on iPhone 16 Pro?