5 ms·

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,

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.

zengid 3y ago
[flagged]
rapsey 3y ago
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.
- dan1234 3y ago
  I have the same problem with react native.
  - com2kid 3y ago
    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 3y ago
      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...
- CrimsonRain 3y ago
  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 3y ago
    > 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.
lockhouse 3y ago
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.
- deleted 3y ago
  [deleted]
- danielvaughn 3y ago
  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.
Vt71fcAqt7 3y ago
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.
kitsunesoba 3y ago
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 3y ago
  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 3y ago
  Especially when you need a date picker that doesn't scream Android
mikhael28 3y ago
Dart and Flutter are totally fine, and great in production. I really don't understand the hate.
- M4v3R 3y ago
  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 https://github.com/flutter/flutter/issues/12920
  - jononomo 3y ago
    Isn't getting 95% of the way there better than getting 0% of the way there? What are you going to do instead?
    - waboremo 3y ago
      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.
    - M4v3R 3y ago
      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.
    - 1123581321 3y ago
cush 3y ago
I'm still holding out for Xamarin
madeofpalk 3y ago
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.

zengid 3y ago

[flagged]

rapsey 3y ago

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.

dan1234 3y ago
I have the same problem with react native.
- com2kid 3y ago
  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 3y ago
    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...
CrimsonRain 3y ago
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 3y ago
  > 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.

lockhouse 3y ago

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.

deleted 3y ago
[deleted]
danielvaughn 3y ago
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.

Vt71fcAqt7 3y ago

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.

kitsunesoba 3y ago

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 3y ago
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 3y ago
Especially when you need a date picker that doesn't scream Android

mikhael28 3y ago

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

M4v3R 3y ago
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 https://github.com/flutter/flutter/issues/12920
- jononomo 3y ago
  Isn't getting 95% of the way there better than getting 0% of the way there? What are you going to do instead?
  - waboremo 3y ago
    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.
  - M4v3R 3y ago
    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.
  - 1123581321 3y ago

cush 3y ago

I'm still holding out for Xamarin

madeofpalk 3y ago

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.