by mevorah on 10/25/19, 3:52 PM with 117 comments
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)?
by toast0 on 10/27/19, 9:05 PM
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.
by pjmlp on 10/27/19, 6:57 AM
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.
by skinnyasianboi on 10/27/19, 6:40 AM
by me551ah on 10/27/19, 6:27 AM
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.
by kerryritter on 10/27/19, 10:11 PM
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?
by mightybyte on 10/27/19, 7:27 AM
by _31 on 10/27/19, 6:59 AM
by novocaine on 10/27/19, 8:02 AM
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
by lewisjoe on 10/27/19, 7:48 AM
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).
by W0lf on 10/27/19, 6:27 AM
by JaggerJo on 10/26/19, 8:55 AM
by nfriedly on 10/28/19, 3:00 PM
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.
by njsubedi on 10/27/19, 7:58 AM
by zwetan on 10/27/19, 9:10 AM
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...
by shanth on 10/27/19, 7:21 AM
by karmakaze on 10/25/19, 11:46 PM
by tpetry on 10/27/19, 4:23 PM
by zelly on 10/27/19, 6:57 AM
by masterwok on 10/27/19, 5:37 PM
by stockkid on 10/26/19, 2:51 AM
It comes with some restrictions and is still deemed experimental. But it could be a viable choice in the days to come.
by arcticbull on 10/28/19, 12:47 AM
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.
by mister_hn on 10/28/19, 10:01 AM
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.
by jamil7 on 10/26/19, 5:26 PM
by mojuba on 10/27/19, 8:09 AM
https://academy.realm.io/posts/swift-on-android/
https://blog.readdle.com/why-we-use-swift-for-android-db449f...
by santa_boy on 10/28/19, 2:20 AM
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.
by cpeterso on 10/27/19, 10:10 PM
https://hacks.mozilla.org/2019/04/crossing-the-rust-ffi-fron...
by pier25 on 10/27/19, 11:44 PM
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.
by omonien on 10/29/19, 11:42 AM
by fmxexpress on 10/29/19, 2:12 PM
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.
by shams93 on 10/25/19, 4:06 PM
by pcstl on 10/28/19, 3:01 PM
However, a lot of the tooling around this is experimental, so you might want to tread carefully here.
by enjoiful on 10/28/19, 5:42 PM
by rsecora on 10/28/19, 11:03 AM
Delphi is not cheap, but in my case the time to market, and tight release dates make it worth.
www.embarcadero.com/products
by cerberusss on 10/25/19, 7:10 PM
by earenndil on 10/27/19, 6:46 AM
by gagabity on 10/28/19, 1:36 AM
by StreamBright on 10/27/19, 7:48 AM
by gok on 10/27/19, 7:05 AM
by timwaagh on 10/28/19, 12:51 AM
by aaronbrethorst on 10/27/19, 7:29 AM