Consider react-native-edge-to-edge

[zoontek]

Hi Jacek 👋

First of all, thank you for the amazing work you’re doing with this library 🙏

With version 3.0.0 just around the corner—and since it will require react-native-nitro-modules—I’d like to suggest making react-native-edge-to-edge a peer dependency as well.

You’re already familiar with the challenges: detecting whether edge-to-edge is enabled is tricky, which makes migration more difficult for the React Native ecosystem.

To address this, we created react-native-is-edge-to-edge—a super lightweight helper (only 250 bytes minified, no gzip) that detects the presence of the library. Some libraries already support it, for example:

• react-native-keyboard-controller
• react-native-bootsplash
• react-native-bottom-tabs
• react-native-true-sheet (not released yet)
• expo-router

We’re actively working to bring support to more libraries as well (#1, #2, more to come).

With react-native-edge-to-edge, some issues described in the "My Android app is not edgeToEdge or insets are incorrect" section of your excellent documentation could be avoided. These libraries can detect react-native-edge-to-edge and ensure they don’t interfere.

Additionally, there’s an ongoing proposal to include edge-to-edge support in React Native core. If it’s accepted, react-native-is-edge-to-edge will be updated to detect both the core and external implementations, allowing users to simply uninstall react-native-edge-to-edge, set enableEdgeToEdge=true, and be done ✨ No extra effort will be required from users or library authors.

Looking at how Unistyles currently handles edge-to-edge, this change wouldn’t interfere with react-native-edge-to-edge at all. The only possible overlap might be the background color setter, but as I understand, that will be removed in v3 since it’s deprecated and won’t work in most contexts.

That said, here are your options:

1. Require the library

By requiring react-native-edge-to-edge, you could remove the “edge-to-edge handling” part of your code and rely on the growing ecosystem of third-party libraries supporting it. This would also boost the library’s visibility and adoption, encouraging more projects to support it.

This pattern isn’t new—React Navigation, for example, requires react-native-screens and react-native-safe-area-insets, avoiding built-in solutions.

2. Detect the library

Using react-native-is-edge-to-edge (or a simple Kotlin check as explained in the documentation), you could skip redundant enableEdgeToEdge calls or avoid APIs that might conflict with the library (if you plan to introduce any).

3. Keep things as they are

As I mentioned, there’s no direct interference. If WindowCompat.setDecorFitsSystemWindows(activity.window, false) is called twice, it’s no big deal. However, if users rely on Unistyles to enable edge-to-edge, they won’t benefit from third-party library support and will need to manually handle other libraries behavior.

[jpudysz]

Yo @zoontek !

Thanks for reaching out and for your kind words! I really appreciate the effort you’ve put into making things easier for the React Native ecosystem, especially with react-native-is-edge-to-edge. I can feel the pain and I wish we had a built-in solution from Android core 😩

I’m on board with the idea of adding your lib as a dependency in the next version. It makes sense to rely on it, especially if it helps with compatibility and simplifies how edge-to-edge is handled across different libraries.

I have a few questions though:

• should I completely remove my setDecorFitsSystemWindows ?
• should I throw if there is no react-native-is-edge-to-edge class detected?
• I deprecated methods you mentioned, but I don't think I need to remove them? They can still be useful for 3-button navigation? [here] and [here] . I guess I should only remove status bar API

[zoontek]

should I completely remove my setDecorFitsSystemWindows ?

No need, react-native-edge-to-edge is also calling it's enableEdgeToEdge fn on start + when the app gain focus + when the color scheme change.

should I throw if there is no react-native-is-edge-to-edge class detected?

That's a good idea! If the user can receive a clear warning when he misses this step, go for it 🙏

I deprecated methods you mentioned, but I don't think I need to remove them? They can still be useful for 3-button navigation? [here] and [here] . I guess I should only remove status bar API

setStatusBarBackgroundColor is deprecated and disabled, so it's 100% removable. For setNavigationBarBackgroundColor, currently RN edge-to-edge ensure that eveything in this list is set:

If the user set a background color, it will be resetted when the app will regain focus / change color scheme, to follow the Android 15 default values.

Of course, I can do an update to only override the nav bar background color at app start, but this comes with another issue: if the user is able to change the nav background color, we should probably also set setNavigationBarContrastEnforced to false and add an API to manage the navigation bar style (light or dark content).

That's a lot of additional burden for a fraction of users. See my similar response here.

Ideally, the navigation bar style would always be automatic, including for the buttons navigation bar. And in this case, having it fully transparent (and not a semi-opaque white / black) would have been the way to go. But that's the path Google took, and I think they kinda want to push users to migrate to gesture navigation too (I wouldn't be surprised if the buttons navigation option disappear in a future version of Android 😅)

[jpudysz]

Thanks for the response, I will implement it later today 🙏🏼

[jpudysz]

Shipped with beta.1!