5 ms·

Super relevant use case: you are making an app for multiple platforms, say iOS and android. You have some common logic, but for the most part the apps are separ

Super relevant use case: you are making an app for multiple platforms, say iOS and android. You have some common logic, but for the most part the apps are separate, native apps. This would let you write the common part once, without needing to do something like drop down to c++ and then do native interop from swift and Java.

KronisLV 5y ago
If the logic is standalone (e.g. algorithms, data structures, validations etc.), then that's indeed a really good approach! But in my experience, you oftentimes have to work with libraries and ecosystem components which are platform dependent. In those cases, the cross platform code would only work when these ecosystem components are also written in that particular language. Now, it can work with Xamarin Forms, React Native or similar technologies with very specific use cases, but it feels like any other, more generic attempts at getting something like that working are doomed to fail (e.g. when you don't have a cross platform solution in place, for example, different ways to access DB on different platforms, or different ways to make web requests etc., or even interact with device capabilities or handle permissions).
skohan 5y ago
I feel like this is a use-case which sounds a lot better on paper than it actually is. Mobile apps in my experience tend to be shaped quite heavily by the system API and UI frameworks they are built on top of. When you talk about the "common part", usually this is like the networking layer and models maybe, which tends to be very simple and takes like a half hour to write in the first place. Even if there is a little duplicate work, it's still better to have the whole app implemented in the native language and frameworks, rather than having some odd bits which don't work with the same tooling for example and are harder to debug.
bsaul 5y ago
i'm exactly in this situation : have an ios swift app and wonder what's the best way to get it to android. Swift and kotlin are so similar i wonder if there isn't a possibility to generate at least the type definitions from one to the other. That would let me ensure that the code design at least stays in sync (at least for the model layer)

KronisLV 5y ago

If the logic is standalone (e.g. algorithms, data structures, validations etc.), then that's indeed a really good approach! But in my experience, you oftentimes have to work with libraries and ecosystem components which are platform dependent. In those cases, the cross platform code would only work when these ecosystem components are also written in that particular language. Now, it can work with Xamarin Forms, React Native or similar technologies with very specific use cases, but it feels like any other, more generic attempts at getting something like that working are doomed to fail (e.g. when you don't have a cross platform solution in place, for example, different ways to access DB on different platforms, or different ways to make web requests etc., or even interact with device capabilities or handle permissions).

skohan 5y ago

I feel like this is a use-case which sounds a lot better on paper than it actually is. Mobile apps in my experience tend to be shaped quite heavily by the system API and UI frameworks they are built on top of. When you talk about the "common part", usually this is like the networking layer and models maybe, which tends to be very simple and takes like a half hour to write in the first place. Even if there is a little duplicate work, it's still better to have the whole app implemented in the native language and frameworks, rather than having some odd bits which don't work with the same tooling for example and are harder to debug.

bsaul 5y ago

i'm exactly in this situation : have an ios swift app and wonder what's the best way to get it to android. Swift and kotlin are so similar i wonder if there isn't a possibility to generate at least the type definitions from one to the other. That would let me ensure that the code design at least stays in sync (at least for the model layer)