What is Flutter?
Flutter is a user interface toolkit for building native applications for mobile, web and desktop platforms from a single codebase. It is developed and made available for free by Google.
When should one use Flutter?
I recently asked John Mullaney, one of our software engineers, this question. Here is his answer.
Ah! It depends on the engine and depends on the project.
The main problem with Flutter is it that it does all its own rendering and user interaction. That is, all the controls are completely custom.
The small problem with that is it means your app will not have a native look & feel. Native look is not a big problem these days -- custom look is in. But people do expect/need the UI to integrate with the OS properly. For example, the mobile keyboard comes up at the right time and interacts with the edit control appropriately; it does copy & paste, and sharing, and drag-and-drop, accessibility, etc. It's a lot of work to nail all this down, and inevitably there are gaps in any framework. When you think about it, to fully keep up with their target frameworks, the Flutter team would have to do the same work as Apple's UI Kit team, Android's UI team, Windows UI team put together and manage it all within one engine where conflicts will occur. That's not feasible, so in reality there just end up being various gaps and least-common-denominator implementations. There's usually a way for an individual app to implement anything important to them that isn't covered, but that defeats part of the purpose of using the framework in the first place.
The longer term problem is that the ongoing work it takes to keep an engine up-to-date with OS changes is usually staggering and crushes the engine. Open source relies on volunteers, and not a lot of people will willingly spend all their time figuring out why behavior ABC doesn't work on version 123 of OS release XYZ. A for-profit company could pay someone to do it, but that costs a lot of money. And the work will not exactly be appreciated because this kind of work will often break existing apps based on the engine. So even once you are done, your app developers have a lot of work to do to get the benefits.
This is the best-case scenario. These engines make abstraction trade-offs (or outright mistakes) in their design all the time, which make some things easier to do, but make other seemingly simple things surprisingly difficult.
[The big mistake/trade-off for Flutter is that it uses the Dart programming language -- I think that's a very questionable choice for a cross-platform engine, though I believe it does allow for Flutter's nicest development feature, which is that code changes are virtually instantaneously hot-loaded into the running app (even though the code is compiled). Dart is specifically designed for the granular recompilation and linking that enables this.]
On the other hand, the value of these engines are that they let you move very quickly to start and give you a cross-platform result.
So, to get to your question... the best use-case is fairly straightforward apps that won't be around long or won't need to change. Like an app for an event or a pizza place. Well, actually for those cases, you'd usually be better off with a template app. But maybe the template app could be Flutter-based. Something like a dashboard app could work, too, because it's mostly "passive" -- you're just looking at data, not really entering or modifying this. Any kind of productivity app would be very questionable because you need to integrate these with your own workflow, so any and all integration points are potentially important to someone.
Games or other kinds of apps that don't need to integrate with the OS very much are good. Games are great because users expect and want a custom, non-standard UX. You can do anything (as long as it's fun and engaging).