Is Nat/J only usable from MOE? Would it be useful at all outside of MOE? Like from Kotlin/Native.
I guess Nat/J is designed for JVMs.
Hey Gergely,
are there any news now? I am really worried about not being able to update my app in the future because many libraries are dropping ObjC support since swift became so popular. It would be awesome to get swift support in MOE.
Would love to hear from you!
5 Likes
Hi, any news so far? 
2 Likes
Iām also interested in an update. I want to know if I can safely use this project in an app, or if Iām wasting my time with technology thatās getting killed off.
3 Likes
Yup, Iād also wanna know what is up. Iāve never seen a project this great with such a miserable user-support. There a tons of questions and nobody seems to take 1 minute time to answer them. Just one minute, just one simple questionā¦ makes me kind of sad.
Iāve developed a more or less successful app on ios and android with multi-os-engine and still I am kind of worried if I need to rewrite it completely after migeran slowly have let it die.
Donāt do this team Migeran. Just donāt. And leave people behind who have questions and still believe in the success of this project.
4 Likes
Hi Eugene. Have you tried Kotlin Native yet? Iād be interested to hear your experiences if you have.
Not really looking forward to converting a 100k lines of code to Kotlin. Besides, Kotlin native, while is cool, it is a beast of its own. For instance you canāt use any stuff you used in Java. So, all common classes like String, Map, etc has to be replaced with ones from Kotlin runtime library.
For that reason the new app I did in dart and flutter. No legacy code there. Though no visual UI designer is annoying (even no ugly one like xcode has).
Moe allowed to run all Java code + threads, sockets, http calls, json and html parsing and generation, sql db and bunch of other stuff as is on web, android and ios. But, unlike flutter - different UI code between android and ios.
An embedded flutter view with a moe backend, or kotlin native backend, or just the dart backend look attractive. Same UI for all.
2 Likes
I think some of the ideas about Kotlin/native are being misrepresented here.
Kotlin as a language has direct support for writing code that has different implementations on different platforms while still enforcing a common contract via its expect and actual keywords.
There are 2 ways you can make code portable:
Write a Virtual Machine or an equivalent that you package with every application so that your code can run everywhere. The pro is that you can use the entire standard library of the language, but the con is that your application is a giant monolith in ported platforms. Another con is that language users of that platform will always look at your language / portability means as second fiddle, and gaining adoption from that native crowd is very difficult. This is what Multi OS Engine does.
Kotlin/nativeās goal is to actually provide native language support as a first class citizen to the community. That means that Kotlin/native actually has the possibility of being seen as an alternative to a native language, and that it can be seen as a competitor to other native languages at similar abstraction levels, i.e. Swift. It also means that a Swift engineer is more likely to be open to developing an application with Kotlin so that they can share code between Android and iOS, as at the end of the day itās still native code. Conversations like this with native mobile developers are surprisingly uphill battles.
Kotlin/native also provides a bridge between itself and objective C, that means Kotlin can interface with ObjC / Swift code directly.
Working with Kotlin multiplatform can feel complicated at first, but after you settle into it, itās very similar to developing for a single jvm platform.