You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
This indicates that preventAppSwitcher() is internally being called from a non-main thread, which violates iOS threading rules — and results in a crash.
📝 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! 🙏
The text was updated successfully, but these errors were encountered:
@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?
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
Stack trace points to:
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:
Inside a custom hook triggered by screen focus:
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
Swift
📱 Environment
📝 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! 🙏
The text was updated successfully, but these errors were encountered: