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.
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.
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?
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 .
