My team owns an Android (Kotlin) and iOS (Swift) app. The app is responsible for processing data, submitting to ML models, and then displaying results in a UI. We chose to do a lot of that processing in a shared Rust component. What we have found is a high overhead of bridging Kotlin/Swift to Rust. Some core logic has also seeped into our bridging code resulting in some duplication (exactly what we were trying to avoid).
With that, those of you who have found yourselves in similar situations, which language would you choose to be shared between your Android and iOS app (if any)?
Share your design specs only, and let each platform team write the implementation in the language that they think best.
Yes, you'll have two teams spending time on doing the same thing. However, you'll get important benefits.
Each team will be able to implement appropriately for their platform. While iPhones and Android phones are rather similar in terms of capability, the interaction models have a lot of differences, and forcing a common component often results in non-native feeling apps. Users will be at best confused, and at worst insulted by this.
Additionally, when you have two teams working on similar problems, they can help each other. Training on this interaction with things known to be pretty much the same helps people realize they can do it with things that aren't obvious. Meeting on a regular basis to discuss things that worked/didn't on the various platforms will help them all.
It is part of both SDKs, you have direct support for mixed mode debugging on the IDEs.
No need of extra tooling.
On Android JNI is always going to be a pain, but at least with C++ Studio gives you an hand on accessing JNI APIs.
Javascriptcore is a lightweight way to execute JavaScript on iOS and you can use V8 context or duktape on Android. This way you can also update code in your app without an app store update.
This won't suit your needs for processing-heavy apps (though can WebWorkers help), but will work well for many apps (https://csform.com/top-10-apps-built-with-ionic-framework/ for a "top 10" list for examples).
I noticed after submitting that you mentioned machine-learning. Any reason you can't offload that to a web API and take the load off the client?
Main advantages are
* kotlin is a nice language with good type support
* has good swift bindings out of the box
* also compiles to js and cpp so we can use it in our Web product as well
Pros:
1. Sharing native APIs with JS runtime and vice versa, was well supported & trivial to implement.
2. Easy to find skill-set.
3. We can run the same code in browsers as well.
Cons:
1. The app will be slightly heavier in Android (as V8 has to be bundled with the app. iOS allows using native JsCore runtime.)
2. The shared code runs slower (Obvious, because dynamic language).
Our requirements are probably a bit different than yours, though, because we're shipping a tool for app developers rather than the app itself. In particular, Objective-C was chosen over Swift because we didn't want to risk potential conflicts if our customers were using a different version of Swift and/or have to bundle a Swift runtime for older iOS versions.
with the Adobe AIR runtime you will be able to publish to iOS, Android, Windows and macOS, see "Adobe AIR" [0]
ActionScript is something similar to TypeScript
you will have access to the whole Flash stack and more, see "Building Adobe AIR Applications" [1]
with ActionScript Native Extension (ANE) you will be able to add your native code with an easy to use AS3 interface, see "Extending Adobe AIR" [2] and "Using native extensions for Adobe AIR" [3]
Note, the latest Adobe AIR SDK are now maintained by Harman [4]
[0] https://www.adobe.com/products/air.html
[1] https://help.adobe.com/en_US/air/build/index.html
[2] https://www.adobe.com/devnet/air/articles/extending-air.html
[3] https://help.adobe.com/en_US/air/build/WS597e5dadb9cc1e0253f...
It comes with some restrictions and is still deemed experimental. But it could be a viable choice in the days to come.
Your business logic should be, to the maximum extent, implemented once on the server. Your client implementations should simply display what the server has computed, once. Caching it is fine, rendering it locally is fine for the most part, and you get a clean, well-fitted, elegant UI for it.
Any limited amounts of business logic that must be correct and truthful should be implemented as a Rust (or if you insist, a limited, well-defined subset of C++) library with C linkages and idiomatic wrappers for iOS and Android. If this can be shared with the server and/or web front-end (via emscripten for instance), it should be. It's usually painful to do this, but there's usually only a small part of your codebase that should fall under this section.
Make your core logic in C++ and write bridges for Kotlin and Swift, where only the UI logic is involved. C++ has the better ecosystem so far and the very modern standard (C++17) let you write robust code. There are also so many tools that help you catch errors and typos, plus thousands of libraries available.
https://academy.realm.io/posts/swift-on-android/
https://blog.readdle.com/why-we-use-swift-for-android-db449f...
I'm leaning towards using [Meteor](https://www.meteor.com/) to share code between mobile apps and web apps.
Using cordova shells is pretty neat for business applications. Would be interested in thoughts.
https://hacks.mozilla.org/2019/04/crossing-the-rust-ffi-fron...
I would like to avoid C++ and so far the best candidate seems to be Nim. It transpiles to C which then can run in pretty much any platform.
I prefer the Object Pascal side but the C++ side is also powerful because it solves some of the problems that the Dropbox team talked about in their "The (not so) hidden cost of sharing code between iOS and Android" article.
However, a lot of the tooling around this is experimental, so you might want to tread carefully here.
Delphi is not cheap, but in my case the time to market, and tight release dates make it worth.
www.embarcadero.com/products