Flutter doesn't use native controls . It draws everything. Just pointing out that difference.

FWIW, the Apple developers discussing SwiftUI on Twitter are careful to point out that SwiftUI is not designed to be a wrapper around UIKit. Much of the implementation currently uses UIKit under the hood, but that's an implementation detail that is subject to change and there are already significant parts of SwiftUI that don't use it.

It seems as though they are viewing SwiftUI as a successor to UIKit/AppKit on all their platforms, not just a higher level wrapper.

Native controls aren't drawn too?

yes, they're drawn too. but, i think what the above comment is pointing out is that Flutter itself does the drawing, instead of delegating the drawing to iOS or Android native widgets.

Actually no, Flutter doesn’t do the drawing. It’s done by Skia, much like Cocoa native controls are drawn by Quartz.

There isn’t much of a difference between Flutter controls and native controls, other than being a reimplementation in some cases.

> other than being a reimplementation in some cases.

Hmm...that's pretty much the entire difference between native and non-native controls.

Yes, and that is precisely my point.

A previous commenter implied that there somehow native controls were technically different than Flutter controls.

Obviously the rendering stack is different but Skia is as native as Quartz is.

That was the exact opposite of my point.

Native widgets are those of the native widget toolkit. I can use the underlying drawing libraries to draw widgets that look vastly different and implement behaviours that behave vastly differently from the native widget toolkit.

The point of native widgets is that they are the same, not that they are drawn using the same underlying technology.

So the fact that you are using platform libraries to draw those non-native widgets is not at all relevant. After all, what else are you going to be using?

> There isn’t much of a difference between Flutter controls and native controls

Except they're not actually native controls. They're reimplementations of them. It is a very important distinction.

> There isn’t much of a difference between Flutter controls and native controls

Except that they behave quite differently…

I meant technically speaking. Obviously the implementation or the user experience are a different matter.

another noteworthy difference is that the look and feel of a widget is locked down at compile time in a Flutter app.

by contrast, with a native android app, the look and feel of the widget can change on an end user's device when the end user updates android on their particular device.

More than just drawing. They have to reimplement all of the behaviors of the built in controls. I'm sure google is up to the task, but my experience has been there's always things missing and and lag behind native .

> there's always things missing and and lag behind native

Flutter specifically or cross-platform UI frameworks in general?

I don't mind it being different, but does the app feel unpolished?

Jetpack Composer you mean.

I bet by next IO, Flutter will get replaced by it, specially after the #KotlinEverywhere announcement and Kotlin/Native effort for iOS.

Flutter is cross platform. I looked for it but didn't see where jetpack has this capability. Please post me a link if I’m wrong, I would follow this project if it does support cross platform development.

Jetpack Compose was announced at IO: https://blog.karumi.com/android-jetpack-compose-review/

No he means Flutter which has been around a lot longer, it's immediately what I've thought of being inspired by as well:

https://flutter.dev/docs/development/tools/hot-reload

I know pretty much what he/she meant, was just making a point that I don't believe in Flutter's long term success.

Trying to sell Dart a 2nd time was a mistake.

Flutter's not a PR campaign for Dart, they're a separate project that chose Dart based on its technical capabilities [1].

Given Flutter enables the nicest native x-plat dev experience today I'd say it has a very bright future, which they've also recently announced Flutter for Desktop and Embedded devices.

Jetpack compose is years away from the same kind of x-plat support that Flutter's providing for Mobile, Web, Desktop and Embedded [2].

[1] https://flutter.dev/docs/resources/faq#why-did-flutter-choos...

[2] https://developers.googleblog.com/2019/05/Flutter-io19.html

That after-the-fact reasoning link that gets posted every time someone questions Dart is well known, no need to give it to me.

Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities".

Flutter is a way to rescue Dart, plain and simple.

Yes, Jetpack Compose might be doing its baby steps, but I am betting most developers are more keen in having Kotlin than Dart on their CV, specially after Dart v 1.0's demise.

And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.

> no need to give it to me.

Think highly of yourself much? But I'll be continuing to provide links as I see it's relevant and informative, my comments are not just for your benefit, readers can make their own mind whose opinions are more informed - "no need" to tell others how to comment.

> Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities".

Am I meant to be impressed by this list of languages? I'm not. Are the number of languages meant to give your inexperienced opinion on Flutter's development environment some credence or is this washy strawman meant to downplay anyone else's opinion who wasn't a developer in the 90's when these languages were more relevant?

What matters is what's relevant now and Flutter lets you build modern x-plat Mobile, Web, Desktop and Embedded Apps with productive Live Hot Reload environment that's both fast at development and runtime which can be run in a JIT VM, as AOT compiled or transpiled to tree-shaken JS. Which of these above languages provides a more productive and "technically impressive" environment to develop iOS/Android, Web and Embedded Apps than Dart/Flutter?

> Flutter is a way to rescue Dart, plain and simple.

Adding "plain and simple" to an baseless opinion doesn't re-enforce it, including links that backs up this wild speculation will. What information have you used to be able present this opinion as fact so staunchly? Do you really believe Google invented and funded the Flutter project out of thin air to give Dart a popularity boost?

> And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.

How can Android have more political power for Fuchsia than Dart which is what most of its UI is written in? You can also develop Flutter Apps on Chrome OS so that's no different. Chrome OS is still primarily a Web OS, allowing running Android Apps doesn't make it an OS for running Android Apps and devs aren't going to be lining up to develop Chrome OS Apps using Android.

Flutter's strength's is that you can develop x-plat App's that looks, behaves and runs natively on all its supported platforms - feel free to wait until Kotlin reaches the same maturity on iOS before declaring it a Flutter killer. Kotlin still suffers from Android's complicated and fragile tooling and from what I've seen with JetPack compose it's highly coupled to Android - it's going to take a long time before they'll let you build iOS/Android Apps from a single code base.

What information have I used?

Besides Dart v1.0, Dartium, Angular Dart when they were still relevant to Chrome and Angular teams, and following up on Flutter?

I usually only criticize stuff that I actually have some level of experience with.

AdWords team rescued Flutter, after Chrome and Angular teams stop caring, which even caused Dart designers like Gilad to leave in disagreement.

I believe that they found out some internal management support that is willing to give them a time frame, of lets say 5 years to prove themselves worthy of such support.

Android has more political power ChromeOS has adopted Android and not the other way around, the two commercial OSes from Google.

While their experimental OS, Fuchsia is now adding support to run ART, while at the same time via Scenic, decoupling themselves from the UI framework.

You want to believe in Dart/Flutter, go for it.

Me, I am betting it will be joining the list of abandoned Google projects in a couple of years.

I think dart/flutter serves primarily two purposes, as I see it. First the obvious one, Google is trying to get devs used to flutter as when the time comes to switch to Fuchsia/Zircon, it would be relatively a breeze.

Secondly, and the most immediate reason, I think it's a very clever and clear move from Google to lock-in devs into using Google Cloud services like Firebase and Cloud ML services by leveraging Flutter. If you have observed, Microsoft has given a rebirth to their Xamarin developers YouTube channel and have been hosting 'The Xamarin Show', which is, hmm, quite similar to 'The Boring Flutter Development Show'.

It looks like Jetpack Compose is not really done yet. It's pre-alpha and the Jetpack Compose doc page says don't use it for production. https://developer.android.com/jetpack/compose/

I may be missing something, but SwiftUI seems to be pretty much ready to go today.

You are missing the fact that Android team doesn't want to have anything to do with Dart, and started a Kotlin everywhere initiative, including iOS via Kotlin/Native.

Ready to go today if you're only supporting iOS 13+

Which for most companies is 2+ years away

To add a bit more detail: the required level for other Apple OSs are macOS 15+, tvOS 13+ and watchOS 6+.

I stand corrected. thanks.

Except it’s not ready to go because it’s not backwards compatible it seems.

Indeed, but (unsurprisingly) Apple-only.

It does, in a good way. I really liked Flutter's UI approach.

But native, of course.

And proprietary.

Jetpack Compose is more like it