Forem: Ishaq Hassan

Building Production Flutter Plugins: A 156-Likes pub.dev Case Study

Ishaq Hassan — Sat, 25 Apr 2026 12:58:48 +0000

TL;DR

The native code is rarely the hard part of a Flutter plugin. The hard parts are: lifecycle correctness across both iOS and Android, permission flows, async cancellation, supporting users who file half-formed issues, and shipping breaking changes without breaking the world. A successful plugin costs 4 to 8 engineer-weeks before launch and a few hours per month forever after.

The plugin in numbers

Metric	Value
pub.dev likes	156
pub points	130
Monthly downloads	470
In production	5+ years

The plugin in one paragraph

document_scanner_flutter is a cross-platform Flutter plugin that lets an app capture a photo of a document, auto-detect the paper edges, perform perspective correction, and return the cropped, rectified image. It uses Apple Vision on iOS and Google ML Kit on Android. Apps using it include KYC flows, expense reporting tools, and field-data collection apps.

The architecture, layer by layer

A Flutter plugin lives at the edge between the Dart VM and the native platform. There are four layers, and getting any one of them wrong shows up as a 1-star review.

1. The Dart-facing API. This is what your users see. It must read like a normal Dart package: simple async functions, well-documented parameters, sensible defaults, type-safe results.

2. The platform channel. Dart talks to native code through a MethodChannel. Calls are async, named, and arguments are JSON-encodable. Lesson learned the hard way: name your channel under your domain. Generic names collide with other plugins.

3. The native bridge. On iOS, a Swift FlutterPlugin class. On Android, a Kotlin FlutterPlugin. Both must validate arguments, hold no implicit state, handle cancellation, and tear down listeners on detach.

4. The native UI / system call. Where 80% of user-reported bugs hide. iPad split-view, Android camera permissions, foldable rotations: all edge cases.

Lifecycle: the silent killer

Flutter plugin lifecycle is the most frequently misunderstood topic. The plugin is attached to a Flutter engine, but the engine can be detached and re-attached when the user backgrounds and foregrounds the app. If your plugin holds an Activity reference (Android) or a UIViewController reference (iOS) past detach, you crash the next time the engine reattaches.

On Android, implement ActivityAware and store the Activity reference only between onAttachedToActivity and onDetachedFromActivity. On iOS, never hold the Flutter engine UIViewController; resolve it lazily.

Federated plugins: when to bother

The federated plugin pattern splits the package into API + platform interface + per-platform implementations. Should you federate from day one? No. Start as a single package with iOS + Android folders. Federate only when you have either a credible second platform (web, desktop) or a co-maintainer for one of the platforms.

Pub.dev scoring is deterministic

Pub points reward sound null safety, valid pubspec, OS support declarations, comprehensive README with example, documentation on public API, up-to-date dependencies, and clean static analysis. Likes and downloads are social signals on top.

Verified publisher: a trust multiplier

The shield icon next to my publisher name on pub.dev means the package is published under a verified domain (ishaqhassan.com). DNS TXT verification, takes 10 minutes, meaningfully shifts trust.

What I would build differently in 2026

Use Pigeon from day one for type-safe platform channels.
Federate from second platform, not from launch.
Native UI in dev mode only: ship native-only flow first, Flutter-styled UI only when truly needed.
Snapshot tests for the native bridge to catch contract drift early.

The full version with the support burden chapter, the iOS/Android lifecycle deep dive, and the full pub.dev scoring breakdown is on my site:

Read the complete article on ishaqhassan.dev

I am a verified pub.dev publisher (ishaqhassan.com) and Flutter Framework Contributor with 6 merged PRs into flutter/flutter. More writing at ishaqhassan.dev/blog/.

Flutter State Management in 2026: A Decision Guide for Production Apps

Ishaq Hassan — Sat, 25 Apr 2026 12:58:04 +0000

TL;DR

For widgets that own their state, setState is correct. For app-wide state in 2026, Riverpod has the best ergonomics. For event-sourced enterprise apps, Bloc still wins. Provider is fine if you already have it. Signals (via signals_flutter, solidart) are the rising option for fine-grained reactivity. Pick by team scale and app boundaries, not by Twitter discourse.

The honest hierarchy

Every state management decision sits on three axes: scope (one widget, one screen, the whole app), team scale (solo, 5 engineers, 50 engineers), and auditability (do you need a log of every state transition for compliance or replayability). Most state management debates ignore those axes and argue Twitter aesthetics.

Tier 1: setState

If your state lives inside one widget and is never read by widgets outside, setState is the right call. It is framework-native, zero dependencies, zero indirection. The reason engineers reach past it too early is that they confuse "state inside the widget" with "state inside the file." Start with setState; lift the moment a sibling widget needs to read a value.

Tier 2: InheritedWidget

Every state management library is, under the hood, an InheritedWidget with extra ergonomics. Provider wraps it. Riverpod wraps a smarter version. Theme.of, MediaQuery.of, Navigator.of: all InheritedWidgets.

Tier 3: Provider (the safe default)

Provider was the official recommendation from 2018 to roughly 2022 and is still in heavy production use. It wraps InheritedWidget into a familiar API: ChangeNotifierProvider, context.watch, context.read, Selector for fine-grained rebuilds. If you have a Provider codebase, keep it. Migration mid-project rarely pays back.

Tier 4: Riverpod (the 2026 default for new apps)

Riverpod is what Provider's author wrote when he had a chance to start over. The headline differences:

Compile-time safety: a provider that does not exist will not compile. No ProviderNotFoundException at runtime.
Code generation: @riverpod annotation produces type-safe providers, eliminating boilerplate.
AsyncNotifier: first-class support for async state with AsyncValue (data, loading, error variants).
Family providers: parameterized providers (per user ID, per item ID) without manual disposal.
Auto-dispose: providers can release resources automatically when no widget reads them.

Tier 5: Bloc (the enterprise pattern)

Bloc separates events (intents) from state (results). UI dispatches events, the Bloc maps events to states, the UI rebuilds on state changes. Where Bloc shines: large teams (10+ engineers per app), strict architectural review, compliance contexts where every state transition must be logged and replayable.

Tier 6: signals (the rising star)

Signals (in Flutter via packages like signals_flutter and solidart) implement the SolidJS / Vue / Svelte approach: a value wrapped in an object that automatically tracks its readers and only rebuilds those readers. No watch, no ref, no Provider scope.

Decision matrix

Context	Recommendation in 2026
State inside one widget	`setState`
Solo dev, new app, < 10 screens	Riverpod (or signals)
5-engineer team, new app	Riverpod
Existing Provider codebase	Stay on Provider
20+ engineer team, enterprise	Bloc
Compliance / audit log needed	Bloc (or Redux for time travel)
Real-time collab, complex async	Bloc or custom RxDart streams

The trap to avoid

Do not pick state management based on a Twitter thread. Pick by walking through three questions:

Where does this specific piece of state live, and who reads it?
How many engineers will touch this code in the next year?
Does anyone outside the engineering team need to audit how this state changed?

The full version with what changed in 2026 vs 2024 and concrete code patterns for each tier is on my site:

Read the complete article on ishaqhassan.dev

I am a Flutter Framework Contributor with 6 merged PRs into flutter/flutter and Engineering Manager at DigitalHire. More writing at ishaqhassan.dev/blog/.

Flutter Three-Tree Architecture Explained: Widgets, Elements, RenderObjects

Ishaq Hassan — Sat, 25 Apr 2026 12:57:12 +0000

TL;DR

Flutter renders by maintaining three parallel trees. The Widget tree is immutable configuration, rebuilt on every setState. The Element tree is the persistent identity layer that decides whether to update or replace. The RenderObject tree is the heavyweight layout, paint, and hit-test machine. Bugs that look like "random state loss" or "ListView jank" almost always live in the Element layer.

Why three trees instead of one

If Flutter rebuilt the entire rendered UI on every state change, no app would hold 60fps. Native frameworks solve this with mutable view objects you imperatively update. React solves it with a virtual DOM diff against a real DOM. Flutter splits the problem into three layers, each with one job.

Widgets are immutable build instructions. They are cheap to allocate, cheap to throw away, and trivially comparable. When you call setState, Flutter does not rebuild any pixels. It rebuilds the widget subtree below the StatefulWidget into fresh widget instances. Widgets are fast because they are dumb.

Elements are the persistent identity layer. Every widget gets exactly one Element when first mounted. The Element holds the parent pointer, the state object (for StatefulWidgets), the InheritedWidget dependencies, and a reference to the RenderObject if it has one. Elements survive across setState calls.

RenderObjects are the real work. Layout, paint, hit-testing, semantics, accessibility tree generation. RenderObjects are expensive to create and expensive to throw away, so the Element layer works hard to keep them around across rebuilds.

The reconciliation algorithm

When the framework asks an Element to update with a new widget, the algorithm is:

if (Widget.canUpdate(oldWidget, newWidget)) {
  element.update(newWidget);     // reuse this Element + RenderObject
} else {
  element.deactivate();           // unmount old subtree
  parent.inflateWidget(newWidget); // create fresh Element + RenderObject
}

The canUpdate check returns true when the runtimeType and the key are equal. Same type, same key (or both null) means the Element is reused. Anything else means a full mount/unmount cycle.

Keys and why they matter more than you think

Keys are the manual override on the reconciliation algorithm. By default, Flutter pairs new widgets to existing Elements positionally. The first child of the new widget tree pairs with the first child Element. If you reorder a list of Card widgets without keys, every Card looks at its new widget, sees a Card with the same runtimeType and a null key, and updates in place. The visible content moves, but the state stays at its original position.

This is the source of the most reported "Flutter is broken" bug: a list of TextField widgets where the user types in the second row, then the row gets reordered, and the typed text appears in the wrong row. The fix is to give each Card a stable key (like ValueKey(item.id)) so the framework pairs by identity instead of position.

What to do with this knowledge

You do not need to memorize the framework source. But you do need a working mental model of which tree is responsible for which behavior:

If your UI looks wrong after a rebuild, suspect the Widget tree.
If your state vanishes or moves, suspect the Element tree.
If your frame rate drops, suspect the RenderObject tree.
If InheritedWidget consumers do not update, suspect the Element dependency graph.

The full version with the six-state Element lifecycle, RenderObject layer details, and a real bug case study from a merged Flutter framework PR is on my site:

Read the complete article on ishaqhassan.dev

I am a Flutter Framework Contributor with 6 merged PRs into flutter/flutter. More writing at ishaqhassan.dev/blog/.

How a Pakistani Engineer Got 6 Pull Requests Merged Into Flutter's Official Framework

Ishaq Hassan — Thu, 23 Apr 2026 21:54:53 +0000

My journey as a Flutter Framework Contributor from Karachi, Pakistan, and why it's a big deal for the Pakistani Flutter community.

TL;DR: I'm Ishaq Hassan, Engineering Manager at DigitalHire, Flutter course instructor on the official Flutter docs, and a Pakistani Flutter developer with 6 Pull Requests merged into the Flutter framework (the official repository maintained by Google). This post walks through why framework-level contributions matter, how I landed mine, and a short guide for other Pakistani (and South Asian) developers who want to do the same.

Live portfolio: https://ishaqhassan.dev

The Gap Nobody Talks About

Pakistan has thousands of Flutter developers now. You'll find Flutter jobs in Karachi, Lahore, Islamabad. You'll find Flutter-based startups, Flutter courses on YouTube, Flutter meetups, Flutter Facebook groups.

But there's a difference between using a framework and contributing to it.

If you open the Flutter repository on GitHub and search the contributor graph for Pakistani engineers with multiple merged PRs, the list is short. Surprisingly short. Most Pakistani engagement with Flutter stops at the app layer, building apps, building plugins, teaching courses. Direct contributions to the framework itself remain rare.

This article exists partly to normalize it. If you're from Pakistan and you want to contribute to the Flutter framework, you can. Here's how I did it.

My 6 Merged Pull Requests

As of April 2026, these are the ones that made it in:

And 3 currently open in review:

Practical Guide

1. Pick the right kind of first PR

Don't try to rewrite the rendering pipeline on day one. The Flutter team, like any major OSS project, accepts small, well-scoped, well-tested PRs from new contributors first. Documentation fixes are underrated. Adding a single missing parameter to a widget is high-impact and low-risk.

My first merged PR (#183081) literally replaces single quotes with double quotes in a Gradle template. That's the bar. Small. Correct. Tested. Useful.

2. Read CONTRIBUTING.md like your life depends on it

The Flutter team has strict style guides, commit conventions, and test coverage requirements. If you don't follow them, your PR will sit forever or get closed.

3. Find real issues via search, not browsing

Search Flutter issues for labels: good first issue, help wanted, d: api docs
Grep the codebase for TODO comments near widgets you understand
Use Flutter yourself, find a paper cut, reproduce it in a test, fix it

4. Tests are non-negotiable

Every PR needs a test. If you're adding a parameter, add a unit test. If you're fixing a bug, add a regression test. No test = no merge.

5. Be patient and responsive

The Flutter team gets thousands of PRs. Reviews are thorough. My average time from PR open to merge is 2-4 weeks. Always respond to reviewer feedback within 24 hours, that moves you up the priority queue.

Why This Matters for Pakistan

Open source framework contributions are a career accelerator in a way most people underestimate:

Global credibility. When I say "Flutter Framework Contributor" on LinkedIn, I don't have to explain what that means. It's objectively verifiable on GitHub.
Better jobs. Senior Flutter roles at international companies care a lot about whether you can work at the framework level, not just app level.
Community leadership. It earns speaking invitations, course opportunities, mentorship requests.
Pakistani representation. Every time a Pakistani name appears on a merged Flutter PR, it chips away at the assumption that serious OSS contributions only come from North America or Europe.

About the Flutter Course in Urdu

Separately from the framework work, I teach a 35-video Flutter course in Urdu that is officially listed on docs.flutter.dev. It's free. It covers Dart basics through advanced Flutter (state management, APIs, custom painters, deployment). On YouTube via Tech Idara.

If you're Urdu-speaking and want to learn Flutter properly, here's the playlist.

Call to Action

If you're a Pakistani developer reading this:

Send your first Flutter framework PR this month. Start with docs. Don't overthink it.
Ping me on LinkedIn if you need a review before submitting. Happy to help.
Share your merged PRs publicly. Representation compounds.

Forem: Ishaq Hassan

Building Production Flutter Plugins: A 156-Likes pub.dev Case Study

TL;DR

The plugin in numbers

The plugin in one paragraph

The architecture, layer by layer

Lifecycle: the silent killer

Federated plugins: when to bother

Pub.dev scoring is deterministic

Verified publisher: a trust multiplier

What I would build differently in 2026

Flutter State Management in 2026: A Decision Guide for Production Apps

TL;DR

The honest hierarchy

Tier 1: setState

Tier 2: InheritedWidget

Tier 3: Provider (the safe default)

Tier 4: Riverpod (the 2026 default for new apps)

Tier 5: Bloc (the enterprise pattern)

Tier 6: signals (the rising star)

Decision matrix

The trap to avoid

Flutter Three-Tree Architecture Explained: Widgets, Elements, RenderObjects

TL;DR

Why three trees instead of one

The reconciliation algorithm

Keys and why they matter more than you think

What to do with this knowledge

How a Pakistani Engineer Got 6 Pull Requests Merged Into Flutter's Official Framework

The Gap Nobody Talks About

My 6 Merged Pull Requests

Practical Guide

1. Pick the right kind of first PR

2. Read CONTRIBUTING.md like your life depends on it

3. Find real issues via search, not browsing

4. Tests are non-negotiable

5. Be patient and responsive

Why This Matters for Pakistan

About the Flutter Course in Urdu

Call to Action

Links