>... but I feel these are not really issues in practice (only in theory). Ha, I wish! I've been down this road a few times and this list came from contemplatin

>... but I feel these are not really issues in practice (only in theory). Ha, I wish! I've been down this road a few times and this list came from contemplating some of my old battle scars. > ...as `coldtea` points out below, this is not really an issue in today's ecosystem. That's not quite the same thing as it not being a problem. I know it can be done, but it's harder than when using native controls. This is something the "big dogs" can handle (they can bring massive resources to high-profile projects if need be) -- especially if they control the framework. > ...cases where code-heavy app sizes have actually hindered app downloads... Well, look around for people complaining about bloat. It's not usually the download itself, by the way. Memory is filled and runtimes have to initialize, buffers allocated, etc. It all takes time and uses runtime resources. This is fine to a point, but once you use too many resources or take too much time, it has a negative impact on the app (and as the developer, you have to deal with it in some way... e.g., perhaps spend time to alleviate the issues or perhaps walk away from lower-end devices). Any app, no matter the tech used to develop it can face these issues as it grows. But with an engine you start off closer to the limits and have less control over resource usage, so you generally reach them more quickly. > Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem? Hey, if flutter solves cross-platform text in 1.0 as you suggest, then good for them. Believe me, that's a massive accomplishment. (Though I'll note: if they aren't using native facilities, they'll have to duplicate them, which goes back to the point on bloat.) > Is this a remark on an incomplete cross platform framework...? No, I'm saying apps -- at some point -- generally eventually need to incorporate third-party libraries/tools to best accomplish their purpose. A PDF generator, a .csv parser, an image processor, an AI library, whatever. (A framework can't include an API for everything and shouldn't try, so it's not a matter of an incomplete framework). However whatever third-partly library you're interested in probably won't provide direct support for your framework, so you'll have to figure it out and do it yourself. It really depends on the library and the framework and how/whether they overlap how much harder this is. E.g., suppose you want to incorporate an image rendering library of some sort into your app. The library supports iOS and Android and can output to UIImage on iOS and Bitmap on Android and their site provides samples showing how each of these work. But you're using a framework that has "XImage" and "XImageView". So now you need to delve into the platform's "XImage" to figure out how to load a UIImage into it on iOS and a Bitmap on Android. Maybe you find it works in terms of OpenGL textures and you realize going through a UIImage/Bitmap is an extra, inefficient step, so now you're learning about how to load directly from the library output into an OpenGL texture and you learn OpenGL textures can have different color formats so you start using the complicated low-level API of the image library to get output in the color format of the OpenGL texture. Whew! What would have been a few lines of code in each native app turned into a couple days of work, but you're done and release it.... and shortly thereafter, you start getting reports that the images are flipped on certain devices. Uh Oh... Now, maybe flutter doesn't have this particular problem, but this is just an example. This kind of thing will pop up as you integrate the third-party libraries you use with the UI platform. The more "opinionated" the UI platform is, the more quickly you'll run into these kinds of problems. > This feels like an emotional assessment of having to learn something new. Oh, come on. I'm pointing out an additional cost to adopting this kind of platform. That's a real concern to anyone developing apps, not something you can dismiss as an "emotional assessment" (Not sure even what that means -- laziness?). Note, this is an additional cost since you'll need native expertise in any case.