Skip to content

🚨 Crash on iOS due to preventAppSwitcher being called off the main thread #88

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
TereshchenkoVlad opened this issue Jun 11, 2025 · 2 comments

Comments

@TereshchenkoVlad
Copy link

Hi 👋

First of all — thanks for this great library!
We’re using react-native-capture-protection in a production React Native app and have encountered a crash on iOS reported by Sentry.

🔥 Crash Summary

EXC_BREAKPOINT
assertBarrierOnQueue > threading violation: expected the main thread
CaptureProtection.preventAppSwitcher

Stack trace points to:

-[FBSMainRunLoopSerialQueue assertBarrierOnQueue]
FrontBoardServices
CaptureProtection.preventAppSwitcher

This indicates that preventAppSwitcher() is internally being called from a non-main thread, which violates iOS threading rules — and results in a crash.

🧪 How to Reproduce
We’re calling:

CaptureProtection.prevent(); // only on iOS

Inside a custom hook triggered by screen focus:

useEffect(() => {
  if (isFocused) {
    CaptureProtection.prevent();
  } else {
    CaptureProtection.allow();
  }
}, [isFocused]);

No direct call to preventAppSwitcher() is made, so we suspect it's invoked internally in prevent().

✅ Suggested Fix
Ensure that any UI-sensitive native calls (such as preventAppSwitcher) are always dispatched on the main thread — e.g.:

Objective-C

dispatch_async(dispatch_get_main_queue(), ^{
  [self preventAppSwitcher];
});

Swift

DispatchQueue.main.async {
  self.preventAppSwitcher()
}

📱 Environment

  • react-native: [0.75.4]
  • react-native-capture-protection: [2.0.7]
  • Platform: iOS
  • iOS version: e.g. 18.5

📝 Notes
As a workaround on JS side, we’ve temporarily wrapped our calls in InteractionManager.runAfterInteractions() or setTimeout(..., 0) to ensure execution timing, but this should ideally be handled in native code for reliability.

Let me know if I can help test or contribute a fix. Thanks again for your work on this lib! 🙏

@wn-na
Copy link
Owner

wn-na commented Jun 11, 2025

hello. @TereshchenkoVlad

Thanks for the bug repot.

I'll check it out and get back to you!

@wn-na
Copy link
Owner

wn-na commented Jun 13, 2025

@TereshchenkoVlad hi I've checked and it's not guaranteed to run on the main thread in our internal implementation. i fixed it and released it in 2.0.9. so can you try it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants