> if Flutter is only relevant for apps, that's a pretty small niche.

No it is not. Mobile apps are thriving. It is desktop apps that are niche now.

> ditching Flutter and using web tech for mobile too sounds like the better bet?

Quite possibly yes.

I meant it's a small niche for Flutter to address only the apps that want to be cross-platform, don't want to invest into having "native" iOS and Android versions, but are Ok with using a different technology for desktop/web (or don't need those).

It is not a small niche at all. A ton of things are mobile first/only.

And plenty of well known companies have discovered that mastering two native stacks is still easier and cheaper in the long run, than mastering a "cross-platform stack" framework + dealing with leaky abstractions + build integration issues + having to master the native stack anyway.

Either go mobile Web, or native.

Yep, a good example is the element X rewrite

They use Jetpack on Android

https://github.com/vector-im/element-x-android

And SwiftUI on iOS

https://github.com/vector-im/element-x-ios

But both use the same underlying Matrix Rust SDK

https://github.com/matrix-org/matrix-rust-sdk

So they share the core part of the app between platforms, but everything user facing is native

You know, this is a solved problem. Qt, for example, can easily do it (and has been able to do it for 10+ years, from microcontrollers to phones). And, just saying, QT is damn fast, a necessity if you want to work on microcontrollers of course. And yes, you can do it without royalties, without paying for QT, and in multiple languages (at least C++ and Python work pretty well).

(oh, and QT supports 3d, on the web, on android, on ios, and on desktop, even on microcontrollers if needed)

And yes, Javascript's advantage has been that it was cross-platform pretty early on. Not particularly fast though, not even decades later.

And everybody keeps pointing out the same shortcoming: these frameworks let you share a lot of code, but mostly not the actual "View" (the V in model/view/controller) code, due to screen sizes, whether the UI can be resized, extra functionality (e.g. statusbar/notifications/...)

That's why new frameworks come out, because "why can't notifications on Windows work the same as on android?". "Why not just share UI?". Unfortunately, there's very good reasons they cannot work the same ... So a couple years in, these frameworks develop the exact same problems.