But it does allow engineers, trained on one platform, to work on the other.

Long ago, I took a few months, and learned Android programming (using Java, which was the native choice, back then). I ended up not really enjoying it, and eventually abandoned it, but my goal was to write fully-native Android.

I’m a big believer in fully-native development. I’ve worked with cross-platform frameworks for decades, and have never enjoyed any significant success.

For that reason, I’m a bit skeptical of the chances for this framework, but admire the work and dedication that went into it. I sincerely wish them luck.

> Most developers learn many languages during their careers and switch between them without a thought.

I’ve worked with quite a few, over my 40+ years of experience, but I don’t really “switch without a thought.” There’s always a “context switch” overhead.

For example, I am currently writing a Swift app (SwiftUI), with a PHP backend. I keep switching between the two. The biggest mistake I make in PHP, is neglecting trailing semicolons. The next-biggest mistake, is not surrounding if statement evaluations in parentheses. I've been working with PHP a lot longer than Swift, but not anywhere nearly as deeply. Swift is definitely my "native" language.

My experience is that I can learn a working understanding of a language in a couple of weeks, but it takes years to really get proficient. Think someone that speaks with a heavy accent, and someone fluent.

Also, the language is often the least relevant aspect. SDKs, stdlibs, and frameworks are where most of the work lives. They can take a long time to master, and are usually “moving targets,” undergoing constant evolution (like the language, itself).

>But it does allow engineers, trained on one platform, to work on the other.

The programming language is the most surface level detail when learning a platform.

The libraries, the frameworks, the OS services, the app lifecycle, the UI idioms are the hard part, and those cannot be abstracted away (of course you can try, but you'll end up with an inconsistent mess that doesn't feel native in any of the supported platforms, at which point you should just create a website).

> using Java, which was the native choice, back then

It still might be, as Kotlin isn't used on the lower layers below JetPack libraries, despite Google's resistance to modern Java adoption.