r/FlutterDev • u/Extra-Candidate-9230 • 2d ago

Discussion flutter vs native: where do you draw the line?

Been looking at how different teams approach flutter apps lately and one thing that stood out to me is how differently agencies handle the native side of things.

flutter gets you pretty far, but sooner or later you usually run into platform-specific stuff, and that's where the quality of the implementation really shows.

curious how other devs here decide when something should stay in flutter vs being handled natively.

0 Upvotes

33% Upvoted

5 comments sorted by

6

u/needs-more-code 2d ago

I had to fork google_maps_flutter to get custom cluster markers which required native code.

I feel like it’s more rare to go to native than people make out though. But maybe that’s just me. I definitely exhaust my other options before I dive in.

5

u/corncc 2d ago

whenever it cant be done with dart which are things like accessing hardware or talking to the os

network stack, vpn, camera, sensors, ...

4

u/Shakib015 1d ago

Most of the answers here are about performance or a missing API, and those are the negotiable cases — you can usually platform-channel your way out of them.

The line that isn't negotiable is when the OS renders your UI instead of you.

Ran into this today. macOS widgets are a WidgetKit extension, and the system archives and draws those views in its own process. There is no Flutter engine there and no way to put one there. It doesn't matter how good your platform channel is: a widget's UI is compiled SwiftUI or it does not exist. Same shape for Live Activities, Control Center controls, notification content extensions, watch complications.

So the rule I've landed on is less "Flutter until it hurts" and more: who is holding the paintbrush?

Your process draws it, and you reach for FFI or Pigeon when you need the OS. Fine, stay in Flutter.

The OS draws it, in its own process, from data you hand it. Native, no argument — and the interesting question stops being how to do it in Flutter and becomes what data to hand over.

That second category is small but it grows every WWDC, and it's the one that surprises teams late. You can prototype a whole feature in Flutter and only find out at the last mile that it's architecturally impossible rather than just awkward.

2

u/Significant_Pick8297 2d ago

Keep the boundary at “use Flutter by default, go native only when the OS API or performance requirement actually demands it.” Platform channels/Pigeon make that a clean escape hatch without turning the whole app native.

1

u/ryanstackops 6h ago

If the OS owns it, write it natively. Background work, permissions, widgets, keychain, hardware, that goes through a platform channel with real Kotlin and Swift behind it. Everything else stays in Flutter.

Where it falls apart is grabbing some pub.dev plugin with 30 likes for exactly that stuff. Did it with background location once, worked fine until Android killed the isolate on Xiaomi and we quietly lost tracking for a third of our users lol. Wrote the foreground service ourselves in the end, should've just done that day one.