[serial_dev]

I'm a Flutter dev since 2018 and I am honestly not sure if Flutter or React Native still make sense in 2024 and onwards.

When they emerged, the mobile development scene was completely different than today.

Today, we have Swift UI and Compose, both are pretty solid. I'm not sure if it's the consensus amongst mobile developers, but I believe that on the mid/long run you will be better off - even if you write things twice. In terms of end user experience, developer experience, and in the business sense, everywhere.

Sure if you have an Flutter / RN app that has years of engineering efforts invested into it, go ahead and continue (duh), but I wouldn't start new apps with them.

[johnny22]

> I believe that on the mid/long run you will be better off - even if you write things twice.

People have believed this the whole time and also a ton of people didn't then and don't now. What has actually changed?

[serial_dev]

Swift and Kotlin are now the de-facto languages for these two platforms for new development, and Swift UI and Compose got released and gained traction since 2018.

[jdthedisciple]

I agree with you only in terms of Flutter and Web: Been a Flutter dev since years now as well and would definitely NOT encourage it for the Web.

That said, it is absolutely up there with the best choices for mobile app dev these days.

I don't see any reason not to use it there, and the industry seems to be thinking in the same direction atm

[gman83]

I got my Flutter app running on iOS, Windows, Linux, and Android. The web version is quite serviceable a well. Totally responsive and with good desktop integration on Windows & Linux. For me, talking about the "mobile development scene" is outdated. I want my app to run on every screen. That's either web or Flutter, Swift UI and Compose just don't fit the bill for me. I like both Web & Flutter, depending on the use-case. I tried React Native for Linux and Windows, but found it too complicated to set up, Flutter just worked. Curious if that has gotten better.

[lawgimenez]

Native dev here throughout my career, I always start projects in both native. Now, it’s SwiftUI and Jetpack Compose. I don’t do cross platforms ever, it doesn’t appeal to me. I don’t know why though.

[billfruit]

By Compose, do you mean Jetpack Compose?

[serial_dev]

Yes. Compose Multiplatform is just not there yet, and will unfortunately share lot of the downsides of Flutter.

[mixmastamyk]

Hmm, what about desktop and/or web?

[EddieRingle]

Compose UI has the potential answer there, as well: https://www.jetbrains.com/compose-multiplatform/

[mixmastamyk]

Great, another one. Recently someone else was touting something called avalonia for .net? Then there are older ones that still exist, like Kivy and QT.

These folks should be working together on just a few open-source projects :-D. Trying to support every mainstream platform is a huge undertaking and as mentioned in this thread, few succeed, and even fewer over the long term.

[EddieRingle]

I think that's an absolutely reasonable reaction. I can only say that, as someone that primarily works on Android, I'll of course prefer Compose UI since it's technically the "native" solution for me already. And while reading further, keep in mind that my views are going to be biased towards Kotlin and such for that reason, of course. There's also the additional disclaimer that it's still relatively early days, and the developer experience isn't perfect out of the box with every platform, just yet.

By opting for Kotlin and Compose UI, in addition to being a first-class citizen on Android, I gain the ability to share code with many other platforms to any degree I need. That is, just the app logic can be done in Kotlin while keeping the actual UI in whatever each platform prefers (UIKit on Apple platforms, Swing on JVM, etc.), or it can be entirely done with Compose UI (which usually means being rendered via something like Skia). And even if you adopt Compose UI, there are different degrees to which that can be applied; Compose UI can output either DOM elements or render to a canvas for the Web target, for example. (It's actually curious you mentioned Qt. As a day-to-day KDE user, I'm interested in playing around with the possibility of wrapping Qt components with Kotlin/Compose as well.)

No matter what degree of that I choose, it's still going to be more "native" than something like RN. Depending on the target platform, Kotlin will compile down to JVM/Dalvik bytecode, LLVM bitcode/machine code, JavaScript, WASM, etc. RN (last I checked, at least) still relies on running in a JavaScript engine at the end of the day. Flutter will get you closer than RN, but it's still not quite native to any one platform in particular and you're still introducing Dart as another language you need to know. A .NET-based solution suffers a similar problem, and IMO it feels even more out of place on Linux than the rest.

(To be clear, Compose UI has been able to learn a lot from Flutter, as they both originated at Google and both take a declarative UI approach; I largely consider Compose UI to be Flutter's successor.)

Ultimately, it can boil down to this: if you want to support multiple platforms, you need expertise in each. Adding most traditional cross-platform frameworks such as Flutter or RN also means you need expertise in that framework as well. In the worst case, my expertise with Compose UI will remain good for the work I need to do on Android. The worst case for most of these other frameworks is that it becomes irrelevant and you need to learn something else anyway.

[mixmastamyk]

Thanks. Wow, Flutter and JPC coming from the same company make me less likely to use either, haha. Decisions, decisions.

Did much of the JPC team get let go like the Flutter team in the last big round of layoffs?

[serial_dev]

I don't want to say you should never, under any circumstances, use cross platform tools. Sure, if you have Android, iOS, web, macOS, Linux and Windows apps that are all roughly the same, go ahead and use cross platform technologies.

I don't think most apps are like that, though. If it is worth having a desktop app (instead of just, you know, having a web app), than that app is probably relying heavily on native integration. Also, mobile apps and desktop apps are usually quite different (as they should), those are two completely different interfaces.

About web, I'm not sure about RN, but Flutter IMO is so terrible on web, that it's so rare that it would make sense to use it, that my default advice would be that write the web in something different, even if you use Flutter already on mobile and desktop.

[mixmastamyk]

Well, I need to make a media-player type of app, that will run on Linux/Wayland devices, which are like small desktops. Mainstream mobile devices would be a nice-to-have too, but there are so many bureaucratic issues, like getting into stores I might just avoid them for now. Web stuff can stay web.

Was thinking of learning Flutter or even RN, but now not so sure. On the other hand, it could mean writing it three times.