Would it be possible to use Go for this? That compiles to native code, although it does include a much more significant runtime than C, it's safer than C or C++, and it's famously easy for developers to pick up as as second language.
Probably not very well, as these solutions typically involve FFI, and integrating thw runtimes would be a big pain. On the other hand, Rust is ideally suited foe this use case. Personally I'd love to see a Rust + react-native combo.
Multiple event loop integration is something projects get to very late in their lifecycle, if they ever get to it at all. Tokio is no exception: https://github.com/tokio-rs/tokio/issues/2443
When I used to write more networking C code, I used to be careful to write my libraries to be event loop agnostic. And if my library had its own event loop, I made sure that it could be stepped independently so it could sit atop another application event loop. This is alot easier on modern Unix systems because kqueue and epoll can be stacked--you can poll a kqueue/epoll descriptor from another kqueue/epoll descriptor, so sockets, timers, etc registered with the first will bubble up to the parent and your library-specific event loop can just export a single file descriptor to be polled by another event loop.[1] Windows doesn't have such a capability so there's no simple way to bubble events.
Of course, you can run your different event loops in different threads, but then you have to deal with the nightmare of shared data multithreading. Rust makes multi-threading "fearless" because it heavily restricts multiple threads from holding references to the same object, so Rust doesn't help in this regard, especially considering you're integrating with non-Rust code and, worst of all, GUI APIs, which tend to be some of the most inscrutable and hostile code with which to integrate.
[1] This is effectively structured concurrency as a first-class kernel interface, an elegant characteristic of kqueue and epoll that is sorely underappreciated and rarely used.
The thing with C and C++, is that they are part of the SDK, anything else is on you to improve the development experience, integrate libraries, or debug FFI issues.
Not easy because they must also be willing to endure the 2nd class tooling that Google creates for C and C++ on the platform, on top of the usual development issues.
But still, it is much enjoyable than using any other framework that adds even more layers to the puzzle.