Choosing state management for a banking app

Every Flutter thread about state management turns into a preference war. In a banking app the question is narrower and more answerable: when a transfer half-fails, which approach makes that state impossible to render incorrectly?

What the domain demands

A money transfer has more states than a typical CRUD screen: idle, validating, submitted, pending at the core banking system, settled, reversed, and failed with a dozen distinguishable reasons. If your state type can represent "loading and error and data" simultaneously, you will eventually ship a screen that shows a spinner over a success message.

That pushes toward sealed state classes, which BLoC models naturally. It does not require BLoC — you can express the same discipline with GetX controllers exposing a single sealed state object rather than a fistful of independent observables.

What the team demands

The second constraint is people. On teams where several developers rotate through a client codebase, the winning pattern is the one that is hardest to use wrongly, not the one with the least boilerplate. GetX is fast to write and easy to scatter; the moment controllers start reaching into each other, a screen becomes untestable.

The rule I settle on: one controller or bloc per screen, one sealed state per controller, and no cross-controller reads. Whichever library you pick, that rule does most of the work.

A practical middle

For most of the fintech apps I have shipped, GetX handles navigation and dependency injection while each feature exposes an immutable state object. It keeps the ergonomics that make GetX pleasant, without the global mutable soup that makes it dangerous.