[MobileVet]

I've worked in mobile since 2004 (not a typo, '04). The 'one platform to rule them all' has been just around the corner the entire time. As was already said, don't hold your breath.

All of that said, if you are time constrained and really want to look at a single thing, I would go with Flutter. It impressed me when I cranked out a side project with it a year or so ago. Hopefully they continue to put effort towards it.

[rapsey]

From our experience Flutter apps are easy to start with but quite hard to maintain. The core system keeps changing so much you are constantly having to fix things and dealing with broken dependencies. Would never use it for anything important.

[CrimsonRain]

Our experience is opposite. We started with GetX because we were new. Then moved to Riverpod/Go-Router as we gained experience. We have a set-up of four modules (shared lib; shared ui; app1 and app2) for two apps targeting web+ios+android; about 50k LoC @ 160 line length.

Obviously there were a lot of friction when moving out of GetX, but upgrading things have always been easy. Usually at most one day worth of work (worst case). We don't upgrade as soon as a new flutter version is released. We give it a month at least and then upgrade.

During upgrade, most of the problems usually come from 3P dependencies which interact with native such as package info plus. Also, we don't add dependencies unless we really need to. I think we are at ~30 total between all modules.

On the other hand, our react projects are forever in dependency hell. Much larger project, yes but way too many dependencies and too many things break during upgrade.

[bartvk]

> Also, we don't add dependencies unless we really need to

I think this is the trick. I've worked for a client whose coding standards basically forbade 3rd party clients. Turns out, it often is not needed at all. Do you need to include a library for a bar chart? No, a bar chart is often just a bunch of rectangles and labels.

When you have stupid-simple project setups, you can have huge projects but they'll compile fast and upgrade quickly.

[dan1234]

I have the same problem with react native.

[com2kid]

I stopped supporting an open source React Native library because keeping the sample code working in Expo was taking too much of my time.

This was years ago, maybe things have calmed down since then, but Expo always felt like hanging onto the horns of a bull, so long as you didn't fall off it was a fun ride!

[timmeta]

That's similar to my experience. Not just React but across JS in general. Was super hard to keep everything at pace when it was and is moving so fast. I slightly envy the old COBOL people sometimes...

[kitsunesoba]

In my experience the issue with Flutter apps is though they aren't too bad on Android, they have an odd off-putting feel to them on iOS, more than is typically visible with competing cross-platform UI frameworks.

[martinald]

It's because unlike a lot of frameworks like React Native and Xamarin, it doesn't use native UI components under the hood (unless this has changed recently). It's a bit like using a canvas element in HTML and drawing your own toolkit, or old Java GUI apps.

[__m]

Especially when you need a date picker that doesn't scream Android

[lockhouse]

The biggest problem with Flutter is Dart. Not the language specifically (it’s a nice enough flavor of C-family language), but the ecosystem. Even Swift is better in this regard. Flutter ported to TypeScript and sufficiently distanced from Google would actually be very compelling.

[danielvaughn]

Yep, I just commented the same thing before I read this. I'd say it's both Dart and Material Design. Dart doesn't seem bad (I've only glanced), it's just not very compelling or interesting.

[madeofpalk]

More specifically, there are a bunch of efforts, but the Swift ecosystem doesn't seem too interested in this.

Even Apple can barely get it with SwiftUI being a dumpster fire on macOS.

[Vt71fcAqt7]

I have to agree. Also I feel like those complaining about dart just have a bad taste in their mouth from dart 1.0. Dart has named parameters (so better than java) and null saftey. It's a pretty standard GCed OOP language. I also don't understand when people complain about the dart ecosystem. Seems fine to me.

[mikhael28]

Dart and Flutter are totally fine, and great in production. I really don't understand the hate.

[M4v3R]

Flutter is mostly fine. Until you need to implement text input in your app. And it turns out that autocomplete doesn’t work properly on iOS for non-English phones and you discover there’s a bug filled on their tracker for 5 years already and it’s still open [1]. Or you encounter another similar issue that is niche enough that the developers ignore it completely but is frustrating for your users and there’s nothing you can do.

Don’t get me wrong, I would really love Flutter to be THE solution to the cross platform mobile app problem, but sadly it only gets you 95% there and if you really care about the last 5% you’re out of luck.

[1] https://github.com/flutter/flutter/issues/12920

[jononomo]

Isn't getting 95% of the way there better than getting 0% of the way there? What are you going to do instead?

[waboremo]

Your equation isn't complete. You can't only care about getting 95% of the way there if the final 5% takes substantially more time than it normally would or worse halts development entirely.

[1123581321]

You can get 100% of the way there with Kotlin and Swift for UIs and a multiplatform library. Or web.

[M4v3R]

It depends. For some use cases it’s definitely enough and if you’re on tight budget it might get you far enough. But eventually it might fall short and you’ll have to either fight the framework or switch to a native solution.

I believe it’s good for knocking out an MVP if the mobile app is not critical to your business. I would not choose it otherwise though.

[cush]

I'm still holding out for Xamarin