jhugman / uniffi-bindgen-react-native

A uniffi bindings generator for calling Rust from react-native
https://jhugman.github.io/uniffi-bindgen-react-native/
Other
46 stars 5 forks source link

Generate Kotlin and Swift at the same time as generating TS/C++ #149

Open jhugman opened 2 weeks ago

jhugman commented 2 weeks ago

@zzorba has been asking for this for a lilttle while.

While the main React Native app requires typescript and C++, iOS extensions still require Swift.

Can we generate the Swift from the Rust at the same time as generating the Typescript and C++?

This issue just covers the generating and building of the Kotlin and Swift generation.

@almost adds this question: can we run the Kotlin and Swift bindings at the same time as the Typescript? This enables a host of new capabilities.

zzorba commented 2 weeks ago

I believe you can run the bindings at the same time, though I do not know if they share the process state or not (I would assume they would, but I'm just not sure since it hasn't been our need).

Our app uses the Swift bindings in our NotificationExtension and the typescript bindings in the foreground app. They both share the same data store (sqlite) for coordination.

jhugman commented 2 weeks ago

I believe you can run the bindings at the same time, though I do not know if they share the process state or not (I would assume they would, but I'm just not sure since it hasn't been our need).

Interesting.

Eyeballing the code, I was under the impression that just generating the extra bindings was necessary but not sufficient for running in the same process. I am expecting that this would require changes to how callback interfaces work.

Still, that is for another issue :)

Johennes commented 1 week ago

Don't app extensions on iOS run in their own process (and with limited system resources) anyway? From what I know they can only share certain storage locations with the main app but not the same system process.

zzorba commented 1 week ago

Yes that's correct about extensions, they are isolated and only share storage and keychain access.

But theoretically you could have swift code and react native code in the library both talking to the same binary.

Not sure if it's a large use case though?

Johennes commented 1 week ago

Oh, I see what you mean now. Hm, yeah I suppose there could be a use case when you want to combine the bindings with some native APIs without having to poke out to TS and back in to another library.