iOS: Camera black screen when using image_picker on a screen_protector secured window (regression in 1.5.1)

[thato-codes-4-fun]

Environment

• screen_protector: 1.5.1
• image_picker (system UIImagePickerController)
• iOS only (Android unaffected)
• Flutter

Summary

After updating screen_protector to 1.5.1, opening the camera via image_picker
results in a black screen and the flow cannot complete. The app freezes and no
photo is captured.

Reproduction condition

This only occurs when screenshot protection is actively enabled. It did NOT
reproduce in our QA environment because protection was disabled there — making
it a production-only failure that is easy to miss in testing.

Root cause (investigated)

The 1.5.1 refactor to an overlay-based implementation (away from the previous
hack-based approach), combined with the UIScene lifecycle changes in 1.4.10 and
the window recreation in 1.4.8, puts the app window into a secured state that
UIImagePickerController cannot handle.

AVFoundation logs showed:

• FigXPCUtilities / FigCaptureSourceRemote errors
• Portrait/device mode issues
• Invalid frame dimensions

Notably, even temporarily disabling protection immediately before opening the
camera did not resolve it — the window state was already corrupted.

Workaround

Replaced image_picker with the camera package (AVCaptureSession + custom UI)
for iOS production builds. This bypasses UIImagePickerController entirely and
is not affected by the secured window state.

Related

Similar black screen regression reported in #61 (triggered by returning from
external link rather than opening camera — likely the same underlying cause).

[Ming6957]

What's the current situation? Can we only avoid the problem by switching to a camera bag?

[gustov3n]

Got similar issue when used with image_picker but the app crashed instead. Here how i reproduce it :

• Call ScreenProtector.preventScreenshotOn()
• While the prevent screenshot is on, force close the app (clear from recent apps)
• Open the app again and call ImagePicker().pickImage(source: ImageSource.gallery). Doesn't need to choose any image though.
• Call ScreenProtector.preventScreenshotOn() again
• The app crashed

Current workaround is by calling ScreenProtector.preventScreenshotOn() then ScreenProtector.preventScreenshotOff() everytime BEFORE calling image picker. This seems like 'reset' the protector stuck state. Something like this

// Call these to 'reset'
await ScreenProtector.preventScreenshotOn();
await ScreenProtector.preventScreenshotOff();

final image = await ImagePicker().pickImage(source: ImageSource.gallery);

// Now it won't crash anymore
await ScreenProtector.preventScreenshotOn();

[AlimFreight]

We hit this in production (screen_protector 1.5.1, Flutter 3.47.4, iOS 26.6.2) and traced the mechanism with an instrumented build. The black screen is the root FlutterView being left at 0×0 while Flutter keeps rendering into it.

What happens

1. preventScreenshotOn() makes ScreenPreventerKit move the root FlutterView into _UITextLayoutCanvasView inside ScreenshotProtectionOverlay, pin it with 4 superview constraints, and set translatesAutoresizingMaskIntoConstraints = false on it. A swizzled setter caught the call:

FLUTTER VIEW TAMIC true -> false  superviews=_UITextLayoutCanvasView < ScreenshotProtectionOverlay
  1   Runner              (swizzled setter)
  2   ScreenPreventerKit  __swift_destroy_boxed_opaque_existential_1 + 1236
  3   ScreenPreventerKit  __swift_destroy_boxed_opaque_existential_1 + 316
  4   ScreenPreventerKit  _ZN5swift19MutexPlatformHelper7destroyER16os_unfair_lock_s + 204
  ...
  9   ScreenPreventerKit  __swift_destroy_boxed_opaque_existential_1 + 4484
  14  libdispatch.dylib   _dispatch_main_queue_callback_4CF + 44

2. A full-screen presentation from the root view controller (for us: VisionKit's VNDocumentCameraViewController and QLPreviewController) moves the view out of the overlay into UITransitionView. The overlay's constraints no longer apply and autoresizing is still off, so the next layout pass sizes the view 0×0.
3. After dismissal the view is left in UIDropShadowView < UITransitionView < UIWindow, still at 0×0 and still with the flag false. Nothing ever sets it back to true. Backgrounding and reopening the app does not recover it.

This looks like the same root cause as #61 and prongbang/ScreenProtectorKit#11 (SFSafariViewController is another full-screen presentation).

Host-app workaround

Subclass FlutterViewController, make it the root class in Main.storyboard (customClass="RunnerViewController" customModule="Runner" customModuleProvider="target"), and repair the view only in the broken state:

class RunnerViewController: FlutterViewController {
  override func viewDidLayoutSubviews() {
    if let v = viewIfLoaded, let host = v.superview,
       v.bounds.isEmpty, !host.bounds.isEmpty,
       !v.translatesAutoresizingMaskIntoConstraints {
      v.translatesAutoresizingMaskIntoConstraints = true
      v.autoresizingMask = [.flexibleWidth, .flexibleHeight]
      v.frame = host.bounds
    }
    super.viewDidLayoutSubviews()
  }
}

We verified the repair on a device in a diagnostic build, where it ran from a timer: the view came back to full size and stayed there through later Quick Look presentations. The layout-pass version above is what we are shipping.

Suggested fix in the library: when the view leaves the overlay, or when protection is turned off, restore the view's original translatesAutoresizingMaskIntoConstraints and autoresizingMask and size it to its new superview.

Note that 1.5.3 still pins ScreenProtectorKit 1.5.1 on iOS, so it is affected too.