9 ms·

I’ve given Flutter a try with one of my client’s apps, and in some cases, it’s obviously better than native development. Mainly because you can develop for both

I’ve given Flutter a try with one of my client’s apps, and in some cases, it’s obviously better than native development. Mainly because you can develop for both platforms. I’d be curious to hear where other developers think Flutter is a good framework to use instead of developing native code.

s_y_n_t_a_x 7y ago
On iOS it's obvious it uses emulated controls. I think if you want a fully themed app that looks the same across all environments, you should go with Flutter. If you want an app that looks the same as other native apps on the target environment, you should go with React Native.
- saagarjha 7y ago
  I’m not sure why this is downvoted, as it summarizes Flutter pretty well. Flutter’s “Cupertino” theme is obviously an emulation if you use it for more than a minute. If you want your app to look like an Android app on both platforms, though, I think it does pretty well at that.
  - solarkraft 7y ago
    Do users care? It doesn't feel exactly native on Android, but is still fast and looks great (it might indeed be better than native). Afaik the main alternatives, RN and Web (for fully reusable UI) are both heavy and don't feel that native either, yet are popular with developers.
    - hn_throwaway_99 7y ago
      IMO, UI frameworks that try to mimic native components virtually always fail, because they end up being an almost-but-something-I-cant-put-my-finger-on-feels-wrong situation, e.g. performance isn't quite there or the physics is different. Much better IMO to go for a "minimalistic", neutral interface where people won't always be comparing your app to better native controls.
      - deleted 7y ago
        [deleted]
      - Apocryphon 7y ago
        That's why Google is trying to push Material as a default alternative to Cupertino widgets, perhaps.
    - saagarjha 7y ago
      As a user, I care quite a bit. As a developer, though, I get paid to tell people that their software doesn’t follow platform UI conventions and I run their code through mental checklists (“does the title animate properly during a controller pop, does this custom view break accessibility”) so I think it’s pretty obvious that I have a very specific slant on this issue. Keeping that in mind, I think that many users do care but they don’t necessarily make it the only thing they care about, nor are they particularly good about vocalizing their concerns. To them an app is just “weird”, or “unusable”, depending on what the framework actually breaks.
      - Klonoar 7y ago
        Slant is putting it mild - you gotta start putting a disclosure in these kinds of comments or something. You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech. You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter. I say this as someone who prefers native controls, has written/launched apps in ObjC/Swift/etc. There's increasingly little reason to bother with the stack.
        saagarjha 7y ago
        > You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech. I dabble in Android and Linux as well ;) > You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter. Agree on both counts, but I like to think that users aren't completely clueless. There are certain things that they do feel acutely: animation physics that differ from the system's (particularly for things like scrolling), lag, choppiness, lack of proper accessibility support… > There's increasingly little reason to bother with the stack. I disagree with this (this isn't just an iOS thing, by the way: I would say the same for every other platform I've interacted with). It is almost certain to be the case that the team that wrote the platform libraries is smarter, better, and cared more than you did about the UI (there are some very notable exceptions, but I think it's very obvious when this is the case). Going with the native stack means lock-in and sometimes more work, but in exchange you get a significant amount of functionality "for free" (sometimes without even realizing that this functionality existed) and automatically share a common design language with the rest of the system, which is a usability plus for users almost all of the time.
    - afiori 7y ago
      I am using a lot of apps that still have a jellybean feeling to them, if it does not crashes and it is not a swipe-hell (I have an underpowered phone) it is fine to me.
    - dliff 7y ago
      RN definitely feels native... assuming the developers utilized the built-in components properly. RN is an actual native component whose state is backed by a JS bridge. There certainly are poorly written / optimized RN apps. There are also apps that due to their nature/goal shouldn't be RN even at an early stage. (Startup, navigation, threading, network issues for one). However, I would argue that a properly written RN app, within the confines of the problem RN attempts to solve, does not feel heavy and is actually indistinguishable from native. From my experience I would surmise a lot of badly performing RN apps stem from poorly written JavaScript, especially bad state management (lots of devs who perhaps have only written web JS in the past?).
      - monocularvision 7y ago
        Except for navigation
        dliff 7y ago
        Curious where this is an issue. React Navigation feels and is, according to their documentation, composed of native components. Vs. what you can do natively it has severe limitations and the documentation isn't the best (though I think it has improved recently).. but feels native to me.
    - pier25 7y ago
      I use plenty of apps on both iOS and Android that do not use native controls such as Kindle and I really don't care as long as performance is good.
    - lone_haxx0r 7y ago
      To me, smartphones are like plungers: They are dirty, ugly (from a software perspective), and I don't like using them, but they are pretty convenient to have most of the time. I only want them to get the job done and then get out of my sight, so I don't care about the UI being pretty. I would say "elegance is reserved for desktop PCs", but those are ugly too (x86 is horrible, all OSs suck).
  - afiori 7y ago
    The emulation is a feature with well understood trade offs. One of the point is to decouple as much as possible from the OS, I believe one of the advantages is that in flutter's mdoel it should be easier to make one-off apps that need less updates.
  - vetinari 7y ago
    > If you want your app to look like an Android app on both platforms Funny thing is, that it is emulated on Android as well.
    - saagarjha 7y ago
      It is, but I trust a Google team to get that to work at least passably well.
      - Andrex 7y ago
        As someone who is highly discerning of small UI issues, Flutter on Android implements the UI controls extremely well to my eye. (Accessibility not so much unfortunately, but that is a work in progress.)
        Hixie 7y ago
        If you're aware of areas where our accessibility support isn't up to par, please file a bug: https://github.com/flutter/flutter/issues/new?template=BUG.md https://github.com/flutter/flutter/issues/new?template=BUG.m...
    - aasasd 7y ago
      Like Android has any consistent UI at all. On my phone, two apps would have the same widgets only by accident.
- Hixie 7y ago
  (I'm the Flutter TL) If you can tell that we're not using OEM widgets, we consider that a bug. Please file it and explain what the difference is. We're definitely not perfect, but fidelity is a high priority for us this year. https://github.com/flutter/flutter/issues/new?template=BUG.md https://github.com/flutter/flutter/issues/new?template=BUG.m...
  - cmroanirgo 7y ago
    Personally, I'd prefer actual native if that was my aim, as opposed to something that looks exactly like it, but actually has layers of styling beneath it in order to look the same. Why? Because if I want the native look, I'm more inclined to be sensitive to my app's size and performance. That said, I do understand that many people want the seeming of a native app, even if there's a bit of a blowout in size and performance... it's just not my cup of tea however. Here's a (random) post talking of performance of Native vs Flutter vs RN: https://thoughtbot.com/blog/examining-performance-differences-between-native-flutter-and-react-native-mobile-development https://thoughtbot.com/blog/examining-performance-difference... >I feel confident in saying that a native Android app will perform better than either a React Native app or a Flutter app
    - Hixie 7y ago
      Given our architecture, it doesn't cost us any more performance to look like the OEM widgets than a bespoke widget set, and indeed it shouldn't cost us any more to look like the OEM widgets than it should cost the OEM widgets themselves to look like the OEM widgets, because we're targeting the GPU directly.
      - s_y_n_t_a_x 7y ago
        It does cost more in developer hours though. Every update to every emulated UI requires an update on your end. There will be a lag between that update where apps will be noticeably different than native. Can you honestly guarantee Flutter will always keep up with all the environments you plan on targeting? Will Windows, MacOS, iOS, and Android always look and feel the same? That seems like a lot more work to maintain than building a bridge.
- aasasd 7y ago
  Qt vs WxWidgets all over again.
McDev 7y ago
Lots of businesses are desperate for cross platform mobile dev (I'm not looking at you <really well funded tech company with slick native apps>), it seems to be an inevitability at this point. In the meantime React Native has come along and I don't think it's made a good name for itself in the mobile dev world. RN projects get littered with poorly implemented third party libraries that aim to bridge a piece of native functionality or SDK into the react context. I've just spent the last 6 months as a contractor running around fixing companies' RN apps for Android that had obscure build issues and dependency problems, along with all the weird UI stuff that just doesn't work the same as it does on iOS and it's not been fun. After playing with Flutter for a bit it looks great. I just hope it isn't susceptible to the same issues I faced with React Native.
- tepidandroid 7y ago
  Agree with this. React Native development is just a horrible overall experience. The ecosystem is fragmented in so many ways with so many strange third party dependencies. It seems as if there is no 'best practice' yet. Its performance and resource usage hasn't been great either, compared to native. After messing with it for a couple of months, I would much, much rather duplicate my work with native Swift and Java/Kotlin codebases than one huge spaghetti code javascript codebase that I don't understand.
  - sievebrain 7y ago
    You can actually use Kotlin on iOS, look at the jetbrains samples for Kotlin/Native. You still need to use the iOS frameworks of course but all the genuinely OS independent code can be shared.
- michaelchisari 7y ago
  If they can avoid the issues of RN, then Dart/Flutter could be the go-to platform for early round applications that let you build a solid cross-platform app with which to prototype your business model. It will probably never be an ideal platform for mature, premium apps, but if it serves a purpose as the place to go to build a solid working MVP, then that's more than enough to keep it around.
pbreit 7y ago
I have so little faith in Google producing code that us usable by mere mortals. Could I please be proven wrong?
kllrnohj 7y ago
My experience with Flutter was it was only really suitable for UI code. Lack of efficient parallelisms among other things really kills the ability to do non-trivial work. If you happen to be able to stay in Flutter's async APIs then the illusion holds up OK, but otherwise you have to just kick over to native code to do anything interesting. At which point the multi-platform story obviously falls apart. It's really not unlike the web platform. If you're in the semi-narrowly supported "good" path it's great, but if you hit the limits of things you're pretty much immediately out of options. And also really bad interop with some really critical components like WebView.
- networkimprov 7y ago
  Maybe Flutter works as a client to a native localhost app? (Analogous to the browser for a localhost web app like Jupyter Notebook[1].) Does it have a Websocket client? [1] https://jupyter.org https://jupyter.org
  - kllrnohj 7y ago
    There's no reason to bother with websocket stuff, you can just call out to native code via platform channels ( https://flutter.dev/docs/development/platform-integration/platform-channels https://flutter.dev/docs/development/platform-integration/pl... ) Just that once you do that you're no longer a portable cross-platform app, and there's limits to what you can do with that pipe in terms of data marshaling and the overhead from that.
    - networkimprov 7y ago
      Unless you're porting an existing localhost web app which is accessed via Websockets.
  - Hixie 7y ago
    https://master-api.flutter.dev/flutter/dart-io/WebSocket-class.html https://master-api.flutter.dev/flutter/dart-io/WebSocket-cla...
PhilippGille 7y ago
> and in some cases, it’s obviously better than native development. Mainly because you can develop for both platforms Have you tried Xamarin?
- bradhoffman 7y ago
  I have not. I didn’t want to put the time into learning the .NET stack and C# because I am from a .NET town and did not want to get stuck here. What're your thoughts on it?
  - JamesSwift 7y ago
    I'm a native dev that is aggressively against the JS-based hybrid frameworks, and I will do every project in Xamarin from now on after working in it for a greenfield project. It's the best option out there until Kotlin Native gets legs.
    - mixmastamyk 7y ago
      Flutter has no js, or are you speaking about something else?
  - gwbas1c 7y ago
    C# is quickly becoming the "new C" in that it runs everywhere, and runs efficiently. It's worth learning the language because you can use it in so many places. It's not a case of "learn a new language for platform xxx."
    - Cyph0n 7y ago
      I think you mean the new Java. C and C# are very different beasts.
      - SneakerXZ 7y ago
        He is right. You should check more about C# before you correct others.
datavirtue 7y ago
Xamarin forms owns cross platform dev right now. Nothing can touch it.
on_and_off 7y ago
Flutter is a reasonable choice if you are developing a "simple" app that won't grow in scope. By simple I mean that you don't need anything special from the device, no access to the sensors, no deep integration with the OS. I think that enterprise apps would be an obvious target (because otherwise, for most of these small apps, the first question to answer is why not just have a website?) For everything else, go native.
MarkMc 7y ago
You might be interested to see a graph of Android, Flutter and React Native questions on Stack Overflow over time: http://sotagtrends.com/?tags=[ionic-framework,react-native,flutter,xamarin,android]&relative=true http://sotagtrends.com/?tags=[ionic-framework,react-native,f... Short version: Flutter is growing nicely

s_y_n_t_a_x 7y ago

On iOS it's obvious it uses emulated controls. I think if you want a fully themed app that looks the same across all environments, you should go with Flutter. If you want an app that looks the same as other native apps on the target environment, you should go with React Native.

saagarjha 7y ago
I’m not sure why this is downvoted, as it summarizes Flutter pretty well. Flutter’s “Cupertino” theme is obviously an emulation if you use it for more than a minute. If you want your app to look like an Android app on both platforms, though, I think it does pretty well at that.
- solarkraft 7y ago
  Do users care? It doesn't feel exactly native on Android, but is still fast and looks great (it might indeed be better than native). Afaik the main alternatives, RN and Web (for fully reusable UI) are both heavy and don't feel that native either, yet are popular with developers.
  - hn_throwaway_99 7y ago
    IMO, UI frameworks that try to mimic native components virtually always fail, because they end up being an almost-but-something-I-cant-put-my-finger-on-feels-wrong situation, e.g. performance isn't quite there or the physics is different. Much better IMO to go for a "minimalistic", neutral interface where people won't always be comparing your app to better native controls.
    - deleted 7y ago
      [deleted]
    - Apocryphon 7y ago
      That's why Google is trying to push Material as a default alternative to Cupertino widgets, perhaps.
  - saagarjha 7y ago
    As a user, I care quite a bit. As a developer, though, I get paid to tell people that their software doesn’t follow platform UI conventions and I run their code through mental checklists (“does the title animate properly during a controller pop, does this custom view break accessibility”) so I think it’s pretty obvious that I have a very specific slant on this issue. Keeping that in mind, I think that many users do care but they don’t necessarily make it the only thing they care about, nor are they particularly good about vocalizing their concerns. To them an app is just “weird”, or “unusable”, depending on what the framework actually breaks.
    - Klonoar 7y ago
      Slant is putting it mild - you gotta start putting a disclosure in these kinds of comments or something. You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech. You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter. I say this as someone who prefers native controls, has written/launched apps in ObjC/Swift/etc. There's increasingly little reason to bother with the stack.
      - saagarjha 7y ago
        > You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech. I dabble in Android and Linux as well ;) > You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter. Agree on both counts, but I like to think that users aren't completely clueless. There are certain things that they do feel acutely: animation physics that differ from the system's (particularly for things like scrolling), lag, choppiness, lack of proper accessibility support… > There's increasingly little reason to bother with the stack. I disagree with this (this isn't just an iOS thing, by the way: I would say the same for every other platform I've interacted with). It is almost certain to be the case that the team that wrote the platform libraries is smarter, better, and cared more than you did about the UI (there are some very notable exceptions, but I think it's very obvious when this is the case). Going with the native stack means lock-in and sometimes more work, but in exchange you get a significant amount of functionality "for free" (sometimes without even realizing that this functionality existed) and automatically share a common design language with the rest of the system, which is a usability plus for users almost all of the time.
  - afiori 7y ago
    I am using a lot of apps that still have a jellybean feeling to them, if it does not crashes and it is not a swipe-hell (I have an underpowered phone) it is fine to me.
  - dliff 7y ago
    RN definitely feels native... assuming the developers utilized the built-in components properly. RN is an actual native component whose state is backed by a JS bridge. There certainly are poorly written / optimized RN apps. There are also apps that due to their nature/goal shouldn't be RN even at an early stage. (Startup, navigation, threading, network issues for one). However, I would argue that a properly written RN app, within the confines of the problem RN attempts to solve, does not feel heavy and is actually indistinguishable from native. From my experience I would surmise a lot of badly performing RN apps stem from poorly written JavaScript, especially bad state management (lots of devs who perhaps have only written web JS in the past?).
    - monocularvision 7y ago
      Except for navigation
      - dliff 7y ago
        Curious where this is an issue. React Navigation feels and is, according to their documentation, composed of native components. Vs. what you can do natively it has severe limitations and the documentation isn't the best (though I think it has improved recently).. but feels native to me.
  - pier25 7y ago
    I use plenty of apps on both iOS and Android that do not use native controls such as Kindle and I really don't care as long as performance is good.
  - lone_haxx0r 7y ago
    To me, smartphones are like plungers: They are dirty, ugly (from a software perspective), and I don't like using them, but they are pretty convenient to have most of the time. I only want them to get the job done and then get out of my sight, so I don't care about the UI being pretty. I would say "elegance is reserved for desktop PCs", but those are ugly too (x86 is horrible, all OSs suck).
- afiori 7y ago
  The emulation is a feature with well understood trade offs. One of the point is to decouple as much as possible from the OS, I believe one of the advantages is that in flutter's mdoel it should be easier to make one-off apps that need less updates.
- vetinari 7y ago
  > If you want your app to look like an Android app on both platforms Funny thing is, that it is emulated on Android as well.
  - saagarjha 7y ago
    It is, but I trust a Google team to get that to work at least passably well.
    - Andrex 7y ago
      As someone who is highly discerning of small UI issues, Flutter on Android implements the UI controls extremely well to my eye. (Accessibility not so much unfortunately, but that is a work in progress.)
      - Hixie 7y ago
        If you're aware of areas where our accessibility support isn't up to par, please file a bug: https://github.com/flutter/flutter/issues/new?template=BUG.md https://github.com/flutter/flutter/issues/new?template=BUG.m...
  - aasasd 7y ago
    Like Android has any consistent UI at all. On my phone, two apps would have the same widgets only by accident.
Hixie 7y ago
(I'm the Flutter TL) If you can tell that we're not using OEM widgets, we consider that a bug. Please file it and explain what the difference is. We're definitely not perfect, but fidelity is a high priority for us this year. https://github.com/flutter/flutter/issues/new?template=BUG.md https://github.com/flutter/flutter/issues/new?template=BUG.m...
- cmroanirgo 7y ago
  Personally, I'd prefer actual native if that was my aim, as opposed to something that looks exactly like it, but actually has layers of styling beneath it in order to look the same. Why? Because if I want the native look, I'm more inclined to be sensitive to my app's size and performance. That said, I do understand that many people want the seeming of a native app, even if there's a bit of a blowout in size and performance... it's just not my cup of tea however. Here's a (random) post talking of performance of Native vs Flutter vs RN: https://thoughtbot.com/blog/examining-performance-differences-between-native-flutter-and-react-native-mobile-development https://thoughtbot.com/blog/examining-performance-difference... >I feel confident in saying that a native Android app will perform better than either a React Native app or a Flutter app
  - Hixie 7y ago
    Given our architecture, it doesn't cost us any more performance to look like the OEM widgets than a bespoke widget set, and indeed it shouldn't cost us any more to look like the OEM widgets than it should cost the OEM widgets themselves to look like the OEM widgets, because we're targeting the GPU directly.
    - s_y_n_t_a_x 7y ago
      It does cost more in developer hours though. Every update to every emulated UI requires an update on your end. There will be a lag between that update where apps will be noticeably different than native. Can you honestly guarantee Flutter will always keep up with all the environments you plan on targeting? Will Windows, MacOS, iOS, and Android always look and feel the same? That seems like a lot more work to maintain than building a bridge.
aasasd 7y ago
Qt vs WxWidgets all over again.

McDev 7y ago

Lots of businesses are desperate for cross platform mobile dev (I'm not looking at you <really well funded tech company with slick native apps>), it seems to be an inevitability at this point. In the meantime React Native has come along and I don't think it's made a good name for itself in the mobile dev world. RN projects get littered with poorly implemented third party libraries that aim to bridge a piece of native functionality or SDK into the react context. I've just spent the last 6 months as a contractor running around fixing companies' RN apps for Android that had obscure build issues and dependency problems, along with all the weird UI stuff that just doesn't work the same as it does on iOS and it's not been fun. After playing with Flutter for a bit it looks great. I just hope it isn't susceptible to the same issues I faced with React Native.

tepidandroid 7y ago
Agree with this. React Native development is just a horrible overall experience. The ecosystem is fragmented in so many ways with so many strange third party dependencies. It seems as if there is no 'best practice' yet. Its performance and resource usage hasn't been great either, compared to native. After messing with it for a couple of months, I would much, much rather duplicate my work with native Swift and Java/Kotlin codebases than one huge spaghetti code javascript codebase that I don't understand.
- sievebrain 7y ago
  You can actually use Kotlin on iOS, look at the jetbrains samples for Kotlin/Native. You still need to use the iOS frameworks of course but all the genuinely OS independent code can be shared.
michaelchisari 7y ago
If they can avoid the issues of RN, then Dart/Flutter could be the go-to platform for early round applications that let you build a solid cross-platform app with which to prototype your business model. It will probably never be an ideal platform for mature, premium apps, but if it serves a purpose as the place to go to build a solid working MVP, then that's more than enough to keep it around.

pbreit 7y ago

I have so little faith in Google producing code that us usable by mere mortals. Could I please be proven wrong?

kllrnohj 7y ago

My experience with Flutter was it was only really suitable for UI code. Lack of efficient parallelisms among other things really kills the ability to do non-trivial work. If you happen to be able to stay in Flutter's async APIs then the illusion holds up OK, but otherwise you have to just kick over to native code to do anything interesting. At which point the multi-platform story obviously falls apart. It's really not unlike the web platform. If you're in the semi-narrowly supported "good" path it's great, but if you hit the limits of things you're pretty much immediately out of options. And also really bad interop with some really critical components like WebView.

networkimprov 7y ago
Maybe Flutter works as a client to a native localhost app? (Analogous to the browser for a localhost web app like Jupyter Notebook[1].) Does it have a Websocket client? [1] https://jupyter.org https://jupyter.org
- kllrnohj 7y ago
  There's no reason to bother with websocket stuff, you can just call out to native code via platform channels ( https://flutter.dev/docs/development/platform-integration/platform-channels https://flutter.dev/docs/development/platform-integration/pl... ) Just that once you do that you're no longer a portable cross-platform app, and there's limits to what you can do with that pipe in terms of data marshaling and the overhead from that.
  - networkimprov 7y ago
    Unless you're porting an existing localhost web app which is accessed via Websockets.
- Hixie 7y ago
  https://master-api.flutter.dev/flutter/dart-io/WebSocket-class.html https://master-api.flutter.dev/flutter/dart-io/WebSocket-cla...

PhilippGille 7y ago

> and in some cases, it’s obviously better than native development. Mainly because you can develop for both platforms Have you tried Xamarin?

bradhoffman 7y ago
I have not. I didn’t want to put the time into learning the .NET stack and C# because I am from a .NET town and did not want to get stuck here. What're your thoughts on it?
- JamesSwift 7y ago
  I'm a native dev that is aggressively against the JS-based hybrid frameworks, and I will do every project in Xamarin from now on after working in it for a greenfield project. It's the best option out there until Kotlin Native gets legs.
  - mixmastamyk 7y ago
    Flutter has no js, or are you speaking about something else?
- gwbas1c 7y ago
  C# is quickly becoming the "new C" in that it runs everywhere, and runs efficiently. It's worth learning the language because you can use it in so many places. It's not a case of "learn a new language for platform xxx."
  - Cyph0n 7y ago
    I think you mean the new Java. C and C# are very different beasts.
    - SneakerXZ 7y ago
      He is right. You should check more about C# before you correct others.

datavirtue 7y ago

Xamarin forms owns cross platform dev right now. Nothing can touch it.

on_and_off 7y ago

Flutter is a reasonable choice if you are developing a "simple" app that won't grow in scope. By simple I mean that you don't need anything special from the device, no access to the sensors, no deep integration with the OS. I think that enterprise apps would be an obvious target (because otherwise, for most of these small apps, the first question to answer is why not just have a website?) For everything else, go native.

MarkMc 7y ago

You might be interested to see a graph of Android, Flutter and React Native questions on Stack Overflow over time: http://sotagtrends.com/?tags=[ionic-framework,react-native,flutter,xamarin,android]&relative=true http://sotagtrends.com/?tags=[ionic-framework,react-native,f... Short version: Flutter is growing nicely