12 ms·

Initial experience creating cross-platform apps with Flutter and Dart

90 points by charris0 9y ago

yawn 9y ago
> So Flutter is actually pushing pixels itself, sounds strange, but it works The siren song of cross-platform development sounds so sweet to the ears and I've fallen for it quite a few times only to get bitten in the end. Introducing another layer between you and the source has several drawbacks: it's an additional source for bugs, it makes you reliant on the middle man to be timely with updates to keep pace of the native changes and bug fixes, it can prevent you from using time-saving tooling for the native environment, etc. What happens when the native controls change? What do I see when I'm running an older native version?
- Aaargh20318 9y ago
  Yeah, been there, done that. The problem with building your own UI toolkit is that you can never make it feel native. You can get 90% there, but it always feels a bit off to the user. The more you make things look like native controls, the more users expect them to act like native controls and tiny differences get amplified.
  - weego 9y ago
    You're also only going to get any of the perceived benefits of the choice to build a custom UI kit if you're only solving the same problems that the framework authors were solving. If you suddenly need, as an example that I've come across, a list of stats to update with a high tick rate which is unusual in an app so no one optimises for it you'll likely find you're no longer anywhere near a native experience. I know that's not a unique problem with opinionated frameworks, but it's usually a programming issue to solve in the background, not a deal-breaker due to how every customer suffers.
  - MarkMc 9y ago
    I'm not sure 100% fidelity to native look and feel is so important to users, as long as the UI is fast, responsive and looks good. Spotify doesn't seem to have a problem with users despite its garish black and green appearance.
- rapsey 9y ago
  > The siren song of cross-platform development sounds so sweet to the ears and I've fallen for it quite a few times only to get bitten in the end. Indeed it is the much harder road to travel. It all depends on who is developing the platform however. Google can pull it off, which is why Flutter is worth considering.
- bsaul 9y ago
  Another issue is when your customer (or boss) ask you for this very simple feature that's found everywhere ( because it's a native sdk feature) and you suddenly realize you'll have the spend days if not weeks implementing it. I wouldn't be surprised if maps weren't as powerful in flutter as in native android or ios sdk for a long time. Still, i think the "low level / pixel level" approach that flutter took is the only one that makes sense. You can't abstract away GUI layers like the android one or the iOS one. it's just way too big, and they are themselves trying to abstract away discrepancies between OS versions. I don't understand how could anyone expect to get something of professional quality with a layer on top, knowing how hard it is to get it right even with the default tools. They are taking on a gargantuan task though..
  - matt2000 9y ago
    I’ve been writing a new project in Flutter and so far it’s been dramatically faster than writing an app with either of the native SDKs. The issue you mention here is the key downside though. For example, as far as I know there is no map component or video player. I don’t happen to need those, but if you did it’d be a deal breaker probably.
    - sethladd 9y ago
      (disclaimer: I work on Flutter) Thanks for the feedback. We're currently exploring how to do inline video, which we think will teach us about techniques for inline maps. These are very top requested features. Stay tuned! :)
- discreteevent 9y ago
  Fair points. It's worth stating though that this only matters if you have a requirement to look 100% native. Many apps don't have this requirement whether mobile or desktop and so they may use a web ui. In our case we didn't have the 100% native requirement and used Qt. We still had a really slick user interface, it just wasn't native. Note that our customers are primarily concerned about the functionality of the app: They are not drive by consumers, they come to the application because of it's functionality. I understand that not everyone has this kind of customer.
  - Illniyar 9y ago
    It's not just about the look, it's about the feel. From looking at the "gallery app" on android: Flutter's input-text has their own custom mark text handler - no double tap, long press opens a custom menu that is missing native options (Such as translate text). Changing the font size in the OS does nothing in the app. Clicking on buttons doesn't make a tap sound if the "sound on tap" option is set. I'm guessing no accessibility support - or very poor one. There's probably many more tiny issues that customer's will complain about when you a product is shipped to production that will make it clear that this isn't a native app.
    - sethladd 9y ago
      (disclaimer: I work on Flutter) Thanks for your feedback! I opened https://github.com/flutter/flutter/issues/12438 https://github.com/flutter/flutter/issues/12438 to track the "not playing a sound when tapped". We're currently working on improving our accessibility support.
    - Hixie 9y ago
      A lot of those are things we've fixed since we published that app. We're just not very good about publishing updates to the play store. I'll see if we can get an update out soon.
- sethladd 9y ago
  (disclaimer: I work on the Flutter team) > What do I see when I'm running an older native version? You will see exactly the pixels that your designer intended and your developer coded. :) Apps built with Flutter ship the renderer and framework inside the app, which helps ensure consistency and fidelity across devices, OEMs, OS, and platform. This is particularly important for brands that want a brand-first design delivered consistently to all their users. Hope that helps!
  - Numberwang 9y ago
    Thank you for replying in this thread. Another question. Why is there no desktop support?
    - kjksf 9y ago
      I'm not on their team but the answer is rather self-evident. There are 100x mobile developers than desktop developers which is why there's so much more investment in mobile tools than desktop tools. Also, this is Google-led project and Google doesn't write desktop apps (modulo few exceptions like Chrome). As every team, they have more work than they can manage, so they have to prioritize things that are important to them.
  - ape4 9y ago
    Not to diminish your amazing work. I'm not sure brand-first is user-first. Its most user-friendly to use the standard phone OS controls that they are already familiar with.
- mmargerum 9y ago
  The other issue is if this middle layer decides to stop supporting older os releases. We cannot force the users of our app to upgrade.
mamcx 9y ago
The thing I want for this kind of tools is to be a TRUE REPLACEMENTE of webviews. I don't wanna code in JS. No in Dart, but I can accept to use it ONLY for UI rendering. SO I can use F# or Swift or any other language. ie: I wanna to have a webview-html-css-alike "render screen" and let me use my own language in the back.
htormey 9y ago
I think the article would have been much better if the author had left out the section about RN. Failing that I would have liked to see him dig into why RN was slow for his use case and what he tried to do to fix theses issues. "While it uses the same React paradigm, there’s still a lot of differences.It seems performance is reduced significantly as your application and the react framework is controlling all the high level rendering functions from within a JavaScript control thread." It really seems like this person didn't spend a lot of time looking into performance when assessing React Native. Facebook have some really nice docs on this: https://facebook.github.io/react-native/docs/performance.html https://facebook.github.io/react-native/docs/performance.htm... They have a whole section on how to handle performance for user interactions/animations/etc which is well worth reading. Many RN related performance issues boil down to not being mindful of how javascript interacts with the native bridge. Tal Kol from Wix wrote a really great article about this, which you can find here: https://hackernoon.com/moving-beyond-animations-to-user-interactions-at-60-fps-in-react-native-b6b1fa0ba525 https://hackernoon.com/moving-beyond-animations-to-user-inte... I'm sure Flutter/Dart are great tools. It's just a little odd to see someone who know's React dismiss RN off handedly for performance reasons without making much of an effort to read the developer docs.
- fauigerzigerk 9y ago
  >Many RN related performance issues boil down to not being mindful of how javascript interacts with the native bridge. Yes, but being mindful of this architectural choice doesn't make it go away. It will always have to be worked around, which may add complexity depending on the specifics of the app. I haven't made my mind up about whether or not to use RN for an actual product. RN has a lot going for it, but this particular architectural choice is a negative in my view. The other concern I have is the lack of JIT on iOS. Or is that already a thing of the past? None of what I'm saying should be taken as some sort of firm assertion. My experience with RN is minimal. I'm keeping an open mind.
brett40324 9y ago
Some implementation features related to a few points in comments here so far, from Flutter faq here: https://flutter.io/faq/ https://flutter.io/faq/ How does Flutter run my code on Android? The engine’s C/C++ code is compiled with Android’s NDK, and the majority of the framework and application code is running as native code compiled by the Dart compiler. How does Flutter run my code on iOS? The engine’s C/C++ code is compiled with LLVM, and any Dart code is AOT-compiled into native code. The app runs using the native instruction set (no interpreter is involved). Does Flutter use my system’s OEM widgets? No. Instead, Flutter provides a set of widgets (including Material Design and Cupertino (iOS-styled) widgets), managed and rendered by Flutter’s framework and engine. You can browse a catalog of Flutter’s widgets. We are hoping the end-result will be higher quality apps. If we reused the OEM widgets, the quality and performance of Flutter apps would be limited by the quality of those widgets. In Android, for example, there’s a hard-coded set of gestures and fixed rules for disambiguating them. In Flutter, you can write your own gesture recognizer that is a first-class participant in the gesture system. Moreover, two widgets authored by different people can coordinate to disambiguate gestures. Modern app design trends point towards designers and users wanting more motion-rich UIs and brand-first designs. In order to achieve that level of customized, beautiful design, Flutter is architectured to drive pixels instead of the OEM widgets. By using the same renderer, framework, and set of widgets, we make it easier to publish for both iOS and Android concurrently, without having to do careful and costly planning to align two separate codebases and feature sets. By using a single language, a single framework, and a single set of libraries for all of your UI (regardless if your UI is different for each mobile platform or largely consistent), we also aim to help lower app development and maintenance costs. What happens when my mobile OS updates and introduces new widgets? The Flutter team watches the adoption and demand for new mobile widgets from iOS and Android, and aims to work with the community to build support for new widgets. This work may come in the form of lower-level framework features, new composable widgets, or new widget implementations. Flutter’s layered architecture is designed to support numerous widget libraries, and we encourage and support the community in building and maintaining widget libraries. What happens when my mobile OS updates and introduces new platform capabilities? Flutter’s interop and plugin system is designed to allow developers to access new mobile OS features and capabilities immediately. Developers don’t have to wait for the Flutter team to expose the new mobile OS capability.
bsaul 9y ago
I'm amazed at the number of original projects i see done with Dart. Yet it always seems to be ambitious prototypes as if the language was still looking for its "ruby on rail" moment. Not that there would be anything wrong with that, but when you combine this impression with reading titles like "google coding its next OS with dart", you wonder if this language is google's secret weapon, or if all of it is just a marketing attempt.
MarkMc 9y ago
If you have an Android phone, a good demonstration of flutter is the gallery app: https://play.google.com/store/apps/details?id=io.flutter.gallery https://play.google.com/store/apps/details?id=io.flutter.gal... There doesn't seem to be an equivalent iOS app, which is kind of strange for a product whose whole purpose is cross platform development. But maybe it's not allowed on the App Store because it's alpha or just a demo.
roughike 9y ago
As a native mobile developer of several years, I've always been somewhat skeptical of the various cross-platform solutions that have emerged over the years. The WebView-based solutions weren't fast enough and sometimes behaved differently across devices because of different WebView versions. With React Native, the impression was far better because the performance actually can be quite good. But it's still hard to abstract the UI layer away when even the native Views on Android behave differently across devices and Android versions. I had to use almost a half of a day for fixing invisible drop-down menu items on some specific Samsung device on Android 4.1.2. Not to mention when you have to abstract the UI for both Android & iOS, which brings its own set of problems. It's one of the reasons why such a fundamental thing as navigation has been so hard to get right. I feel Flutter is the first cross-platform SDK that gets something fundamentally right. Since every pixel on the UI is rendered by the framework, we as developers have better control of everything. It's going to have much better performance because there are no bridges between native and cross-platform land. Additionally, Samsung can't fuck up our UIs: once the UI works, it works the same on every device. As a bonus, they also keep tremendous care of their codebase and they have the best documentation I've ever seen. My really simple, quick 4-line fix didn't go through until I wrote 30 lines of automated tests to go with it. After all, Flutter is going to be the native SDK for developing apps for Fuchsia, and I think Google has learned not to repeat the same mistakes that happened with Android again.
- discreteevent 9y ago
  In fairness Qt also gets this right: It renders every pixel and it has a fast rendering architecture. Having used Qt, flutter is very attractive to me for the case where you have to work with a team. It can be hard to get together enough people nowadays who will want to work with even a little C++. The Qt libraries make it very easy IMO (most stuff is ref counted) but not everyone is going to buy that.
  - mherrmann 9y ago
    I use the PyQt Python bindings to Qt for exactly that reason(?) It works very well for my file manager [1]. [1]: https://fman.io https://fman.io
bitwize 9y ago
No. You use native UI widgets or you gtfo. This may seem strange to us Linux folks, who are used to making do with any old UI. But Apple users are UI supertasters. If anything is a tiny bit off -- a bounding box one pixel too short, a response to button click one millisecond too laggy -- Apple users will notice, and Apple users will complain, and it will be reflected in your app's sales/metrics. At least on iOS, it's worth it to use the native widgets.
- copperx 9y ago
  You're insane if you think that most users are like that.
- symlinkk 9y ago
  Yeah, Snapchat would have been successful if only they used native widgets...
lninyo 9y ago
This article could use some serious grammarly love. Its painfull two reed!
Zigurd 9y ago
Life is hard for cross-platform environments. Cross-platform apps, never mind runtimes and sdks, don't have wide use. React Native is the only notable exception. While tools like Xamarin can make a living, that's mostly outside of mass market apps. Web apps on JS are the most compelling example of an app ecosystem that has come unmoored from underlying OSs, but iOS and Android have brought back the dominance of native apps, because the underlying platforms and their capabilities are interesting and useful. Maybe Flutter is a good UI stack for Fuchsia, and maybe easy Web app compatibility would be a boost to both Flutter and Fuchsia, but it will be tough sledding to get Flutter apps accepted by Android and iOS users. Flutter needs to find a place where it is essential, not a compromise for developers searching for a panacea. The reason Java is the most widely used language is that Android turned Java into a platform-specific, UI-stack-specific app language. The irony is that, because of the mountain of highly capable modern mobile apps, I'd bet that the Android runtime on ChromeOS quickly becomes the most widely used cross-platform runtime, in terms of the number of apps actually used by people and running on multiple platforms.
chickenbane 9y ago
Coincidentally I just saw this video by Eric Seidel (the lead of the Flutter team) talking about the stack of Flutter: https://www.youtube.com/watch?v=VUiVkDpikDI https://www.youtube.com/watch?v=VUiVkDpikDI
programmarchy 9y ago
Side story... I wish you guys hadn't killed Apportable. It was such an awesome product! From what I could gather, Google acquihired the Apportable team, which then pivoted to Flutter. For anyone that doesn't know, Apportable was an Obj-C to native Android compiler. It bypassed the JVM, compiling directly to the native architecture, and actually ran faster than comparable Java apps. As a compromise, it also had a Java bridging interface to hook into Android APIs. It was mainly targeted at games which used Cocos2D, but a UIKit bridge was in the works... When I first heard about Apportable, I was incredibly wary of their claim, but it worked like absolute magic. I was able to successfully port several Cocos2D apps directly to Android with almost no intervention. Anyway, assuming the core team is still intact, if there is anyone that can pull off what Flutter is claiming to do, it's these folks.
oweiler 9y ago
Flutter itself seems nice but I can't stand Dart. It's an okay language but isn't expressive enough for a modern language.
- mraleph 9y ago
  > but isn't expressive enough for a modern language. What do you miss?

90 points by charris0 9y ago

yawn 9y ago

> So Flutter is actually pushing pixels itself, sounds strange, but it works The siren song of cross-platform development sounds so sweet to the ears and I've fallen for it quite a few times only to get bitten in the end. Introducing another layer between you and the source has several drawbacks: it's an additional source for bugs, it makes you reliant on the middle man to be timely with updates to keep pace of the native changes and bug fixes, it can prevent you from using time-saving tooling for the native environment, etc. What happens when the native controls change? What do I see when I'm running an older native version?

Aaargh20318 9y ago
Yeah, been there, done that. The problem with building your own UI toolkit is that you can never make it feel native. You can get 90% there, but it always feels a bit off to the user. The more you make things look like native controls, the more users expect them to act like native controls and tiny differences get amplified.
- weego 9y ago
  You're also only going to get any of the perceived benefits of the choice to build a custom UI kit if you're only solving the same problems that the framework authors were solving. If you suddenly need, as an example that I've come across, a list of stats to update with a high tick rate which is unusual in an app so no one optimises for it you'll likely find you're no longer anywhere near a native experience. I know that's not a unique problem with opinionated frameworks, but it's usually a programming issue to solve in the background, not a deal-breaker due to how every customer suffers.
- MarkMc 9y ago
  I'm not sure 100% fidelity to native look and feel is so important to users, as long as the UI is fast, responsive and looks good. Spotify doesn't seem to have a problem with users despite its garish black and green appearance.
rapsey 9y ago
> The siren song of cross-platform development sounds so sweet to the ears and I've fallen for it quite a few times only to get bitten in the end. Indeed it is the much harder road to travel. It all depends on who is developing the platform however. Google can pull it off, which is why Flutter is worth considering.
bsaul 9y ago
Another issue is when your customer (or boss) ask you for this very simple feature that's found everywhere ( because it's a native sdk feature) and you suddenly realize you'll have the spend days if not weeks implementing it. I wouldn't be surprised if maps weren't as powerful in flutter as in native android or ios sdk for a long time. Still, i think the "low level / pixel level" approach that flutter took is the only one that makes sense. You can't abstract away GUI layers like the android one or the iOS one. it's just way too big, and they are themselves trying to abstract away discrepancies between OS versions. I don't understand how could anyone expect to get something of professional quality with a layer on top, knowing how hard it is to get it right even with the default tools. They are taking on a gargantuan task though..
- matt2000 9y ago
  I’ve been writing a new project in Flutter and so far it’s been dramatically faster than writing an app with either of the native SDKs. The issue you mention here is the key downside though. For example, as far as I know there is no map component or video player. I don’t happen to need those, but if you did it’d be a deal breaker probably.
  - sethladd 9y ago
    (disclaimer: I work on Flutter) Thanks for the feedback. We're currently exploring how to do inline video, which we think will teach us about techniques for inline maps. These are very top requested features. Stay tuned! :)
discreteevent 9y ago
Fair points. It's worth stating though that this only matters if you have a requirement to look 100% native. Many apps don't have this requirement whether mobile or desktop and so they may use a web ui. In our case we didn't have the 100% native requirement and used Qt. We still had a really slick user interface, it just wasn't native. Note that our customers are primarily concerned about the functionality of the app: They are not drive by consumers, they come to the application because of it's functionality. I understand that not everyone has this kind of customer.
- Illniyar 9y ago
  It's not just about the look, it's about the feel. From looking at the "gallery app" on android: Flutter's input-text has their own custom mark text handler - no double tap, long press opens a custom menu that is missing native options (Such as translate text). Changing the font size in the OS does nothing in the app. Clicking on buttons doesn't make a tap sound if the "sound on tap" option is set. I'm guessing no accessibility support - or very poor one. There's probably many more tiny issues that customer's will complain about when you a product is shipped to production that will make it clear that this isn't a native app.
  - sethladd 9y ago
    (disclaimer: I work on Flutter) Thanks for your feedback! I opened https://github.com/flutter/flutter/issues/12438 https://github.com/flutter/flutter/issues/12438 to track the "not playing a sound when tapped". We're currently working on improving our accessibility support.
  - Hixie 9y ago
    A lot of those are things we've fixed since we published that app. We're just not very good about publishing updates to the play store. I'll see if we can get an update out soon.
sethladd 9y ago
(disclaimer: I work on the Flutter team) > What do I see when I'm running an older native version? You will see exactly the pixels that your designer intended and your developer coded. :) Apps built with Flutter ship the renderer and framework inside the app, which helps ensure consistency and fidelity across devices, OEMs, OS, and platform. This is particularly important for brands that want a brand-first design delivered consistently to all their users. Hope that helps!
- Numberwang 9y ago
  Thank you for replying in this thread. Another question. Why is there no desktop support?
  - kjksf 9y ago
    I'm not on their team but the answer is rather self-evident. There are 100x mobile developers than desktop developers which is why there's so much more investment in mobile tools than desktop tools. Also, this is Google-led project and Google doesn't write desktop apps (modulo few exceptions like Chrome). As every team, they have more work than they can manage, so they have to prioritize things that are important to them.
- ape4 9y ago
  Not to diminish your amazing work. I'm not sure brand-first is user-first. Its most user-friendly to use the standard phone OS controls that they are already familiar with.
mmargerum 9y ago
The other issue is if this middle layer decides to stop supporting older os releases. We cannot force the users of our app to upgrade.

mamcx 9y ago

The thing I want for this kind of tools is to be a TRUE REPLACEMENTE of webviews. I don't wanna code in JS. No in Dart, but I can accept to use it ONLY for UI rendering. SO I can use F# or Swift or any other language. ie: I wanna to have a webview-html-css-alike "render screen" and let me use my own language in the back.

htormey 9y ago

I think the article would have been much better if the author had left out the section about RN. Failing that I would have liked to see him dig into why RN was slow for his use case and what he tried to do to fix theses issues. "While it uses the same React paradigm, there’s still a lot of differences.It seems performance is reduced significantly as your application and the react framework is controlling all the high level rendering functions from within a JavaScript control thread." It really seems like this person didn't spend a lot of time looking into performance when assessing React Native. Facebook have some really nice docs on this: https://facebook.github.io/react-native/docs/performance.html https://facebook.github.io/react-native/docs/performance.htm... They have a whole section on how to handle performance for user interactions/animations/etc which is well worth reading. Many RN related performance issues boil down to not being mindful of how javascript interacts with the native bridge. Tal Kol from Wix wrote a really great article about this, which you can find here: https://hackernoon.com/moving-beyond-animations-to-user-interactions-at-60-fps-in-react-native-b6b1fa0ba525 https://hackernoon.com/moving-beyond-animations-to-user-inte... I'm sure Flutter/Dart are great tools. It's just a little odd to see someone who know's React dismiss RN off handedly for performance reasons without making much of an effort to read the developer docs.

fauigerzigerk 9y ago
>Many RN related performance issues boil down to not being mindful of how javascript interacts with the native bridge. Yes, but being mindful of this architectural choice doesn't make it go away. It will always have to be worked around, which may add complexity depending on the specifics of the app. I haven't made my mind up about whether or not to use RN for an actual product. RN has a lot going for it, but this particular architectural choice is a negative in my view. The other concern I have is the lack of JIT on iOS. Or is that already a thing of the past? None of what I'm saying should be taken as some sort of firm assertion. My experience with RN is minimal. I'm keeping an open mind.

brett40324 9y ago

Some implementation features related to a few points in comments here so far, from Flutter faq here: https://flutter.io/faq/ https://flutter.io/faq/ How does Flutter run my code on Android? The engine’s C/C++ code is compiled with Android’s NDK, and the majority of the framework and application code is running as native code compiled by the Dart compiler. How does Flutter run my code on iOS? The engine’s C/C++ code is compiled with LLVM, and any Dart code is AOT-compiled into native code. The app runs using the native instruction set (no interpreter is involved). Does Flutter use my system’s OEM widgets? No. Instead, Flutter provides a set of widgets (including Material Design and Cupertino (iOS-styled) widgets), managed and rendered by Flutter’s framework and engine. You can browse a catalog of Flutter’s widgets. We are hoping the end-result will be higher quality apps. If we reused the OEM widgets, the quality and performance of Flutter apps would be limited by the quality of those widgets. In Android, for example, there’s a hard-coded set of gestures and fixed rules for disambiguating them. In Flutter, you can write your own gesture recognizer that is a first-class participant in the gesture system. Moreover, two widgets authored by different people can coordinate to disambiguate gestures. Modern app design trends point towards designers and users wanting more motion-rich UIs and brand-first designs. In order to achieve that level of customized, beautiful design, Flutter is architectured to drive pixels instead of the OEM widgets. By using the same renderer, framework, and set of widgets, we make it easier to publish for both iOS and Android concurrently, without having to do careful and costly planning to align two separate codebases and feature sets. By using a single language, a single framework, and a single set of libraries for all of your UI (regardless if your UI is different for each mobile platform or largely consistent), we also aim to help lower app development and maintenance costs. What happens when my mobile OS updates and introduces new widgets? The Flutter team watches the adoption and demand for new mobile widgets from iOS and Android, and aims to work with the community to build support for new widgets. This work may come in the form of lower-level framework features, new composable widgets, or new widget implementations. Flutter’s layered architecture is designed to support numerous widget libraries, and we encourage and support the community in building and maintaining widget libraries. What happens when my mobile OS updates and introduces new platform capabilities? Flutter’s interop and plugin system is designed to allow developers to access new mobile OS features and capabilities immediately. Developers don’t have to wait for the Flutter team to expose the new mobile OS capability.

bsaul 9y ago

I'm amazed at the number of original projects i see done with Dart. Yet it always seems to be ambitious prototypes as if the language was still looking for its "ruby on rail" moment. Not that there would be anything wrong with that, but when you combine this impression with reading titles like "google coding its next OS with dart", you wonder if this language is google's secret weapon, or if all of it is just a marketing attempt.

MarkMc 9y ago

If you have an Android phone, a good demonstration of flutter is the gallery app: https://play.google.com/store/apps/details?id=io.flutter.gallery https://play.google.com/store/apps/details?id=io.flutter.gal... There doesn't seem to be an equivalent iOS app, which is kind of strange for a product whose whole purpose is cross platform development. But maybe it's not allowed on the App Store because it's alpha or just a demo.

roughike 9y ago

As a native mobile developer of several years, I've always been somewhat skeptical of the various cross-platform solutions that have emerged over the years. The WebView-based solutions weren't fast enough and sometimes behaved differently across devices because of different WebView versions. With React Native, the impression was far better because the performance actually can be quite good. But it's still hard to abstract the UI layer away when even the native Views on Android behave differently across devices and Android versions. I had to use almost a half of a day for fixing invisible drop-down menu items on some specific Samsung device on Android 4.1.2. Not to mention when you have to abstract the UI for both Android & iOS, which brings its own set of problems. It's one of the reasons why such a fundamental thing as navigation has been so hard to get right. I feel Flutter is the first cross-platform SDK that gets something fundamentally right. Since every pixel on the UI is rendered by the framework, we as developers have better control of everything. It's going to have much better performance because there are no bridges between native and cross-platform land. Additionally, Samsung can't fuck up our UIs: once the UI works, it works the same on every device. As a bonus, they also keep tremendous care of their codebase and they have the best documentation I've ever seen. My really simple, quick 4-line fix didn't go through until I wrote 30 lines of automated tests to go with it. After all, Flutter is going to be the native SDK for developing apps for Fuchsia, and I think Google has learned not to repeat the same mistakes that happened with Android again.

discreteevent 9y ago
In fairness Qt also gets this right: It renders every pixel and it has a fast rendering architecture. Having used Qt, flutter is very attractive to me for the case where you have to work with a team. It can be hard to get together enough people nowadays who will want to work with even a little C++. The Qt libraries make it very easy IMO (most stuff is ref counted) but not everyone is going to buy that.
- mherrmann 9y ago
  I use the PyQt Python bindings to Qt for exactly that reason(?) It works very well for my file manager [1]. [1]: https://fman.io https://fman.io

bitwize 9y ago

No. You use native UI widgets or you gtfo. This may seem strange to us Linux folks, who are used to making do with any old UI. But Apple users are UI supertasters. If anything is a tiny bit off -- a bounding box one pixel too short, a response to button click one millisecond too laggy -- Apple users will notice, and Apple users will complain, and it will be reflected in your app's sales/metrics. At least on iOS, it's worth it to use the native widgets.

copperx 9y ago
You're insane if you think that most users are like that.
symlinkk 9y ago
Yeah, Snapchat would have been successful if only they used native widgets...

lninyo 9y ago

This article could use some serious grammarly love. Its painfull two reed!

Zigurd 9y ago

Life is hard for cross-platform environments. Cross-platform apps, never mind runtimes and sdks, don't have wide use. React Native is the only notable exception. While tools like Xamarin can make a living, that's mostly outside of mass market apps. Web apps on JS are the most compelling example of an app ecosystem that has come unmoored from underlying OSs, but iOS and Android have brought back the dominance of native apps, because the underlying platforms and their capabilities are interesting and useful. Maybe Flutter is a good UI stack for Fuchsia, and maybe easy Web app compatibility would be a boost to both Flutter and Fuchsia, but it will be tough sledding to get Flutter apps accepted by Android and iOS users. Flutter needs to find a place where it is essential, not a compromise for developers searching for a panacea. The reason Java is the most widely used language is that Android turned Java into a platform-specific, UI-stack-specific app language. The irony is that, because of the mountain of highly capable modern mobile apps, I'd bet that the Android runtime on ChromeOS quickly becomes the most widely used cross-platform runtime, in terms of the number of apps actually used by people and running on multiple platforms.

chickenbane 9y ago

Coincidentally I just saw this video by Eric Seidel (the lead of the Flutter team) talking about the stack of Flutter: https://www.youtube.com/watch?v=VUiVkDpikDI https://www.youtube.com/watch?v=VUiVkDpikDI

programmarchy 9y ago

Side story... I wish you guys hadn't killed Apportable. It was such an awesome product! From what I could gather, Google acquihired the Apportable team, which then pivoted to Flutter. For anyone that doesn't know, Apportable was an Obj-C to native Android compiler. It bypassed the JVM, compiling directly to the native architecture, and actually ran faster than comparable Java apps. As a compromise, it also had a Java bridging interface to hook into Android APIs. It was mainly targeted at games which used Cocos2D, but a UIKit bridge was in the works... When I first heard about Apportable, I was incredibly wary of their claim, but it worked like absolute magic. I was able to successfully port several Cocos2D apps directly to Android with almost no intervention. Anyway, assuming the core team is still intact, if there is anyone that can pull off what Flutter is claiming to do, it's these folks.

oweiler 9y ago

Flutter itself seems nice but I can't stand Dart. It's an okay language but isn't expressive enough for a modern language.

mraleph 9y ago
> but isn't expressive enough for a modern language. What do you miss?