djinni

Right, So is that why Discord was successful in using 'React Native' (RN) and also was able to implement the same features (Stage Channels) faster than Clubhouse (iOS only in early 2021) did for their Android users at the time? Or is that why Coinbase announced a successful transition to RN [0] given the metrics they outlined in their blogpost? Perhaps is that also why when it comes to needing high performance, the largest stock broker in India (Zerodha) went from Native to RN and settled on using Flutter? [1] Why didn't they go back to native then? The problem with this article is that it is from an unrealistic and absolutist perspective. Just look at this nonsense: > And if you ever need to share code between your iOS and Android apps, you can always use C++; which was the solution adopted by Dropbox for almost a decade. And a decade la

> In comparison, the Go protoc plugin is written in Go, the alternatice rust-protobuf protoc plugin is witten in Rust, the Typescript one is written in Typescript... So they're maintaining a project with two languages with Python 2 as a hard requirement for code generation? Oh dear. This tells me that this project will have the same fate as djinni [0] or their similar archived projects. [0] https://github.com/dropbox/djinni

Can concur, we had huge success sharing our core business logic as a C++ library which was then used by UI on Android/iOS/Web and even desktop native apps. Using Dropbox Djinni (https://github.com/dropbox/djinni) also helped with the horrible pain of JNI... although it's unmaintained these days. I guess people use SWiG now.

I came to the same conclusion (and I'm not a big company that can afford Qt), so I built my own. Before Flutter got a new team @ Google ~3 years back, it was a set of tools for building cross-platform apps with C++ shared libs. A few years ago, this is what many of the FAANG companies were doing with their apps. Then, React Native was released and (I guess) the management at Google decided to take a different tack. I did some research and found that Dropbox open sourced their internal tool for building cross-platform mobile apps in C++. Djinni (https://github.com/dropbox/djinni) uses an interface definition language to generate bindings between C++ & ObjC & Java (via JNI). From this, I added some tooling to help get the build setup and define some basic UI elements while trying to keep it simple. If you happen to give it a try, I'd love t

Yes, we build it natively. There are tons of native applications: sublimes, Dropbox, chromes etc... and many ways to cross-platform. I don't want to spend 2GB for every electrons app (slack, vscode, database app...) so I build TablePlus natively. Basically, I split the project into 2 pieces. Logic and Interface. The logic can cross-platform because it is pure C/C++. Dropbox does the same way with djinni: https://github.com/dropbox/djinni

>With modern C++ language features, the "complicated language with the manual memory management" a lot less obvious or necessary Not completely though, you still have to think a lot more about ownership and object lifetimes (https://www.youtube.com/watch?v=JfmTagWcqoE), which is a lot better than manual new/delete, but still not as simple as just having a GC. Plus you have to deal with lifetimes of objects proxied to Java code, where something in the Java code becomes the object's owner. Though you can use a bindings generator like djinni (https://github.com/dropbox/djinni) to handle this for you (with some tradeoffs). >Debugging is only complicated on Android It's gotten slightly better recently, but it still sucks. With Swift it's not trivial either, it's not that easy to set breakpoints into C++ code, stack traces on crashes are often

Dropbox has some mobile apps that have some fairl complex client-side logic with multithreading (https://tech.dropbox.com/2014/04/building-carousel-part-i-ho...), so they use a cross-platform C++ library with bindings to Obj-C and Java with their Djinni library (https://github.com/dropbox/djinni/)