[dave_sid]

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.

[ChrisMarshallNY]

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

[meindnoch]

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

[pjmlp]

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

[muzani]

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.

[oefrha]

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.

[tcoff91]

Yes building a native app has fewer layers of abstraction and often has better DX than building with a cross-platform framework where you have to work around bugs that inevitably exist in the framework.

Cross-platform frameworks I find are more about making sure that your apps stay consistent across platforms over time as they are maintained. Features land on all platforms at the same time.

I worked on a product that had been around a long time and had a separate macOS, windows, iOS, android, and web apps. It was a big a big shit-show when product leadership wanted to make large scale changes across all platforms in unison. For that product though it really did have to be native to each platform and I don't think any cross platform framework could have worked for that particular product.

Having worked with both native apps & cross-platform frameworks, I do think there is value in cross-platform frameworks as long as the framework allows you to drop down to native platform specific code easily where needed.

When it comes to mobile, I think that React Native has some serious benefits:

- Fast refresh: incredible DX improvement to be able to just save a file and instantly see the behavior of your app update without rebuilding and reinstalling. - Server-driven UI via React Server Components (still experimental): Companies like AirBnB spend a ton of engineering effort to build their own bespoke server-driven UI frameworks. Expo Router is bringing React Server Components to native apps. - Automatic deep linking: If you also ship your app for the web using Expo Web & Expo Router, then all your links work perfectly as deep links into your app because your web app and your native app have the exact same routing. If you use next.js with solito for your web app instead of Expo Router, you can also keep your web app in lock-step with your native app without having to use Expo Router for your web app. - Over the Air Updates: You can ship changes to your apps instantly without app store review. - Can drop down to native easily: These days you can easily build an expo module or if you need really high performance build a nitro module and leverage the native platform APIs where you really need it. I mean look at react-native-vision-camera, it's so much easier to use than the native camera APIs. - LLMs are way better at react than they are at swift & kotlin development.

If I wanted to build the next TikTok though I'd 100% go full native.

[leptons]

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

[dave_sid]

If he can only remember two programming languages then he wouldn’t stand a chance in today’s dev ops, t-shaped, m-shaped world I’m afraid. Imagine asking him to help setup an CI pipeline, or some infrastructure but he’s worried learning a bit of Terraform will make him forget his second last language. You just can’t be like that these days. You have to be a jack of all trades and a master of all trades. That’s just where we are and it’s not going to change anytime soon.

[wiseowise]

Many times this. I'm always skeptical if people saying they know 5+ programming languages beyond surface level.

[dagmx]

A lot of language concepts are shared and abstract. It’s not hard to know many languages proficiently.

I do agree a lot of people over estimate how much they know, but I work with multiple people who know at least 5 languages well.

For me myself, only counting things I’ve shipped at scale, I’d know C, C++, Swift, JavaScript, Python, Rust, MSL, HLSL, GLSL, MEL. There’s enough in common between them that I think it’s quite doable.

[wiseowise]

> A lot of language concepts are shared and abstract. It’s not hard to know many languages proficiently.

Every language has thousands of papercuts. It is hard to know many languages proficiently beyond surface syntax level, period.

> I’d know C, C++, Swift, JavaScript, Python, Rust, MSL, HLSL, GLSL, MEL

Shipped !== know. I've touched dozens of languages over my career and every time I've had my ass kicked by some esoteric knowledge of specific quirk in std of %lang%. We have a different definition of "know".

[dagmx]

Now you’re just shifting the goalpost.

You initially said beyond a surface level and now you’re talking about esoteric quirks.

Pick one. Of course nobody has the same definition as you if you’re shifting the line and simultaneously not defining what you mean.

You don’t need to know every aspect of a languages corners to be proficient in it. If that were true, there’s only a handful of people on this planet who’d be proficient in a single language let alone multiple.

[wiseowise]

> If that were true, there’s only a handful of people on this planet who’d be proficient in a single language let alone multiple.

This was indeed my point from the start.

[pjmlp]

When you work in enterprise consulting, it suffices to know a language good enough to deliver.

It is common practice to be thrown at random projects regardless of the programming project.

What is valued is the soft skills, and the ability to swim when thrown into the cold water, no matter how.

Yes it kind of sucks, however the Pandora box is long open and only an implosion of the capitalist enterprise culture would fix it.

[leptons]

Sure, I can "swim when thrown into the cold water", but you have to be a masochist to like that kind of job. It sucks. I won't do it if I don't have to, and luckily I don't have to.

[pjmlp]

It pays better than the alternatives and some freedom moving between technologies, which tend to be product development with an expiration date, until the company gets acquired or decides to offshore the team.

Contrary to product companies you also get to jump technologies without having an HR department sending the application into the garbage because one doesn't tick all the boxes on a specific stack.

[isodev]

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.

[myko]

Shocked to hear Swift described as "painful" (well, maybe the new concurrency stuff)

[isodev]

It's always been unpleasant but you could find a balance to make it work. Since Swift 6 it's just headache as a service. If only we weren't forced to use it..

Also picture this. Every time you run swift build, you get a mental image of Cook dining with Trump. It's very hard to stay focused and creative in that ecosystem rn.

[saagarjha]

I have unfortunate news about the tech industry in general.

[isodev]

Indeed, but it doesn't hurt to be a bit more selective and future thinking when choosing a stack or tools.

[saagarjha]

Where are you heading to next?

[einsteinx2]

So Swift is painful to use because Tim Cook once had dinner with someone you don’t like?

[willtemperley]

Bill Gates, Tim Cook, Mark Zuckerberg, Satya Nadella, Sergey Brin and Sundar Pichai were all there dining with Trump.

Weird how Tim Cook gets so much hate, when the rest of them didn't. He didn't say anything notable except a bit of ring-kissing: "I want to thank you for setting the tone such that we can make a major investment ..."

Then Sergey Brin starts talking about how he's happy about Trump pressuring Maduro:

You're applying a lot of pressure to Maduro and I think that's phenomenal for an American president to actually be applying pressure there uh in Venezuela and then hopefully in Cuba and so forth. So there's a lot of um civil rights work that you're leading. we didn't get a chance to mention. Um I also just wanted to mention um we don't have to get into all the uh details talked about in the Oval Office, but uh I think it's a real incredible inflection point right now in AI and the fact that your administration uh is uh supporting our companies instead of fighting with them."

So, reading between the lines a little, i.e. Google looking depose dictators and burn lots of oil to keep their AI slop churning is totally fine:

https://www.youtube.com/watch?v=MvbKA-Te8QE

[monegator]

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.