Flutter allows the use of plugins which, through glue code, allow using native code and existing libraries. It's pretty comparable functionally to Java's JNI.
But, that's almost the same as not having support at all. JNI isn't really a poster-child of usability.
With Qt, since you're already on the right side of the fence, it's just a matter of "#include "whatever.h" and linking it at compile time.
I mean, even just getting a camera feed on Flutter isn't a built-in: https://pub.dartlang.org/packages/camera
(Disclosure: I'm a PM on the Flutter team.)
Obviously I don't know how you've structured responsibilities internally, but what I've seen before is, that the quality of individual components, or plugins if you will, live and die by the interest of the teams and people behind them.
Qt has this very same problem, often leading to some bugs ageing unacceptably long, or features never properly maturing, simply because there's little to no inside interest. NPM has a variant of the same problem as well. I'd venture a guess that a large percentage of packages on NPM right now, is downright abandonware.
I will be keeping a interested eye out for the developments of Flutter and I'm hopeful you succeed in this space. There's definitely room for it.
With regards to the native stuff, I'm mainly coming from a performance perspective on GPGPU and computer vision applications. I think going forward, there's going to be a huge increase in AR/MR apps, that will need easy access to do heavy lifting on metal. Coincidentally, I was lucky enough to catch a quick chat with Michael Thomsen, after his talk at Coldfront recently and he mentioned that, that was indeed on the roadmap. If you guys manage to provide the easiest cross platform way to do Vulkan/Metal or whatever the next-gen iOS and Android HAL is going to be, you're definitely going to come out on top.
Also not having a JSX like syntax. I went into RN expecting to hate JSX, but I ended up loving it.
Doing UI development with nested {} is so hideous in comparison. I am impressed at the quality of UIs Flutter can make, but the code behind them is, IMHO, much harder to read than the RN equivalent.
Why should it be built-in? That's such a C++ (or C) mindset: that using dependencies is bad, which stems from the difficulty of adding and updating dependencies in the C++ world.
In a language with a rock solid package manager, it's better to have a small core and then pull in what you need. Each of these out-of-core dependencies can have separate lifecycles, which makes it a lot easier for them to be developed and updated, making them higher quality. If breaking changes need to be made, that can easily be done in out-of-core libraries, since existing projects can continue depending on their SemVer-defined compatible version of the dependency ad infinitum, and the project maintainers can continue releasing updates to any SemVer series of the package if they need to backport changes to older versions. When something is in the core, it's very hard to update it while maintaining complete compatibility, and people can only depend on one version of your core library at a time, so there's no room to be flexible. This constricts growth, since the core needs to meet everyone's needs, but it doesn't have the flexibility to do that as the world changes, so it often meets no one's needs.
I don't know how good Dart's package manager is, since I haven't really touched Dart since the very earliest days of the language after it became public, but Rust's package manager is excellent, and having most things out-of-std has been great for the community. Futures and async have flourished out-of-std and gone through several very different approaches to gain real world experience. Some very small pieces of that ecosystem will be stabilized into the core language soon, but only the most bare minimum features to add the "await" keyword to the language. As much as possible will still remain in outside libraries.
In general, things go to stdlib to die.[0] The main exception I've seen with this over the years is Go, where they have done a really great job of maintaining and extending their huge batteries-included stdlib to the point that most people almost always recommend starting with the stdlib before reaching for a third-party package.
[0]: http://www.leancrew.com/all-this/2012/04/where-modules-go-to...
I agree that a truly solid package system, is inherently a good thing for any framework. But it has to be just that. Qt is severely lacking in that aspect; qpm isn't even close IMO.
Counter to your point though, just take a look at the ecosystem around NPM for instance. What a mess...
For a cross platform development framework, to truly shine, I need to be able to "trust", that my majority use case is covered within the framework itself, so I don't have to go package shopping and spend a lot of time on quality controlling vendored code.
For a mobile app framework, I want the most ubiquitous device capabilities covered. That means various hardware specific things, such as networking, gps, bluetooth and yes, the camera. Whatever is to be expected present on most devices.
So yeah, I guess it boils down to dependability and trust. Something which is implicit in the framework and core library for the most part.
Tim Sneath linked to the official plugins list in another comment, https://github.com/flutter/plugins, and both camera, sensors and connectivity, would be akin to the kind of ownership I'd expect. It's definitely a good start.
Please explain your logic here.