[websiteapi]

jeez so many ways to do things -

react native flutter ionic

and now swift.

it seems dart + flutter still is the only way to do all targets (cli/web/iOS/android/desktop) though. react native being very close (albeit needs electron).

it surprises me that this hasn't been perfected. surely some big company would look at their balance sheet and see it's worth it even if you take a 10% performance hit on each platform, assuming you can share 90% of the code.

does swift have a good web story or is wasm the main way? desktop?

[topspin]

> it surprises me that this hasn't been perfected

It shouldn't. It's never really been perfected across native GUI APIs after 40+ years: just various degrees of "good enough," plus fobbing it off to web stacks.

Anyhow, I've been playing with gioui, which is golang rendering in a lightweight <canvas>-like. Really nice: fast, small, cross platform GUI with just Go. Scale expectations appropriately.

[wahnfrieden]

Swift on WASM also got very good last year. SQLite in WASM too.

Flutter is still bad on iOS and macOS. No Liquid Glass (except some weird hack attempts that look and behave badly). Liquid Glass isn't an optional decoration, it's the name of the new system-wide UI. Leaving it out of your app is like committing to iOS 6-era skeuomorphic design after iOS 7.

Edit: Several cross-platforms frameworks can do Liquid Glass:

- SwiftUI by using Skip for Android

- SwiftCrossUI

- React Native

I'm glad to see that I can finally target iOS as the first-class citizen, using Apple technologies, and then run that code on other platforms. Instead of having to use frameworks that treat iOS as secondary when it is by far the biggest money-maker for most apps.

[cageface]

I’ve had very good experiences with Flutter on iOS and macOS. It’s actually a lot easier to get good performance in Flutter than SwiftUI.

No cross platform stack can do Liquid Glass yet. You have to wonder if that was one of design goals.

[gumby271]

I'm pretty well convinced it was a goal too. If it wasn't then shame on them since it doesn't accomplish anything else well.

[d12bb]

It’s nice developer experience indeed. But for me as a user, I hate it. Looks nothing like an iOS app, often even worse than fckng webviews…

[wahnfrieden]

All those approximations at Liquid Glass are infuriating to use and make every app that does feel cheap and gross

[dangus]

> Liquid Glass isn't an optional decoration, it's the name of the new system-wide UI

Of course it’s optional. Some of the most popular apps on the planet ignore the local UI conventions of their parent OSes entirely.

TikTok is a Flutter app. It looks identical on iOS and Android. It uses basically no native UI elements.

It’s a pretty well-known strategy to create apps that look identical on all platforms so that you lessen your customer confusion and your support burden. The fact that Spotify, Facebook, Uber, and Reddit look exactly the same no matter what platform you’re on is more important than complying with OS design guidelines and UI elements.

[d12bb]

> Spotify, Facebook, Uber, and Reddit

And I hate every one of those apps (well, back when I used Facebook, years ago, I did), because they’re just bad iOS citizens. I, as most iOS users do, don’t care what apps look on Android. For Android users, it’s the same with iOS. Making shitty cross platform apps is all about branding and saving some money for developers, nothing about the users.

[dangus]

It’s cool that you are a non-conformist badass but their wild popularity proves that a native app experience doesn’t matter.

What does “bad iOS citizen” even mean?

It’s not even about saving money for developers, it’s about the fact that your users expect a consistent experience.

Imagine if you watched an NFL game on NBC and the on-screen graphics were different if you were watching on a Samsung TV versus an LG TV. That’s the issue with native app UI elements (and it would quite literally be an issue with content apps on smart TV app platforms which are way more fragmented than iOS versus Android).

[d12bb]

Your conclusion is false, as you’re mixing stuff that shouldn’t be mixed here:

1. Spotify, Uber etc are popular because of their product, not the pure quality of their apps. People use Uber because they want to cheaply get somewhere, and Spotify cause that’s there all their shared playlists are.

2. People buy whatever tv is on sale when their old one breaks, but the vast majority will stay with their phone platform, so couldn’t care less what their apps look on the other platforms out there.

So, native experience does matter, but obviously only as one of multiple deciding factors.

> What does “bad iOS citizen” even mean?

Doesn’t look like native apps, doesn’t feel like native apps (come on, most multi platform frameworks don’t even get the scrolling right, one of the most basic forms of interaction), doesn’t use all of the platforms features to their fullest, as applicable for the type of app.

[wahnfrieden]

What I meant to say in my original message is that if you are using system default-ish iOS UI styling, Liquid Glass is not optional decoration. If you have your entirely own UI and design system, sure you don't need it. But many of these Flutter apps or other such toolkits are using it to approximate system default UI except either without the Liquid Glass parts or with uncanny and incomplete approximations of it.

[neonmagenta]

Exactly. Branding and UX are breaking out of the box for guidelines in the successful platforms. You want to be able to pick up any device and have the user know exactly what theyre doing

[wiseowise]

Thank God I’m only using web versions whenever possible.

[dangus]

Which also have consistent branding and UX with the apps.

[wiseowise]

That's fine, as long as I have native OS dialogs/settings.

[uripont]

I thought TikTok used native implementations and Lynx (their cross-platform framework)

[dangus]

I dunno, the ByteDance logo is on the Flutter web page.

But it really doesn’t matter either way. The point is that TikTok doesn’t follow any OS conventions.

[satvikpendem]

> Edit: Several cross-platforms frameworks can do Liquid Glass:

This is pretty funny because you just listed SwiftUI three times but in different configurations. They're not truly cross platform, they just wrap Apple's native design code. In contrast, I can (and do) use a package like liquid_glass_renderer to get Liquid Glass everywhere, on all my devices, with one codebase.

[wahnfrieden]

If this is the current state of it, I can spot a dozen details that are wrong or missing: https://x.com/imadetheseworks/status/1973765948218941771/vid...

Maybe it will get there... Meanwhile I would rather use technologies that provide the full experience on the platform where it matters, and would never want those liquid components on platforms like Android or Windows anyway.

[satvikpendem]

Well, the library is literally 3 months old, and it's made by one person as an OSS package, so yes, I'm sure you can spot those wrong details. Still, it'll get there, especially once Flutter gets official support for Liquid Glass, as they are planning on working on it later this year or into next year, currently they are refactoring their current design library code.

> and would never want those liquid components on platforms like Android or Windows anyway.

That's where we disagree then, I like the design itself but don't like it stuck on only one platform. I make apps with wholly custom UI designs, not following any particular OS' "native" design, and that's why Flutter is so powerful, because I am not constrained to what pixels I can render to a screen, nor should I be.

[websiteapi]

in my experience wasm on web, though it works, has too slow a first page load time for slow connections.

[wahnfrieden]

Embedded Swift WASM is very small now. But it is still behind on some useful capabilities like having a replacement for Codable (which last I read may be getting a more performant replacement). Regular Swift WASM got a lot smaller too last year though.

[websiteapi]

interesting - do you have a good example of a non-trivial web app that uses swift wasm?

[wahnfrieden]

Goodnotes

[LorenDB]

Qt/QML can do all those targets as well (although it is admittedly jankier on mobile than Flutter or Swift would be).

[palata]

I never understood that. Qt is C++. The only valid reason to use C++ is "not having a choice" (which happens to me, too). But if you write a mobile app, I find it extremely weird to choose C++ instead of a modern language.

Disclaimer: I have seen teams writing mobile apps in Qt, and it was systematically a lot slower to develop, with a lot of pain, and resulting in worse apps. Even if you only have C++ devs, I would argue that it may be worth giving them the time to learn a modern language and write the mobile app with it.

[rubymamis]

Hi there! I'm curious about the use cases people you know used Qt to develop for mobile. Do you mind expanding on this?

I'd love if you could also contact me (my socials are in my profile) as I'm developing a set of components to help exactly in that situation.

[palata]

> I'm curious about the use cases people you know used Qt to develop for mobile.

They were developing non-trivial mobile apps. The kind where you use your fingers on a touch screen, but that are more complex than just showing a text and an image. Say Google Maps, or WhatsApp.

The problem was not the lack of components: the problem was that it was C++. C++ is more complex to write correctly than Swift or Kotlin and harder to debug. Which made those teams measurably a lot slower. It's just the wrong technology for the use-case, IMO.

[rubymamis]

I also write complex UIs with QML and C++. I do not consider myself an expert in C++ but there is clearly a subset of it that I feel comfortable in. I think the combo of QML & C++ is great since QML lets you focus on the UI - and does a great job at it, and in C++ you can write performant code. C++ isn't that complicated these days - if you stick to a subset you're familiar with.

[palata]

How much experience do you have writing mobile apps in Kotlin or Swift, as a comparison? I have worked in C++ for years, and in Swift for years. I have seen the exact same app being written both in Java and in C++.

> in C++ you can write performant code

This almost certainly does not matter for a mobile app, and definitely not for the UI part. In case your app has to do something that may need C++ (e.g. computer vision), then you can just call a C++ library over FFI.

> C++ isn't that complicated these days

I didn't mean that it is complicated. I can totally write C++. What I meant is that it is more complicated to get it right than modern languages. If users complain about a segmentation fault, it's often pretty tricky to debug. In Java/Kotlin, you will get an exception that tells you exactly which line crashed.

On top of that, C++ is slower to write. Again I have been able to compare teams working on the same app both in C++ and in Java/Kotlin/Swift (Java is not exactly a modern language, but still it's a lot faster to develop with).

And after all those disadvantages of using C++ for a mobile app, you end up with a UI that doesn't feel native to the platform.

Again: I still write C++ when it makes sense (usually that's for legacy reasons or libraries availability, otherwise Rust is a better choice IMO). But for writing a mobile UI? Doesn't make any sense to me.

Even for writing a Desktop app, I don't understand why people use Qt instead of e.g. Java. Kotlin/Compose seem to be coming on Desktop too, which makes a lot of sense to me. And maybe even Flutter.

Finally, I don't understand writing a cross-platform UI for Desktop and mobile. On mobile, I have a big finger and a small touch screen. On Desktop, I have a big screen, a mouse and a keyboard. Those require different UIs. Sharing the logic is fine, but the UI needs to be written for the platform.

[yk09123]

I find Kotlin Multiplatform to be far and away a better experience than flutter

[flax]

Could you explain why? I have been interested, in theory, in Kotlin Multiplatform. But I'm already very comfortable in Dart and Flutter. I have decades of experience with Java, Javascript, and quite a few years with Typescript. Kotlin feels like a different kind of language, one I find grating. I think this is primarily aesthetic, but it's still enough to make getting over the initial hump annoying. As petty as it is, I think the lack of statement-terminating semicolons is a major reason I do not like it. I would welcome a factual list of things that make the KM experience better for you.

[vips7L]

Kotlin doesn’t feel right to me either. I did a portion of AoC in it this year and it was surprisingly more verbose than I expected. I think the thing I liked the least was trailing lambda syntax combined with how verbose it was to define variables with types.

It also inherits all of the bad parts of the JVM. Crappy build tooling (gradle), and then the slow startup and high memory usage.

[cosmic_cheese]

Coming from writing a ton of Swift (and previously Obj-C), Kotlin’s ergonomics feel kinda off. It also feels like it’s different for the sake of being different more often than I’d like.

[Larrikin]

Can you give concrete examples? I played with Swift in school after already making the dive into Kotlin. It just felt like Kotlin but trapped on Apple. Part of the program even included a course in using a different language every couple weeks where we went through Scala, Lisp, and some others just to see what they could do.

Currently Kotlin is far and away my favorite language but I also haven't looked into the newer languages recently and am interested in hearing pain points people have. Especially if it isn't annoyances with Gradle

[cosmic_cheese]

Broadly speaking, Kotlin deviates from popular conventions more than Swift does. For example, Kotlin expects you to use inline if statements where in Swift, ternary operators work like they do in C, JavaScript, and many other languages.

There's also things like Swift's guard statements that can help make intent clearer and read a bit more nicely.

[satvikpendem]

I used Kotlin as well and it just feels off too. The package support is a major thing, as I don't want to mess around in Gradle, I want something that Just Works™. Dart 3 has much of the same feature set as Kotlin now with sealed class support, it's just not as functional, but it recently got tearoffs so you don't have to specify the class, just the property, similar to Swift (ie if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`).

The main thing though is that Dart has pub.dev and a CLI that makes it extremely easy to add packages, via `dart pub add`. If I do want to go more of a functional route I'll just use Rust instead, it has all of what Kotlin has and more, plus a similar streamlined package management as Dart in the form of `cargo add`.

[BoorishBears]

Funny you say that since Dart is the primary reason most people I know don't want to use Flutter.

There's been a trend of improved DX for languages used in app development:

ObjC -> Swift

Java -> Kotlin

Javascript -> Typescript

...Dart feels like the before with no after, even though it got traction in the era of the Afters.

[vips7L]

Darts pretty good. It has a lot of modern features, nullable types, pattern matching, sum types, and factory constructors; some really good build tooling. It can compile fully AoT.

[saagarjha]

It’s not very good if you’re comparing it against Kotlin or Swift though.

[realusername]

It's a matter of taste, even just the swift example on this website makes me raise eyebrows.

[wiseowise]

It is great if you’re comparing it against Kotlin or Swift, unless you’re stuck in an era of 1.x Dart.

[satvikpendem]

Eh, it's getting there, slowly at first but more rapidly now. It now got tearoffs, I explained in another comment but

> if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`

Dart is getting new features pretty fast, they really started focusing on the DX more after Dart 2 and now especially after Dart 3. Macros were supposed to ship but it was incompatible with the goals of fast compilation, so other sorts of smaller features will ship instead.

[websiteapi]

isn't this just because Dart is way newer than those? it's from the 2010s. it's really modern in comparison (same generation as Kotlin swift and typescript)

[BoorishBears]

> Dart feels like the before with no after, even though it got traction in the era of the Afters.

It's aged like the recent languages but feels clunkier like a language that's much much older.

[mdhb]

Dart is hands down the best modern language out there for app development right now what are you even talking about? I understand that maybe a lot of people haven’t used it or maybe haven’t used it in years and that probably drives a lot of the FUD but for those who use it, it has stupidly high ratings from developers who use it and has for years.

[BoorishBears]

It's not FUD when you make something terrible* and that reputation doesn't immediately slough off.

And I just checked the Dart release notes from all of 2025: https://dart.dev/resources/whats-new

Great progress! But smells a lot like the language I had it pegged for when "underscore as a wildcard" lands in February 2025, 2 years after pattern matching lands.

How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?

-

* Dart was awful, lost to Javascript because no one rated it highly enough to justify moving off Javascript, and was practically dead until Flutter dusted off the corpse and pivoted away from their browser goals... so super weird revisionism to act like we're talking about some beloved evergreen language.

[munificent]

> How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?

We shipped support for `_` as wildcards in patterns with Dart 3.0 when pattern matching first shipped.

However, prior to Dart 3.0, `_` was already a valid identifier (as it is in most other languages). The feature you're mentioning from last year was to remove support for uses of `_` as an identifier outside of patterns. This way `_` consistently behaves like a wildcard everywhere in the language. We didn't ship that in 3.0 because it's a breaking change and those are harder to roll out without causing a lot of user pain.

It's OK to not like Dart. There are multiple popular languages for a reason. But it is helpful when communicating about a language to others to be accurate so that they can make their own informed opinions.

[wiseowise]

You seem confused and indeed spreading FUD.

Dart wasn’t awful. It wasn’t adopted at the time because it had a distinct runtime that would require splitting web in two which nobody wanted. On top of that it gave Google too much power, because now they would control both runtime (V8) + language (Dart).

TypeScript won and became king because it was pretty much JS 2.0 instead of JS++ like Dart.

[wiseowise]

Have you even used modern Dart?

[cageface]

The last time I looked at it was far less mature on non-Android platforms than Flutter. Has that changed?

[crowbahr]

Flutter has been abandoned by all the large companies - Google is throwing their weight in on KMP and has laid off the flutter teams.

[satvikpendem]

This is completely incorrect. Large companies like Canonical are all in on Flutter even now, they're making it the default for desktop UI development in Ubuntu and are writing a lot of their own apps in Flutter.

The "layoffs" were not any of the core team, it was just an offshoring, of infrastructure devs at Google that happened to work on Flutter builds, to Europe where they rehired for the same positions there.

[cageface]

This is a large exaggeration. There are still a lot of people working on Flutter at Google and large companies continue to adopt it.

Google's wildly popular NotebookLM is a recently released Flutter app, for example.

[websiteapi]

I heard of the flutter layoffs, but my understand is that it was unrelated to KMP. fwiw google still uses flutter

[wiseowise]

Source?

> Google is throwing their weight in on KMP

Hahah.

[mdhb]

Just straight up making shit up here. WTF are you talking about?

[palata]

Google Workspace has been moving to KMP. They said at KotlinConf that it has replaced their decade-old transpiler from Java to ObjC, which is very impressive.

[mdhb]

Yes this is because they are starting with a Java codebase and that obviously makes sense there.

You have other platforms like Google earth who when it was time for a proper rewrite went with flutter and dart along with a bunch of Google cloud stuff and Google Ads.

[satvikpendem]

That's funny, I found it the exact opposite, not the least of which is that it requires a JetBrains IDE to even run it. VSCode or neovim with Flutter and really most every other UI framework like React (and Native) work great.

Regarding KMP specifically, I didn't find it much use to only write business logic in one language, while still having to rewrite the UI up to 6 times (mobile, web, desktop), I'd rather have everything all in one.

Compose Multiplatform looks promising as it's Flutter-like in that it renders its own UI but it's still quite early, I know they say it's "stable" but when I used it, it really didn't seem so, plus the package support is extremely lacking compared to Flutter and of course the behemoth that is React (and Native)'s npm.

These days I'm looking forward to Dioxus, they're making their own native renderer similar to Flutter but especially for web, they are not doing the canvas trick, because they actually use plain HTML and CSS as their markup languages so they can compile directly to browser standards sites while still having a non-webview experience on mobile and desktop.

[websiteapi]

Kotlin Multiplatform does seem pretty appealing, but haven't looked into it very much

[wiseowise]

In what way? It’s an unfinished, hot garbage bolted on top of Gradle. Flutter is light years ahead in terms of polish and development experience.

[palata]

I think you're confused. It's not "something on top of Gradle". For instance to run on in Swift on iOS, it has to compile to native, and then it wraps it in a C interface and finally in a Swift interface. This has absolutely nothing to do with Gradle.

[wiseowise]

> For instance to run on in Swift on iOS, it has to compile to native, and then it wraps it in a C interface and finally in a Swift interface. This has absolutely nothing to do with Gradle.

And what exactly orchestrates the process of compilation (invoking Kotlin compiler + fetching dependencies)?

[palata]

Whatever you want, really. The default just happens to be Gradle because that's the default on Android.

My point is that the fundamental difference between Flutter and KMP is not at all Gradle.

Last time I checked, Flutter was relying on messaging. KMP leverages FFIs. Flutter is a framework, KMP is not. If all you see is the command line you invoke to run the build, I think you're missing a lot.

[cyberax]

React Native doesn't use Electron on mobile, it's a misconception. But it does depend on interpreted JavaScript on iOS and Android.

[websiteapi]

I mean on desktop

[avtar]

React Native doesn’t depend on Electron for desktop apps either. It renders using native UI components and don’t use a browser engine.

[websiteapi]

I know react native for windows is a thing, but is it on par with electron these days? my understand is that it was way beyond, but I could def be wrong

[kenferry]

The bigger hit than performance is usually user experience quality and “write once debug everywhere”.

[websiteapi]

true - though I don't think that's inherent, more just the mentality of one who might pursue this.

[andycall]

React/Vue + TailwindCSS are now ready for building Flutter apps.

https://openwebf.com/en/blog/announcing-webf

[SchwKatze]

There is also Dioxus

[satvikpendem]

I was initially uninterested in Dioxus because they just used webviews but their native renderer is really interesting now because it has a lot of strengths, using plain HTML and CSS as the markup language so that they don't have to render to a canvas on the web like Flutter, Compose Multiplatform or many other WASM based renderers do, as they can just, well, ship the HTML and CSS directly. But then on mobile and desktop, it will be rendered without a webview, so you get all the benefits of each platform.