Why I use Flutter for almost everything

Except for this website (Astro) and Nyao Scalper (MQL5), almost everything I've published is Flutter. Flutter POS, Money Chat AI, Zirel POS, Counsel Link (a counseling app with chat and video calls), and the small tools on this site like the K-Means and SERVQUAL calculators. This post is about why, and also about the parts I don't like.

The same code on every device

The main reason is simple. Most of what I build needs to run on more than one kind of device.

Flutter POS runs on Android, iOS, Windows, macOS and Linux from one codebase. Zirel POS is made for Android phones, tablets and desktops, and the same screens have to work on a 6 inch phone and on a tablet next to a cash register. Money Chat AI is a Flutter web app. Writing each of those separately for each platform is not realistic when you work mostly alone.

Flutter draws its own widgets instead of using the native ones from each platform. In practice that means a screen looks the same on Android, Windows and the web. When there's a layout bug, it's usually the same bug everywhere, and you fix it once. That's not 100% true, there are always some platform differences around things like fonts, keyboards and window sizes, but it's close.

Dart

Dart is the other half of why I stay. Three things I like most:

Null safety. In business apps a lot of bugs are something being null when it shouldn't be, like a product price or a stock number that wasn't loaded yet. With sound null safety the compiler forces you to handle that before the app runs.

async and await. A POS waits a lot. For the database, for the network, for a Bluetooth printer. With async/await that code reads from top to bottom. For example, this is how Flutter POS replays its offline queue:

for (final queue in queues) {
  if (!pingService.isConnected) continue;

  final res = await executeQueuedAction(queue);
  result.add(res.isSuccess);
}

You can read that without knowing anything about futures. Dart also runs your code on one thread unless you use an isolate, so you don't get the usual race conditions between threads. When something heavy needs to run without freezing the UI, you move it to an isolate.

Hot reload. Everyone mentions it, but it really changes how much small UI polishing you do. Changing a padding and seeing it in a second on a screen full of real data is very different from rebuilding the app every time.

What I don't like

Hardware. A POS has to talk to thermal printers, barcode scanners, cash drawers and customer displays, and every platform does that differently. The plugins on pub.dev are often for one connection type only, or haven't been updated in a while. I ended up writing my own printer package because of this.

Web bundle size. Flutter web apps are heavy for what they are. The K-Means calculator on this site is a small tool, but its main.dart.js is about 2.4 MB, and SERVQUAL is about 2.1 MB, before compression. For a POS that people install once and use all day, size doesn't matter much. For a page someone opens once from a link, the first load is noticeably slower than a normal website.

Apps that are mostly the OS. If an app is mostly camera work or deep system integration, most of the code ends up talking to the platform through plugins and channels anyway. For those I'd probably go native.

Packages

When I need the same thing in two projects, I try to make it a package. These are on pub.dev:

• app_image and app_table, first published in July 2024, the same month I started Flutter POS. app_image is at version 1.0.18 now, it's the one I update the most.
• flutter_presentation_display, since September 2024. It handles a second display, like a customer facing screen on POS devices that have one built in.
• unified_esc_pos_printer, since March 2026. One API for USB, Bluetooth classic, BLE and network thermal printers. It started when I finally added printing to Flutter POS, and it's my most downloaded package now, around 2,400 downloads a month.
• mqtt_broker_lite, since May 2026. A small MQTT broker in pure Dart, for when devices on the same local network need to talk to each other without a server in the cloud.

So should you use it?

If your app is mostly screens, forms and business logic, and it needs to run on more than one platform, I think Flutter is a very good choice. If your app is mostly about the operating system, or it's a light web page, probably not.

For me the biggest benefit is that everything shares the same language and the same structure. What I learn or fix in Flutter POS ends up in Zirel POS, and the printer code became a package any Flutter app can use.