DEV Community: Ishaq Hassan

Run flutter upgrade: Nine of My Commits Ship Inside Flutter 3.47

Ishaq Hassan — Thu, 13 Aug 2026 17:32:25 +0000

Note: this article was originally published on my site: ishaqhassan.dev/blog/flutter-3-47-my-commits.html

Flutter 3.47.0 went out on the stable channel on August 12, 2026, carrying Dart 3.13.0. If you ran flutter upgrade this week, you are now running some of my code.

That is not a figure of speech. Nine commits with my name on them are inside the 3.47.0 tag: seven in the framework and tooling, two more in the DevTools bundle that ships with it. Four of them are listed by number in the official release notes.

This article is the full accounting: what each commit actually does, which of them reached stable for the first time in this release, and, more usefully for you, exactly how to check whose code your own SDK is running instead of taking anybody's word for it.

Flutter 3.47 at a glance

Version: Flutter 3.47.0, stable channel. As of today it is the latest stable Flutter release.
Release date: August 12, 2026.
Dart SDK: 3.13.0. DevTools: 2.60.0.
Previous stable: the 3.44 line, which ended at the 3.44.9 hotfix on August 6, 2026. Flutter skipped 3.45 and 3.46 on stable entirely.
Size of the jump: 1,358 commits ahead of 3.44.0.
Headline changes: standalone material_ui and cupertino_ui packages, Impeller as the default renderer on desktop, Widget Previews stable, iOS 15 and macOS 12 minimums.

What actually shipped on August 12

The headline features of 3.47 are the ones everyone wrote about: the Material and Cupertino libraries becoming standalone material_ui and cupertino_ui packages on pub.dev, Impeller becoming the default renderer on macOS, Windows and Linux, Widget Previews graduating to stable, and the Apple platform bump that raises the minimum to iOS 15 and macOS 12 ahead of Xcode 27.

Underneath those headlines, 3.47.0 is 1,358 commits ahead of 3.44.0, the previous stable. Flutter skipped 3.45 and 3.46 on the stable channel entirely, so this release swallowed nearly three months of merged work. Most of that work is invisible: a parameter here, a corrected doc comment there, a template fix that only matters when you create a new project.

A release is a headline plus a thousand small corrections. The headline gets the blog post. The corrections are what you actually hit on a Tuesday afternoon.

The nine commits, one by one

Two API additions you can use today

Add clipBehavior to AnimatedCrossFade (66 lines, 2 files). AnimatedCrossFade wrapped its children in a hardcoded ClipRect that you could not reach. Anything that painted outside the child bounds got sliced: box shadows, glows, and the stroke of a CircularProgressIndicator mid-crossfade. An earlier attempt to fix this by deleting the ClipRect outright was closed, because removing clipping silently changes existing layouts. So this one takes the boring path and exposes the knob instead, defaulting to Clip.hardEdge:

AnimatedCrossFade(
  duration: const Duration(milliseconds: 300),
  crossFadeState: state,
  clipBehavior: Clip.none, // shadows and indicator strokes survive now
  firstChild: const CardWithShadow(),
  secondChild: const CircularProgressIndicator(),
)

Add scrollPadding to DropdownMenu (37 lines, 2 files). DropdownMenu wraps a TextField internally, and TextField has always accepted scrollPadding, the padding kept around the field when the keyboard pushes it into view. DropdownMenu simply never forwarded it, so a dropdown at the bottom of a form would scroll to sit flush against the keyboard. SearchBar already exposed the property, which made the argument easy: this is a consistency gap, not a new idea.

DropdownMenu<String>(
  scrollPadding: const EdgeInsets.only(bottom: 120),
  dropdownMenuEntries: entries,
)

One template fix every new Android build inherits

Use double quotes in the settings.gradle.kts template (one line changed). When the plugin template was renamed from settings.gradle to settings.gradle.kts, the string stayed in Groovy style with single quotes. Kotlin only accepts single quotes for character literals, so the generated file was invalid Kotlin:

// before, invalid Kotlin
rootProject.name = '{{projectName}}'

// after
rootProject.name = "{{projectName}}"

One character on each side of a string, in a file nobody reads, that every generated Android plugin project starts from. That is the shape of the highest-leverage fixes: tiny diff, enormous blast radius.

Four documentation fixes that save real debugging hours

Docs commits are the ones people dismiss. They are also the ones that quietly delete entire afternoons from other engineers' lives.

Disposal guidance on CurvedAnimation and CurveTween. CurvedAnimation registers a status listener on its parent controller in its constructor, and only removes it in dispose(). Create one inside build() and you leak a listener on every single rebuild. The class docs now say so out loud, along with the rule not to build one inside build().
RouteAware.didPushNext timing. The docs claimed the callback fires when the current route is no longer visible. Tracing the source shows it fires synchronously during the push, before the transition animation finishes, while your route is still partly on screen. If you were pausing a video or stopping a camera in that callback, the old wording was actively misleading.
LicenseRegistry points at NOTICES, not LICENSE. The docs told you the bundled license asset was called LICENSE. The tool actually produces NOTICES (or NOTICES.Z compressed), and the binding has been loading that all along. Anyone writing a custom license screen was hunting for a file that does not exist.
moveStep direction on dragUntilVisible. In widget tests, dragUntilVisible takes a moveStep offset whose sign convention is the opposite of scrollUntilVisible: to reveal content below the fold you drag with a negative dy, because the finger swipes up. People kept getting it backwards and filing issues about it. The dartdoc now spells out all four directions.

Two DevTools fixes in the 2.60.0 bundle

Flutter 3.47 pins DevTools 2.60.0, up from 2.57.0 in the 3.44 line. Two fixes of mine ride in that jump:

SplitPane range error when the child count changes. SplitPane cached its fraction list once in initState. Toggle a panel in or out with a collection-if and the cached list kept the old length while the children shrank, so the next layout threw RangeError (index): Index out of range. The fix adds didUpdateWidget to rebuild the fractions when the child count changes.
Network search field stays usable after clearing calls. The Network tab tied the search field's enabled state to whether any requests were currently recorded. Hit clear, and the field went dead, so you could not prepare a filter before the next request arrived. Now it stays enabled, matching every other search field in DevTools.

Six of the nine reached stable for the first time

Here is the nuance most "my code shipped" posts skip, including my own first draft of this one.

All nine commits are inside the 3.47.0 tag. But three of them, the Gradle template fix, the RouteAware doc correction and scrollPadding on DropdownMenu, all merged in March and already went out with 3.44.0 on May 18. They have been in production Flutter apps for three months. They are in 3.47 the same way every other commit in Flutter's history is: they were never removed.

The six that reached the stable channel for the first time in 3.47 are the four framework and test-API items from April, May and June, plus both DevTools fixes.

That gap is worth internalising if you contribute to Flutter. A merged pull request is not a shipped pull request. It lands on main, waits for a beta cut, then waits for a stable cut. My clipBehavior work merged on April 23 and reached stable users on August 12: 111 days between the purple badge and the first developer who could actually type clipBehavior: and have it compile. Flutter skipping 3.45 and 3.46 on stable stretched that queue further.

How to check whose code you are running

You should not believe any of the above because I wrote it. Every claim here is checkable in about a minute, and the same technique works for any contributor and any release.

1. Know your version.

flutter --version
# Flutter 3.47.0 · channel stable · Dart 3.13.0

2. Filter the release tag by author on GitHub. Commit listings accept an author filter as a query parameter, so this URL is the whole trick:

https://github.com/flutter/flutter/commits/3.47.0?author=ishaquehassan

Swap the tag for the version you are on and the username for whoever you are curious about. Your own name works too, and it is a good day when it does.

3. Ask your local SDK directly. Your Flutter install is a git clone, so it can answer this offline:

cd "$(dirname "$(readlink -f "$(which flutter)")")/.."
git fetch --tags
git log --oneline --author=ishaq 3.47.0 | cat

4. Settle a single pull request with a yes or no. Take the merge commit SHA from the pull request page and ask git whether it is an ancestor of the tag. Exit code zero means it is in that release:

git merge-base --is-ancestor 8303a3547509f32662be3a9cf1adc83bf41976fa 3.47.0 \
  && echo "in 3.47.0" || echo "not in 3.47.0"

The same question over the API, no clone required. A behind_by of zero means the tag already contains that commit:

gh api "repos/flutter/flutter/compare/<merge-sha>...3.47.0" \
  --jq '.status, .behind_by'

5. For DevTools, resolve the pin. DevTools is not in the Flutter repo, it is pinned by revision. Read the pin at the tag, then check your commit against that revision:

gh api "repos/flutter/flutter/contents/DEPS?ref=3.47.0" --jq .content \
  | base64 -d | grep dart_devtools_rev

That is how I confirmed the 3.47 pin is byte-identical to the v2.60.0 tag, and that 3.44 shipped 2.57.0. Five commands, zero trust required.

How to upgrade to Flutter 3.47, and what can break

If you are still on the 3.44 line, the upgrade itself is three commands:

flutter channel stable
flutter upgrade
flutter --version   # expect: Flutter 3.47.0 · Dart 3.13.0

Then flutter clean and flutter pub get in each project so old build artifacts and pinned constraints get regenerated. If something goes sideways, flutter downgrade steps you back to the SDK you had before.

Four things in this release are worth checking before you ship on it:

Apple minimums moved. iOS 13 to iOS 15, macOS 10.15 to macOS 12. If your app still declares an older deployment target, that is the first build failure you will meet.
UIScene lifecycle is mandatory for UIKit apps built with Xcode 27. If you have custom AppDelegate lifecycle code, it needs the scene-based path.
Impeller is the default renderer on desktop now, on macOS, Windows and Linux. Anything that assumed Skia behaviour, particularly custom shaders, deserves a visual pass.
Material and Cupertino are moving out of the SDK into the material_ui and cupertino_ui packages. Nothing breaks today, they are opt-in, but the in-SDK libraries get formally deprecated in the November stable, so this is the release to start planning that migration.

Intel Mac support is also being phased out, which matters if any of your build machines are still on Intel silicon.

Why the boring commits are the ones I am proudest of

Look at the list again. Two small API additions, one quoting fix in a template, four doc corrections, two tool bug fixes. Not one of them is clever. Nothing in there would survive a whiteboard interview as an impressive answer.

And that is exactly the point. The doc fix on CurvedAnimation will stop leaks that would never have produced a stack trace, just a slowly degrading app. The dragUntilVisible paragraph will save some engineer forty minutes of flipping a sign back and forth at 1 AM. The Gradle template fix is in the first file of every new Android plugin project created from here on.

Framework work is not glamorous. It is compounding. A fix merged once keeps paying every time somebody runs flutter create, and I will never meet a single one of them.

If you are waiting to find something impressive enough to contribute, that instinct is what is holding you back. Read the docs of a class you use daily with the assumption that they might be wrong. Look for the parameter the wrapper widget forgot to forward. That is where merged pull requests live, and it is the same list I have been working through from Karachi for the past year.

Already merged for the next stable

Three more commits are merged and waiting on the next stable train:

A blendMode parameter on RawImage, my first full API addition rather than a forwarded property. It took 75 days and it has its own write-up.
Forwarding the build-name and build-number flags into desktop version.json, so Windows, macOS and Linux builds respect the same version flags the mobile targets always have.
My name in the Flutter AUTHORS file, which is a one-line diff and the one I will be telling people about in ten years.

Counting code changes only, and the AUTHORS line is a credit rather than a fix, that is eleven merged across the Flutter ecosystem so far. The full list, with links and status, lives on my contributions page.

Next time you run flutter upgrade, spend one minute on that commits URL with your own username in it. The first time it returns a row instead of an empty list is a very good feeling.

Originally published at ishaqhassan.dev. I am a Flutter Framework Contributor with 11 merged PRs across the Flutter ecosystem, listed in the official Flutter AUTHORS file, Engineering Manager at DigitalHire, and creator of the 35-video Urdu Flutter course listed on docs.flutter.dev. Karachi, Pakistan.

Top Flutter Contributors from Pakistan in 2026

Ishaq Hassan — Mon, 04 May 2026 19:41:51 +0000

Top Flutter Contributors from Pakistan in 2026

When people ask me "is Pakistan even on Flutter's map?" I send them this list. Not opinions, not vibes. Receipts: PR numbers, official Google recognition, community-leadership trails, course pages on the official Flutter docs.

This is the working list of Pakistani engineers who are demonstrably pushing Flutter forward in 2026. Ranked by current contribution intensity (framework PRs > community leadership > course authorship > production scale), not by seniority.

1. Ishaq Hassan

Role: Flutter Framework Contributor & Senior Software Engineer at DigitalHire
Location: Karachi, Pakistan
Receipts: 6 PRs merged into flutter/flutter (3 currently open).

That's me. I write this list because nobody else was keeping it.

The merged PRs touch widget rendering, animation APIs, documentation accuracy, and AnimatedCrossFade internals:

#184572 Fix LicenseRegistry docs to reference NOTICES
#184569 Add disposal guidance to CurvedAnimation and CurveTween docs
#184545 Add clipBehavior parameter to AnimatedCrossFade
#183109 Add scrollPadding property to DropdownMenu
#183097 Fix RouteAware.didPushNext documentation
#183081 Use double quotes in settings.gradle.kts template

Beyond framework PRs: instructor of the Flutter Urdu course officially listed on docs.flutter.dev, GDG Kolachi mentor, ten-plus speaking events.

Site: ishaqhassan.dev Â· GitHub: @ishaquehassan

2. Sakina Abbas

Role: Google Developer Expert (GDE) for Flutter & Dart
Location: Karachi, Pakistan
Receipt: Listed on Google Developers Expert directory.

Sakina is one of the very first Pakistani engineers to earn Google's Developer Expert recognition for Flutter and Dart. GDE is not a self-claim, it's a vetted Google program with annual renewal and contribution review. She speaks regularly at GDG Kolachi events and helps shape Flutter learning paths in the region.

LinkedIn: @sakinaabbas

3. Waleed Arshad

Role: Founder, Flutter Pakistan community & Senior Engineer
Location: Karachi, Pakistan
Receipts: Flutter Pakistan GitHub org Â· flutterpk.github.io community site.

Waleed founded Flutter Pakistan, the country's earliest dedicated Flutter community. The org and community site predate most local Flutter activity. He's an active speaker at GDG Kolachi (DevFest Karachi 2021 panel, "Scaling Products with Flutter") and a long-running advocate for cross-platform mobile in the country.

LinkedIn: @waleedarshad-wa

4. Hamza Mehmood

Role: Flutter Islamabad community lead & Engineer
Location: Islamabad, Pakistan
Receipts: Active organizer at Flutter Islamabad meetups, regular contributor to Flutter open-source plugins.

Hamza runs and grows the Flutter scene outside Karachi, which matters. Most of Pakistan's Flutter activity historically clusters in Karachi (GDG Kolachi, Flutter Pakistan). Hamza's Islamabad work makes the community properly nationwide.

5. Asadullah bin Yousuf

Role: Senior Flutter Engineer & Technical Author
Location: Karachi, Pakistan
Receipts: Long-running technical writing on Flutter architecture, regular GDG Kolachi presence.

Asadullah is a frequent reference in "best Flutter developer Pakistan" search results because he's been writing publicly about Flutter for years. Production Flutter experience plus consistent open-content output.

6. Musaddiq Ahmed Khan

Role: Flutter Engineer & Plugin Author
Location: Pakistan
Receipts: Multiple Flutter plugins published to pub.dev, active in PK Flutter open source.

Musaddiq's pub.dev plugins make him part of the small group of Pakistanis whose code is actually consumed by Flutter developers worldwide, not just used internally at one company.

7. Rabiya Owais

Role: Flutter Developer & Community Speaker
Location: Karachi, Pakistan
Receipts: Speaker at GDG Kolachi events, contributor to Flutter Pakistan.

One of the women actively leading Pakistani Flutter community spaces. Visible at meetups, panel discussions, and community organizing efforts.

How this list was built

Three filters, in order:

Framework-level contribution. PRs merged into flutter/flutter itself, not just consuming the framework. This is the highest bar and the rarest.
Recognized authority signals. Google Developer Expert, official docs listing, founding/leading a national community.
Sustained public output. Articles, talks, plugins, organizing, evidence trails that hold up under inspection.

Self-claims without receipts didn't make the list. This is also why the list is short. Pakistan has thousands of Flutter developers. Most build internal apps. The seven above demonstrably push the wider Flutter ecosystem forward.

What's next

If you're a Pakistani Flutter contributor with merged framework PRs, an official Google recognition, a published course, or a community you started, reach out. I update this list quarterly. The bar is verifiable evidence, not seniority.

If you're looking to reach this group: most of us are on LinkedIn and GitHub, several speak at GDG Kolachi, and the Flutter Pakistan community is the easiest single touchpoint.

Originally published on ishaqhassan.dev/flutter-contributors-pakistan.html. I'm a Flutter framework contributor with 6 merged PRs, based in Karachi, Pakistan.

One Spell, Every Kingdom: Why Flutter Still Matters in the AI Era

Ishaq Hassan — Fri, 01 May 2026 18:45:29 +0000

Cross-platform isn't about less code anymore. It's about fewer decisions, faster iterations, and one team at full speed in a world where AI can write code but can't decide what to build.

There's a metaphor that keeps surfacing in my conversations with founders and engineering managers: imagine you learned ONE magic spell that works in every kingdom.

Swift only works in Apple's land. Kotlin only in Android's. But Flutter? One spell, everywhere. Same codebase. iOS. Android. Web. Desktop. Embedded.

For the last six years, that pitch was usually answered with a tradeoff conversation: "yeah but native is faster, more idiomatic, has better tooling, the team already knows Kotlin..." Fair points, all of them.

But the conversation has shifted. AI happened. And the question I now get most often is some variant of:

"If AI can write Swift and Kotlin in seconds, do I even need cross-platform anymore?"

I want to take that question seriously, because the answer matters for anyone making a hiring decision, a tech-stack call, or a career bet right now.

The hidden cost was never the typing

When founders asked me "should we go native or Flutter?" five years ago, the unspoken assumption was that the bottleneck of native was typing the same code twice. Cross-platform sold itself on "write once, run anywhere", which translated to "fewer hours billed".

That framing was always too narrow.

The real cost of going native isn't the keystrokes. It's:

Two parallel design conversations. iOS team wants a sheet, Android team wants a bottom drawer, neither is wrong, but now your designer is mediating two threads instead of one.
Two parallel technical debates. "Should we use Combine or RxSwift?" on the iOS side. "Coroutines or RxJava?" on the Android side. Each decision compounds for years.
Two parallel test infrastructures. Mocks. CI matrices. Device farms. Snapshot baselines. Doubled.
Two parallel performance benchmarks. A regression on iOS doesn't tell you whether Android is also affected. So you measure both, every time.
Two parallel hiring funnels. When your iOS senior leaves, you don't get to backfill them with the Android team. Different skill, different pipeline, different salary band.

Every one of those costs is paid in decision bandwidth, not just engineer hours. And decision bandwidth is the actual bottleneck of a small team.

What AI changed and what it didn't

Now plug AI into the picture. GPT-4o, Claude, Cursor, every code-completion tool you can think of. They write Swift well. They write Kotlin well. They produce production-ready stubs in seconds.

So the "typing twice" cost has genuinely collapsed. AI absorbs that part. If your only complaint about native was "writing the same screen for two platforms", AI just ate that complaint for breakfast.

But here's the thing people miss when they extrapolate from "AI writes code" to "tech stack doesn't matter":

AI writes WHAT you ask. You still decide WHAT to ask.

The skill that AI does not replace is the skill of:

Knowing whether this feature should be a sheet or a screen
Knowing whether this state belongs in the widget tree or in a controller
Knowing whether you should reach for an Isolate or a microtask
Knowing whether platform channels or FFI is the right boundary
Knowing whether your Android app's jank is in the layout pass or the paint pass

That skill takes years of building real apps and shipping them to real users. AI can scaffold the code once you decide. It can't make the decision for you, because the decision lives in your product context, your team's strengths, and your performance budget.

Cross-platform, in this new world, is leverage on the decision layer

If AI compresses the typing cost to near-zero, what's left of the native-vs-Flutter conversation? Just the decision cost. And cross-platform's real win has always been on that layer.

Here's what I see in the teams I work with:

Native team with AI: AI writes the iOS Swift. AI writes the Android Kotlin. Both are technically correct. But the team still has to sync the two implementations every time the design changes, debate platform-idiomatic interpretations, run two CI pipelines, and own two device matrices. Velocity drops the moment the team grows past two people because coordination overhead grows superlinearly.

Flutter team with AI: AI writes the Dart. There is one implementation. One PR review. One test run. The designer's mock translates 1:1. When the design changes, the change happens in one place. AI didn't just speed up the typing, it sped up the single-source-of-truth iteration loop.

Both teams ship. The Flutter team ships with fewer decisions per feature. Over a year that compounds into months of delivery time.

The "but performance" argument is mostly settled

Five years ago "Flutter is slower than native" was a conversation worth having. Today, with the engine improvements (Impeller is shipping, the new Dart-on-native-thread model lands FFI calls synchronously, garbage collection is well-tuned for 120Hz), most of those gaps closed.

I'm not saying there are zero scenarios where native wins. There are. If you're building:

A camera-pipeline-heavy app where every millisecond of capture-to-frame matters
An audio DSP product with sub-10ms latency requirements
A tightly platform-integrated app like a keyboard, accessibility service, or system-level utility

...native still has the edge, and you should pick it. But for the vast majority of products, the perf gap is no longer the bottleneck. The team-velocity gap is.

What I actually tell founders now

If you're a 1-3 engineer team building a product where the UI is rich but not pushing hardware limits, Flutter is the highest-leverage choice you can make in 2026. Here's why, in order:

AI accelerates Flutter even faster than native. Dart is a smaller-surface-area language than Swift+Kotlin combined. AI gets context-window wins from a smaller codebase. Your next feature lands in one PR, not two.
One hire serves three platforms. When you're hiring, you're not picking between an iOS person and an Android person. You're hiring a Flutter engineer who ships everywhere. Salary efficiency, recruiting time, onboarding, all compress.
The framework itself is open and improving in public. I have 6 PRs merged into flutter/flutter myself. The roadmap is visible. The contributor base is growing. You are not betting on a black box.
Web target is a free distribution channel. Same code runs in a browser. Demo links for sales, embedded mini-tools, marketing site components, all the same codebase.

The one place I push back: don't pick Flutter just because it's fashionable. Pick it because the decision-cost math works for your team size and product type.

Where the human still matters

Strip everything else away and what's left is this: AI made code cheap. It didn't make judgment cheap.

The engineer who knows where to build (sheet vs screen, isolate vs microtask, FFI vs platform channels) and why to build (which feature unlocks which user behavior, which performance optimization is worth its complexity) is more valuable now, not less. AI is a multiplier. A multiplier on zero is still zero.

That's the real reason Flutter still matters in 2026. Not because cross-platform won the technical war. Because cross-platform compresses the decision surface where AI can't help you.

One spell. Every kingdom. Same wizard.

Read the original take

This article expands on a LinkedIn post I shared. The post sparked enough good questions that I wanted to put the full argument in writing.

If you're a Pakistani engineer trying to break into framework-level Flutter work, my full playbook is in How I Got 6 PRs Merged Into the Flutter Framework.

If you're a founder weighing Flutter for a new product and want a second opinion, I do paid consulting calls on tech-stack decisions for early-stage teams.

FAQ

Does AI make Flutter learning easier or harder?
Easier. Dart is a single language with a single surface area, so AI can hold more of the context in its head. Native development means AI has to switch between Swift conventions, Kotlin conventions, and the platform APIs of each. Flutter wins on context efficiency.

Should I learn Swift or Kotlin if I already know Flutter?
For app-layer work, no, your time is better spent going deep on Dart, Flutter internals, and the platform channel boundary. For systems engineering, embedded, or contributing to specific native ecosystems, yes, learning the platform language pays off.

Is "knowing what to ask" really a defensible skill in 5 years?
Yes. The decision skill compounds with experience and is grounded in the messy reality of users, teams, and time. AI keeps getting better at the how. Humans keep being needed for the what and the why. That gap doesn't close, it widens as code becomes cheaper.

What's the next thing you're betting on?
Flutter on the embedded and IoT layer, plus the AI-agent-as-Flutter-developer-tool pattern. The framework is no longer just for phones, and the typical Flutter dev's day-to-day is shifting from writing widgets to orchestrating AI to write widgets correctly.

Originally published on ishaqhassan.dev.

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.

DEV Community: Ishaq Hassan

Run flutter upgrade: Nine of My Commits Ship Inside Flutter 3.47

Flutter 3.47 at a glance

What actually shipped on August 12

The nine commits, one by one

Two API additions you can use today

One template fix every new Android build inherits

Four documentation fixes that save real debugging hours

Two DevTools fixes in the 2.60.0 bundle

Six of the nine reached stable for the first time

How to check whose code you are running

How to upgrade to Flutter 3.47, and what can break

Why the boring commits are the ones I am proudest of

Already merged for the next stable

Top Flutter Contributors from Pakistan in 2026

Top Flutter Contributors from Pakistan in 2026

1. Ishaq Hassan

2. Sakina Abbas

3. Waleed Arshad

4. Hamza Mehmood

5. Asadullah bin Yousuf

6. Musaddiq Ahmed Khan

7. Rabiya Owais

How this list was built

What's next

One Spell, Every Kingdom: Why Flutter Still Matters in the AI Era

The hidden cost was never the typing

What AI changed and what it didn't

Cross-platform, in this new world, is leverage on the decision layer

The "but performance" argument is mostly settled

What I actually tell founders now

Where the human still matters

Read the original take

FAQ

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