A lot of “Flutter developers” can build a screen from a Figma file. Fewer can tell you why your list view is dropping frames, or debug a platform channel that’s silently failing on Android 14 but not iOS. That second kind of work — the kind that shows up after launch, not during the demo — is what I do.

The Part Most Flutter Hires Get Wrong

Flutter’s pitch is one codebase, two platforms. True, mostly. But the moment your app needs a native camera permission flow, a biometric auth prompt that behaves differently on Android’s BiometricPrompt versus iOS’s LocalAuthentication, or a background service that Android kills more aggressively than iOS — you’re no longer writing pure Dart. You’re writing a MethodChannel bridge, and if whoever built it doesn’t actually understand what’s happening on the native side, that bridge breaks in production, quietly, usually on whichever OS version you didn’t test.

This is the actual skill gap between someone who “knows Flutter” and someone who’s shipped it. Clean Dart widgets are the easy 80%. The other 20% — native channel bridging, Firebase security rule audits, App Store review rejections over privacy manifest issues — is where projects stall.

State Management: An Honest Take

Bloc and Riverpod both work. The difference matters more than most write-ups admit. Bloc forces a stricter event-driven structure — every state change is traceable, which is genuinely valuable on a larger team where you need predictable, testable data flow. Riverpod is lighter, faster to write, and better suited to a smaller app or a solo-maintained codebase where you’re optimizing for iteration speed over enforced structure.

I pick based on the actual team size and maintenance plan, not personal preference. A five-screen MVP that one person will maintain doesn’t need Bloc’s ceremony. A booking platform with six months of planned feature work does.

Firebase Isn’t “Set It and Forget It”

This is the part that gets skipped constantly, and it’s a genuine liability when it does. Firebase’s default security rules, left unaudited, can expose an entire Firestore collection to anyone with your API config — which, on a Flutter client app, is trivially extractable from the compiled binary. Before any app I build goes live, security rules get written explicitly per collection, tested against unauthorized read/write attempts, and reviewed again before submission. This isn’t optional hardening. It’s the difference between a backend and an open door.

What Breaks Apps in App Store Review (and How to Avoid It)

Apple’s review process has gotten stricter on privacy manifests, tracking disclosures, and background execution justification. A rejected build isn’t just annoying — it’s a week lost if the fix requires re-architecting how a feature works, not just changing copy. Handling this properly means front-loading privacy manifest declarations and permission justifications during development, not scrambling after a rejection email.

Real Project Reference

Client apps I’ve built handle exactly this stack — Firebase authentication and Firestore as the backend, Riverpod for state management on smaller builds, custom platform channels where native functionality was required, and a release pipeline through both TestFlight and Google Play’s internal testing track before public submission. Message me directly and I can walk through specific examples relevant to your project type.

Frame Budget: Why Your App Feels Janky

Flutter renders at 60fps by default, which means each frame has roughly 16 milliseconds to build, layout, paint, and composite before the next one is due. A janky scroll almost always traces back to expensive work happening inside the widget build method — a database query, an image decode, a heavy computation — that should be moved off the main isolate or memoized properly. This is a diagnosable, fixable problem, not something you accept as “how Flutter feels.”

Frequently Asked Questions

Do you build the backend too, or just the Flutter frontend?
Both, typically through Firebase — Firestore, Authentication, Cloud Functions — though I can also integrate with an existing REST API or a backend your team already maintains.

Bloc or Riverpod — which will you use for my project?
Depends on team size and maintenance plan, not a fixed preference. I’ll tell you honestly which fits your specific project during scoping, including the tradeoff either way.

Can you fix an existing Flutter app instead of building from scratch?
Yes — this is common. A proper audit first (checking state management structure, security rules, and platform channel implementation) determines whether it’s a targeted fix or worth a partial rebuild.

What happens if my app gets rejected during App Store review?
Rejections are usually fixable without a full rebuild — privacy manifest and permission-justification issues are the most common cause in 2026, and I handle resubmission as part of the engagement, not as extra billable scope.

How do you handle native features like biometric auth or camera access?
Through platform channels, built and tested against both Android and iOS separately — these behave differently at the OS level, and treating them as identical is exactly where most apps break in production.

Message me on WhatsApp with your project scope, or run it through the Cost Calculator first for a real price range.