JNI is so expensive when cross the language barrier, you have to be conscious to constantly minimize your API exposure. This may be helpful in long-term, but no

JNI is so expensive when cross the language barrier, you have to be conscious to constantly minimize your API exposure. This may be helpful in long-term, but not helpful for onboarding purposes. On the other hand, if you can lower Kotlin to native code, it may be more natural to interact with (of course, there are still these nonsense of Java's default UTF-16 string <-> Swift's native UTF-8 string conversion). Interoperability between high level languages are just hard. I am skeptical of either way, but I can see how it is more appealing to go from Kotlin to Swift direction. On the other hand, data modeling and high-level data transformation doesn't require all language features. It is possible to do such with a limited DSL that supports product / sum types, some filter / map / flatmap / zip, and boom, you now have your view models for UI rendering. As long as we've made up our mind on string UTF-16 / 8 or have some performant library to do lazy transformation on these. We can go a long way on standardize business logic cross iOS / Android platform.