5 ms·

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 c

by bsaul 7y ago

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.

rabenblut 7y ago
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 https://kotlinlang.org/docs/reference/multiplatform.html
izacus 7y ago
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.
- alien1993 7y ago
  How do you achieve this? Are you using some framework like Qt? Or is it custom?
  - izacus 7y ago
    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.
- bsaul 7y ago
  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.
  - Aissen 7y ago
    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.
    - bsaul 7y ago
      Thanks, i completely missed that part. Very interesting solution...
  - izacus 7y ago
    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.
- madeofpalk 7y ago
vlozko 7y ago
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-cost-of-sharing-code-between-ios-and-android/ 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.
- izacus 7y ago
  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.

by bsaul 7y ago

rabenblut 7y ago

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 https://kotlinlang.org/docs/reference/multiplatform.html

izacus 7y ago

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.

alien1993 7y ago
How do you achieve this? Are you using some framework like Qt? Or is it custom?
- izacus 7y ago
  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.
bsaul 7y ago
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.
- Aissen 7y ago
  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.
  - bsaul 7y ago
    Thanks, i completely missed that part. Very interesting solution...
- izacus 7y ago
  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.
madeofpalk 7y ago

vlozko 7y ago

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-cost-of-sharing-code-between-ios-and-android/ 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.

izacus 7y ago
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.