Hacker News Reader

Comment by bsaul | Hacker News Reader

I used to be into flutter (theorically), but after seeing some bugs and performance issues, i’m now thinking the best combination would be :

- write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature)

- write native UI code using native tooling, and call the business logic library from there.

But i haven’t settled yet on the ideal PL to write that library and have it interface easily on both android and ios.

View on HN

This is the approach we took at my current and previous mobile projects and has proven to be very effective (we chose C++ due to toolchain maturity over all platforms):

- It forces you to think about your business logic vs. UI structure.

- It forces you to make your core logic library easily testable.

- Since you can deploy the core logic library anywhere, you get native, no Electron bullshit, support for pretty much all major operating systems at a cost of running a CI on all compilers to catch non-portable parts of C++ quickly.

- The users get UI that's built for their platform with it's own quirks and doesn't burn 500MB of RAM.

- Using a serializable and portable message standard (we opted for Protobufs) to communicate between logic library and UI part makes deployment to server easy as well.

Biggest issues?

- Getting inflexible people to learn anything other than JavaScript.

- Getting slow compile times under control.

- Getting CI coverage to the point where it catches developers accidentally adding Apple or Linux specific headers into codebase.

- Learning to be conservative enough to not trust the platform and ship our own libraries. Even basic ones like SQLite.

> no Electron bullshit

Electron is a UI 'framework', so bringing it up is kind of a non sequitur. Your approach of a C++ core is entirely compatible with an Electron UI.

I worked on a project that had its 'core logic' implemented in C++, which we then ran that on the web in Javascript, for the same portability reasons.

how did the java interop work for you ? I used to work in a company that used that approach with gomobile (golang) , and frankly the dark magic required to have a decent java API to the shared library made me want to not touch that with a ten foot pole.

I believe it was due to JNI but my memories may be wrong.

The answer is in the parent's comment. They used protobufs, so I guess there's no JNI, just a simple RPC over a local socket.

Thanks, i completely missed that part. Very interesting solution...

We used Dropbox' Djinni for a long while and it was good for most cases, but there were performance limitations - we switched to protobuffs over byte[] arrays for complex data later.

How do you achieve this? Are you using some framework like Qt? Or is it custom?

As the previous poster mentioned, the UI is all native and written separately for each platform. To populate UI elements you call native calls so there's no UI framework like Qt needed.

We used C++14 which has a pretty good standard library and plugged the holes with some parts of Boost and then standalone libraries like SQLite, json11 and others to provide missing functionality.

I did not have a great experience with that approach. The now (in)famous DropBox article describes why way better than I ever could: https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cos... My biggest pain points were tooling. For all of Xcode’s faults, C++ and Objective-C debugging and intermingling wasn’t one of them. Android, though, was another story.

The big thing the Dropbox article does not mention is the fact that they never really ported the Dropbox core functionality to C++ so they never reaped the benefits of sharing code in their most complex and most business logic heavy part of codebase.

We actually used their own Djinni library on one of the projects and it worked well - but even at that time the Dropbox team wasn't maintaining it at all since they never used this approach beyond the short-lived Carousel app.

This is the approach used with Kotlin multiplatform development.

I suspect it will be the best way going forward, other approaches all have serious issues.

https://kotlinlang.org/docs/reference/multiplatform.html

Reply on news.ycombinator.com