disablePreventScreenshot() leaves residual overlay causing black screen with SFSafariViewController (v1.5.1)

[smcaman]

• Environment:
  iOS, Flutter app, ScreenProtectorKit 1.5.1 via CocoaPods, Using it in flutter through method channel

   [✓] Flutter (Channel stable, 3.41.2, on macOS 26.2 25C56 darwin-arm64, locale en-IN)
   [✓] Android toolchain - develop for Android devices (Android SDK version 36.1.0-rc1)
   [✓] Xcode - develop for iOS and macOS (Xcode 26.2)
   [✗] Chrome - develop for the web (Cannot find Chrome executable at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome)
   ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.
   [✓] Connected device (3 available)
   [✓] Network resources
  

• Steps to reproduce:
  Call enabledPreventScreenshot()
  Call disablePreventScreenshot()
  Present SFSafariViewController (via ChromeSafariBrowser / flutter_inappwebview)
  Dismiss the Safari view controller
  Black screen appears — Flutter view doesn't redraw

• Workaround:
  Pinning to 1.4.2 resolves the issue

• Code:
  // Initialize Flutter method channel for secure screenshot control
  let controller : FlutterViewController = window?.rootViewController as! FlutterViewController
  methodChannel = FlutterMethodChannel(name: "secureChannel", binaryMessenger: controller.binaryMessenger)
  screenProtectorKit = ScreenProtectorKit(window: window ?? UIWindow())

    // Configure prevention (initial setup)
    screenProtectorKit?.configurePreventionScreenshot()
  
    methodChannel?.setMethodCallHandler { [weak self] (call, result) in
        guard let self = self else { return }
        switch call.method {
            case "disableTakingScreenshot":
                self.screenProtectorKit?.enabledPreventScreenshot()
                result(true)
            case "enableTakingScreenshot":
                self.screenProtectorKit?.disablePreventScreenshot()
                result(true)
            default:
                result(FlutterMethodNotImplemented)
        }
    }
  

[rock-redotpay]

Hi @prongbang,

We are also experiencing this issue in a production Flutter app using ScreenProtectorKit / screen_protector.

The problem appears consistently on:

• iOS 26+
• Flutter projects using SceneDelegate
• apps with multiple UIWindow / FlutterEngine lifecycle transitions

Current behavior causes:

• black screen / gray overlay
• invalid screenshot protection state
• occasional rendering issues after app background/foreground transitions

[smcaman]

@rock-redotpay You can try the workaround

Pinning to v1.4.2 resolves the issue in pod file.

Hope this fix you issue until the actual fix release.

[rock-redotpay]

@smcaman Version 1.4.2 does not support multiple windows and has crash issues.

[smcaman]

@rock-redotpay Thanks for confirming this is happening on your end too.

Regarding 1.4.2 not supporting multiple windows — understood. In our case we found an additional root cause on our side: we had .then() callbacks on Navigator push calls that were re-enabling screenshot protection (enabledPreventScreenshot()) after the OTP screen popped, leaving the protection ON when the user reached the main screen. When SFSafariViewController dismissed over a window with the secure overlay still active, it caused the black screen.

So the issue is twofold:

1. App-side: If you call enabledPreventScreenshot() and don't call disablePreventScreenshot() before presenting SFSafariViewController, the black screen occurs on dismiss.

2. (I'm not sure) Library-side (1.5.x): Even after calling disablePreventScreenshot(), the internal ScreenPreventerKit xcframework doesn't fully clean up the secure overlay from the view hierarchy. In 1.4.x this cleanup was handled properly.
   Since ScreenPreventerKit is a closed-source xcframework, we can't debug or fix the actual cleanup logic. @prongbang would need to address this in the binary.

As a workaround if you can't use 1.4.2: make sure disablePreventScreenshot() is always called before presenting any external view controller (SFSafariViewController, ASWebAuthenticationSession, etc.), and avoid rapid enable/disable cycles in the same navigation flow.