Using a common language between platforms, whether it’s Swift or Kotlin always sounds great on the surface but I don’t think adds the expected efficiencies when it comes to the crunch. I expect teams would always still end up with two codebases, with enough differences and workarounds to make it that you might as well just enjoy using Kotlin or Swift as you need to. Knowing two languages isn’t all that bad. Most developers learn many languages during their careers and switch between them without a thought. Just my opinion tho, I’m sure this is a good project.

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).

Kotlin and Swift are both very similar, and where they are not, we don't really want the abstraction. I agree, it's cool, but I doubt we'd use it.

I'm leaning towards Swift being the 'better' language, but even in this case, something like KMP has been around longer and is more stable.

Yes, these cross platform frameworks speed up developing easy and boring things but actively gets in the way the moment you venture out for more esoteric platform-specific features. Overall time savings is questionable, especially in the AI age where you get a lot more speedup for the easy and boring things with better documentation and more training corpus. Not recommended (from someone who made the switch back to separate native codebases), unless your app can basically be a web app anyway.

>Knowing two languages isn’t all that bad. Most developers learn many languages during their careers and switch between them without a thought.

One of the most revered programmers in my circle, who's been coding since the early 1970's asked me once, "how many programming languages do you know?". I started rattling off a few, and he stopped me. He said "I only really know the last 2 languages I used".

Jack of all trades, master of none. If someone asked me to code in PHP, Perl or any of the dozens of languages I've used in the past today, just no way. No thank you. Yeah, I used to be very proficient with lots of languages, but no way am I going dust off those brain cells. Assembly is probably the only language I can really get into on different platforms without a huge cognitive context switch, because it's just straight forward, no kooky abstractions.

That said, I've used Javascript for front-end, back-end as well as database (mongo), and it was absolutely great to not have to context switch constantly. I've also done lots of different systems with a wide variety of other languages glued together, and it hasn't been as effortless as using one language for everything. YMMV.

Knowing two or more languages is kind of liberating even. People love shiny but there are no shortcuts in this case.

Also, given <waves hands at everything>, I’d never consider becoming even more dependent on some big bad corp. And even if one is to put that aside somehow, Swift is a painful language … would be such a self own to have to use it even in places you’re not forced to.

Which is what we're doing. The moment your app isn't some webview react crap and start using any non basic (or even basic) features you end up with two codebases. For example, anything using foreground services or requiring runtime permissions.

The only framework i found that really bridges the gap is B4X, but you still need to have two separate projects, because of services, and #if blocks for the things the framework doesn't abstract (which, to be frank, is really just advanced uses of peripherals and libraries)

The two OS' are just so fundamentally different.