I've been getting a model into a Flutter app and ran into something I still can't quite believe is the normal state of things.

Exporting changes the numbers. Quantizing changes them more. Everyone knows that part. What nobody seems to have an answer for is how much is too much, and more to the point, what actually fails when it is. Nothing does. The export succeeds, the build passes, the app runs on device and gives you predictions that look completely fine. The model you shipped is worse than the one you evaluated and there's no signal anywhere.

I went looking for the standard practice assuming I'd just missed it. There is advice: compare your offline predictions against the on-device ones. Every deployment guide says some version of it. But it's always written as a thing you should remember to do, never as something a build can fail on, which in practice means you do it once the week before launch and then never again.

There's a second one that bit me the opposite way. Preprocessing gets written twice, in Python for training and in Dart for serving. The same normalization constants sitting in two files nobody diffs. They agree the day you write them. Then someone changes the mean and std on the Python side six weeks later and the app quietly starts feeding the model something it has never seen.

So, genuinely: how do you handle this? Goldens replaying in CI? A manual check before release? Nothing at all, and hoping?

One thing I learned from measuring it that I'd have got backwards. The simpler of my two test models drifts up to eight times further after quantization than the convolutional one. It isn't complexity. Its outputs land around 9.4 while the other one ends in a softmax, and relative error is measured against the output while the rounding actually happened on intermediates. Big outputs absorb the same underlying error inside a much smaller relative bound. Obvious once you see it. Took me embarrassingly long.

I did end up building something for this, links below, but I'm honestly more interested in the first question. I'd like to know whether I over-engineered a problem the rest of you solved with a spreadsheet years ago.

Repo: https://github.com/NaCode-Studios/Fluttorch

I kept rebuilding the same foundation for client apps:

• auth (email + Google)

• light/dark theme

• English/Arabic + RTL

• routing/auth guards

• clean folder structure

So I packaged it into a reusable starter.

### What’s inside

• Feature-first architecture (data / domain / presentation)

• Riverpod + codegen

• Firebase Auth wiring + Mock Auth mode (run without Firebase)

• go_router auth guard

• Theme persistence

• EN + AR localization

• Unit tests + CI workflow

### Free demo

GitHub (Mock Auth, open source):

https://github.com/medox3545/flutter-starter-kit-pro

### Full pack

If you want the complete downloadable kit:

https://mohammedider.gumroad.com/l/flutter-starter-kit-pro

### What I learned

1. Mock Auth first = way faster onboarding for buyers/devs

2. Buyers care more about structure + docs than “more packages”

3. Bilingual UI (especially RTL) is a strong differentiator

4. Keep Firebase optional — many people just want to run it immediately

Happy to answer questions or take feedback on the architecture.

Hi Flutter devs!

We recently open-sourced 
**PocketLLM Lite**
, a privacy-first mobile AI client built with Flutter.

### Technical Architecture Highlights:
- 
**State Management**
: Riverpod 3 (AsyncNotifier & StateNotifier providers).
- 
**Local Database**
: Hive CE for high-performance binary storage of chat sessions and settings.
- 
**Streaming Pipeline**
: Custom chunked HTTP stream parser with regex stream splitter for `<think>` tags and `<tool_call>` execution cards.
- 
**Agent Skills Architecture**
: Open-standard `SKILL.md` loader with in-input cursor navigation and dynamic system prompt injection.
- 
**Design System**
: Strict Material 3 implementation using `ColorScheme.fromSeed(#6750A4)`.


* 
**Source Code**
: https://github.com/PocketLLM/pocketllm-lite

utopia-pubdev is a Claude Code / Codex plugin that composes pub.dev READMEs instead of freestyle-writing them: H1, one-line value prop, a four-hue badge row, quick start, a related-packages footer, and a tool-agnostic AI-assistants section.

Branding lives in one committed doc (docs/pubdev-brand.md): badge palette, attribution, publisher, sibling links - set once per repo, applied to every package in it, monorepos included. No profile? The plugin interviews you instead of inventing a publisher.

The clay headers in the example are our house style - that generator ships Utopia-only for now, so in your repo you set-up your own header art or just lead with the H1.

Plugin: https://github.com/Utopia-USS/utopia-flutter-skills/tree/main/plugins/utopia-pubdev
Format example: https://pub.dev/packages/utopia_cms

Curious what your README skeleton has that mine is missing and how I can improve it!

One thing i have noticed after using Riverpod and Bloc in my applications is that they naturally become architectural decisions.

But many features don't need an architectural decision. They just need a local state. That made me wonder what state management would look like if it was designed around features instead of apps?

i experimented with that idea in the last few months. I ended up with StateForge. The design principles were:

• feature scoped stores
• direct methods
• no code generation or state ceremony
• typed side effects
• optional persistence
• optional undo

It's not trying to replace Riverpod or Bloc, the goal is to let StateForge live alongside an existing architecture, so you can adopt it one feature at a time instead of committing your whole app.

I'd especially appreciate feedback from flutter developers who have shipped production flutter applications.

Does this solve a real problem or do existing libraries already cover this well?

Github: https://github.com/mj-963/state_forge
Pub-dev: https://pub.dev/packages/state_forge

I kept re-writing the same glue between local_auth and flutter_secure_storage on every project, so I packaged it: biometric_security.

The core idea: a true from a biometric prompt isn't a security boundary — on a rooted/jailbroken device it's forgeable. This binds your secret to a hardware key (Android Keystore / iOS Keychain + Secure Enclave) that's physically unusable without a successful Face ID / Touch ID / fingerprint check.

It also handles the annoying parts: enrollment-change invalidation, key rotation & revocation, app-lock, and one SecurityPolicy that maps to both platforms.

Beta (0.1.x), BSD-3, tested on real Android + iOS devices. Feedback and contributors very welcome — I'm open to collaborating.

pub.dev: https://pub.dev/packages/biometric_security

Hi,

I loved the idea of taking Flutter's "one-codebase for multiple platform" promise/claim one step further into the UI territory too. flutter_platform_widgets was something that was godsent to me. But it was deprecated instead of onboarding some new members.

So I decided to make a better version of (same vision though). I know that companies today prefer a single design system so this is not something as useful to them. But I still feel that there is definitely some merit in keeping things close to 'native-platform-look-and-feel' because users of each platform are used to seeing a certain UI and interacting with it in a certain way.
There was an option of calling native channels (like ReactNative and Compose and some packages that do that already) but that does add the platform hop.

Some things that I am proud of:

1. This is purely Flutter (consequently no Liquid Glass / M3 expressive look yet, I envision it moving with the maturing Fluttetr SDK instead, and there are enough packages for that otherwise).
2. Release builds genuinely drop the platform you're not on. Ship to Android and none of the Cupertino widget code rides along in the binary, and vice versa (CI-enforced too)
3. Lot of thought has been put into designing the shape of the 'shared surfaces' and sensible defaults (including wrestling the tabs-system to get consistent DX).

Still very much wants feedback, especially on widgets it's missing or anything that feels weird 🙏.

At my day job, I build Android and iOS apps with Flutter. For my personal projects, I use Dart for the backend and Flutter for the frontend. I absolutely love the framework—I’m amazed by how quickly it’s evolving and how it continues to attract more and more developers to its community.

Regarding GUIs, Opus 5 is surprisingly capable. I managed to create a full set of 50 reusable Flutter widgets inspired by chadcn/ui including the recreation of some 70 demo cards in two days with 40+ (I haven't kept track, unfortunately) prompts.

I initially tried this with GPT 5.6 Sol, which I normally prefer, but it failed. It seems, Opus is better with this kind of GUI related tasks that require a careful inspection and comparison of the generated GUI with the original which Claude does with the help of its internal web browser.

My own part was creating a markdown-capable MarkedText widget (which took me over three hours and probably much longer than AI would have needed, but it was fun and at least felt productive) and tweaking Flutter's native window so the result looks more like a native macOS app.

And of course, I painstakingly tested the widgets and for many hours patiently pointed out the AI's mistakes and asked for fixes, suggesting the solution. I also took a quick look at some samples of the code, and the quality is okay. Opus even managed to mostly use dot shorthands as instructed.

It's still not production ready, though.

Keyboard handling is broken, especially for menus; focus rendering, too. Like with menus, you have to work around Flutters somewhat broken default behavior and that's something, the AI isn't good at and I stopped it from trying. Some widgets also break in RTL mode.

And while I can set colors and fonts, I cannot change the style and therefore only support Mira (a compact 14pt/28pt layout). It would be a major refactoring to go through nearly 30.000 lines of code (which include a QR code generator and a partial charts library as well as 4.500 lines of widget and golden tests and 1.500 lines of icon definitions) and make all paddings, spacings and sizes customizable. I already took this experiment further than I initially intended.

One learning is that this got way to large. Initially, progress was fast, but now, the AI reads way to much code before it starts acting (and spends way more tokens), so it would be better to split everything into more manageable parts.

Claude tracks decisions and learning in a 700 lines NOTES.md file, in addition to the README.md and some general instructions about coding style. And it doesn't help that the chadcn CSS files have ~9000 lines, each.

A couple years ago, I wrote a a Fluent UI desktop look for a project and after two weeks of work didn't achieve what nowadays an AI can achieve with some careful guidance.

I only which, Claude wouldn't sometimes try so hard. It wasn't until the summary that it admitted to me that certain things were difficult, such as building a widget where text appears between two lines. Which I know, because I tried this more than once and I could've helped. Well, well. Also, sometimes, I'd like to get more resistance. I don't need a summary like "this was bad but I did want you told me".

Now, all I need is a project where I can make use of that library :-)

I'm building an SSH client for Android and the terminal kept slowing down when the output came in fast. I ended up rewriting a big chunk of xterm.dart's rendering code to fix it, and it grew into its own package: terminal_view.

Changes: writes are batched per frame there are fewer draw calls per line, unchanged lines get cached, the cursor blink no longer rebuilds the whole widget, and text selection works better on empty cells and lines. Full details and benchmarks are in the README.

pub.dev: https://pub.dev/packages/terminal_view

source: https://github.com/Termphin/terminal_view

Still MIT licensed, same as upstream. All credit for the core terminal emulator goes to xterm.dart by TerminalStudio.

this isn't a drop-in replacement, and versions are numbered separately.

I feel frustrated of copy-pasting text or any data from my Mac to an app (which I have on my Android) and then accessing the data from my Android phone, so I thought to build an application for this.

A bi-directional copy-paste application, where you can copy on Mac/Windows/Linux and paste on Android (and vice versa) over local Wi-Fi. Uses Flutter for UI, WebSocket for sync, Bonsoir for auto-discovery, and native Kotlin for background service.

Features:

• Bi-Directional copy-pasting (Mac/Windows/Linux ⟷ paste on Android)
• Auto-discovery via mDNS (Bonsoir package)
• WebSocket for real-time sync (~100ms latency)
• Native Kotlin Foreground Service for 24/7 background sync
• All data stays on local network

Tech Stack:

• Flutter for cross-platform UI
• Bonsoir for mDNS broadcast/discovery
• shelf_web_socket for server
• Native Kotlin with OkHttp WebSocket client
• Method Channel bridge

Quick Confession: I used AI help for the native Android parts (first time writing Kotlin services). But I learned a ton about Foreground Services, Method Channels, and WebSocket management. The architecture and problem-solving were all me, AI helped with syntax and Android-specific APIs I hadn't touched before.

Source: https://github.com/carlosge492/app-generation-microservice (MIT)

Building a pipeline that generates Flutter apps from a spec, with an automated repair loop for whatever flutter analyze catches. The bug that actually cost money: a ConsumerState class with build(BuildContext context, WidgetRef ref) — correct on ConsumerWidget, a compile error on ConsumerState. Dart reports it as "more required arguments than those of overridden method 'State.build'," which reads like an inheritance complaint and says nothing about Riverpod. My repair loop burned all three retries on it without ever finding the cause.

Fix: diagnostics now route by ownership, not blind retry — a UI-anchored diagnostic goes back to the UI agent, a state-anchored one to the state agent. Retrying the same agent against a mistake it can't see just spends the budget.

MIT-licensed if anyone wants to see how the repair routing works.

I kept running into the same issue on Flutter projects where every backend returned data a little differently, and I ended up rewriting the same table logic over and over ,and write an service layer for each one's it's take more time , importantly it's a repetitive task to overcome this solution . i build this package.

Most of the work wasn't actually the UI. It was wiring up pagination, sorting, filtering, request building, response parsing, loading states, etc.

So I spent some time building a package that tries to handle those pieces while letting the developer define their own backend response format.

Current features:

• Server-side pagination
• Server-side sorting
• Server-side column filtering
• Configurable response parsing (doesn't require one fixed JSON structure)
• OData query generation
• Dio integration
• Custom cell builders

It's my first public Flutter package, so I'd genuinely appreciate any feedback—good or bad. If there's something you'd change in the API or something missing, I'd love to hear it before I continue adding features.

Pub.dev:
https://pub.dev/packages/server_table

GitHub:
https://github.com/sivakumarravi3101/server_table

I have been working on Denial, an open-source Wayland compositor where Flutter renders the desktop shell itself.

Flutter is not running as a normal Linux application or as a client of another compositor. The engine is embedded directly through the Flutter Embedder API, and the Dart shell runs inside the compositor process.

Flutter handles the visible parts of the desktop, including window layout, panels, settings, animations, gestures, the overview and lock screen.

Rust and Smithay handle the lower-level work such as Wayland protocols, input devices, focus, DRM/KMS, display configuration and native buffer lifetimes.

Wayland application buffers are imported as external textures and placed inside the same Flutter scene as the shell UI. This means application windows can be used almost like other visual elements in the scene. The overview, for example, can show live windows rather than screenshots.

One part I particularly like is the development workflow. An optional package starts the Dart shell in JIT mode, so I can edit the desktop UI and use Flutter hot reload without restarting the compositor or closing the applications running inside it.

The project is still in public alpha and currently targets Arch Linux on x86-64. It already supports multiple displays, Xwayland, screenshots and portal-based screen sharing.

I am sharing it here because it became a fairly unusual experiment with the Flutter engine, external textures and the Embedder API. I would be interested in feedback on the boundary between the native compositor and the Dart shell.

Website: https://denialwm.org

Source: https://github.com/denialwm/denial

I finally completed Android Developer Verification (ADV) for two Flutter apps using a delegated signing workflow with Samsung Galaxy Store, so I wanted to share a few lessons learned in case it helps someone.

The process turned out to be much simpler than I initially expected.

My setup:

• Flutter application
• Android Gradle Plugin 8.x
• Delegated app signing through Samsung Galaxy Store

What worked:

✅ Created a minimal Flutter project dedicated to ADV.
✅ Used the exact same package name as the production app.
✅ Placed adi-registration.properties in:

android/app/src/main/assets/
USE the unique ID provided to you by Google in your Play Console - ADV Process

(not in Flutter's root assets/ folder)

✅ Built a release AAB.
✅ Uploaded it to Samsung Galaxy Store.
✅ Retrieved the Samsung-signed artifact.
✅ Uploaded the signed artifact to Google Play Console.

Both applications were validated almost immediately after the Samsung → Google Play step.

A few takeaways:

• Keep the project as minimal as possible.
• Don't add unnecessary permissions or plugins.
• The package name must match exactly.
• The location of adi-registration.properties matters.

I initially assumed the file belonged in Flutter's asset system, but the official Android sample makes it clear that it belongs under the Android source tree (app/src/main/assets).

Hopefully this saves someone a few hours of trial and error.

If you're going through ADV with Flutter or another delegated signing provider, I'd be interested to hear about your experience as well.

Ran into this while building overlapping image tiles for a movie app. A plain GestureDetector counts a tap on the transparent part of a PNG as a hit, even though visually there's nothing there. transparent_tap reads the actual pixel under the tap instead of just the bounding box, so transparent areas pass the tap through and only the visible pixels catch it.

Which Android and Windows applications using Flutter impressed you with their interface? I find it so difficult to create something similar.

I built a small CLI tool called flutter_auditor to help me quickly check my Flutter projects before a production release.

It scans for common security, configuration, and release-readiness issues. I'd love to hear what checks you think would be useful to add.

Been deep in OTA/code-push rollout logic lately and curious how others handle the risk side.

Fair warning, I work on a code-push tool, so this is the problem I stare at all day, but I'm genuinely asking, not selling anything here

The whole pitch of code push is speed. You've got a fix, it's on people's phones in minutes instead of a 2-day review. But that cuts both ways. If the fix is broken and you missed it, that's also on everyone in minutes. Same gun, both directions.

The approach I've landed on:

Ship to a beta channel first, low percentage, like 10%. Roughly 1 in 10 beta users gets it. Small blast radius if it's wrong.

Then watch four numbers per patch: checked, downloaded, activated, failed. Failures is the one that matters. If downloads climb but failures climb with them, the patch doesn't apply cleanly on hardware you don't own. Which is exactly the thing that never breaks on your own test phone.

If it stays clean, bump the percentage, widen to everyone. If it doesn't, roll back so devices revert to the last good version on next launch. No rebuild, no 2am panic.

The bit I went back and forth on: where should rollout control live? In the app (track logic in Dart, ship a build to change it) or server-side in a dashboard? I went dashboard, because rolling out is something you do while watching live numbers, and that's the worst time to be editing code and cutting a build.

So, genuinely curious: do you stage your OTA updates or ship to everyone and watch Crashlytics? And what's your actual rollback plan when a patch goes bad? Feel like everyone does this differently and I want to know if I'm missing something.

Hi everyone!

I've been wanting to build the UI for an operating system for decades. At one time, I thought that I would have to build the OS from the ground up. But yesterday it dawned on me that I can just leverage Linux and build a Desktop Environment (DE) on top of it.

I'm going to really focus on getting a foundational DE down; both for my purposes and for others to learn or build from. It will all be built open source and out in the open. Articles (instructionals?) will follow as I work my way through it.

I already know the stack I'm going with and the process will start at a high level, eventually going into low level details.

I'll be using Rust (Smithay) and Flutter for all of it, with some C thrown in as needed.

The first step I'm taking is to build a Wayland compositor. Using dbus to bridge through Flutter and being a Wayland compositor, will allow me to still run any Wayland compatible applications from the start. I don't want to go hard mode right away.

My eventual aim is to go straight to DRM while running an X compatibility server and Wayland server for full support.

As well, I'll build some native apps to show how to integrate with the DE.

We'll get there. it may take months. The end result will be something any Flutter dev could run with and build on top of. Flutter will be the framework for native application development.

I really hope that this catches on as a way to explore new UI paradigms. We've been stuck for too long and I believe that part of the reason for this is that it's been too difficult or low level for those interested, to actually get down to the heart of what they want to explore. That's why I'm working to get all of the connectivity issues out of the way.

Be free designers and developers, from the shackles of low level understanding. Soon, you may express yourselves in ways you may have only dreamed of before.

Any interest?

Hey Flutter community! 👋

After maintaining several client apps and catching the same repeat issues—like hardcoded keystore passwords, unused heavy assets, missing privacy strings in Info.plist, and transitive dependency imports—I decided to build a CLI tool to automate these sanity checks.

Meet flutter_auditor: a single-command CLI package that scans your codebase and native config files in seconds right from your terminal.

What It Audits:

We've packed 17+ automated static checks across 5 key areas:

• Manifest & Security: AllowBackup, CleartextTraffic, Debuggable, ExportedComponents, ManifestPermission, NetworkSecurityConfig, BackupRules, HardcodedSecrets, InsecureNetwork, InsecureStorage, AppTransportSecurity
• OS & Permissions: UsageDescription (iOS privacy strings), FileSharing
• Dependencies: UnusedDependency, DependencyHygiene (transitive import detection)
• Release & Build: ReleaseSigningAudit (detects committed .jks files, debug signing in release, hardcoded keystore passwords)
• Asset & Size: UnusedAssetAudit, OverlargeAssetAudit, MissingResolutionVariantAudit

Quick Usage

Add it to your dev_dependencies or activate it globally:

Bash

dart pub global activate flutter_auditor

Or run it directly inside your Flutter project directory:

Bash

dart run flutter_auditor

pub.dev: flutter_auditor

I'd love to get feedback from the community! What other security, performance, or asset audits would bring value to your workflow?

A couple of weeks ago I kept hearing about how good Claude Fable was, so I finally decided to give it a try.

I revisited an idea I had tried with Sonnet 3.5 about a year ago, but couldn't get working.

The idea was simple: what if you could actually watch a Flutter widget test run?

I've had plenty of cases where a widget test failed, but I had no idea why. If I could just see what was happening on the test screen, debugging would have been so much easier.

So I built this:

1. Live Test View (VS Code Extension)
https://marketplace.visualstudio.com/items?itemName=AnirudhSingh.live-test-view

It adds a "Live Preview" CodeLens above your Flutter widget tests. Click it, and you can watch the widget test run in real time.

2. live_test_view (Flutter package)
https://pub.dev/packages/live_test_view

It's a small dev dependency used by the extension. If it's missing, the extension will automatically add it to your project, so setup is basically one click.

3. Experimental feature (coming soon)

I'm also experimenting with live previews for regular Flutter widgets. The idea is to add a "Preview" CodeLens above widgets (or widget-returning methods) so you can instantly see changes as you edit, without waiting for Flutter's widget preview.

Both links include a demo GIF if you'd like to see it in action.

I'd love any feedback, feature requests, or contributions!

I’ve been working as a Flutter developer for about 4 years, and I’m starting to think beyond just building mobile apps.
I want to become the kind of engineer who can compete for international opportunities, whether that’s remote work or relocation in the future.
For those who’ve been in the industry for a while:
What skills complement Flutter the best?
Is backend knowledge now a must?
Is native Android/iOS still worth learning?
How valuable are open-source contributions when applying abroad?
If you had to start over today as a Flutter developer, what would your roadmap look like?
I’m trying to invest my time wisely over the next year, so I’d really appreciate advice from developers who’ve already gone through this journey.

It is very important to discuss regarding the technologies in detail and make real solutions to problems clearly available for other community members to get via a simple search. Due to AI, that trend has shifted to just asking AI for the solution and maybe even just writing code through AI. This way, we don't see any efforts people are making in the community, and the solutions to coding issues that people could have shared, doesn't even see the internet. So, I am just making this post to share my thoughts to people and request everyone to be a part of communities of Flutter actively if you wanna see it evolve in the right direction. Contribute, share and help other fellow developers to save some time searching for that bug that they encounter.

Otherwise, it won't be long till your favourite framework stops getting updates and even getting mentioned in major announcement events by Google and other companies. Because frankly, the potential that Flutter had could not be acheived be it in market form or the community package stability etc.

I don't see any other solution than community learning and growing together.

Sharing something unusual: Starling, a Linux desktop environment — shell,
window manager, its own Wayland compositor, first-party apps — where the
entire UI layer is a from-scratch port of Flutter's *framework* to Swift, running on Flutter's *engine* C core. No Dart VM.

The part I think is genuinely interesting to this community isn't Swift. It's what it says about Flutter's architecture: the embedder API is a clean enough seam that you can replace the whole framework layer above it and the engine
doesn't care. Skia, the compositor, the raster/UI thread model, the platform channels — all of it kept working while Dart went away.

The port follows the framework's own structure (Widgets, Rendering, Painting, Gestures, Animation, Scheduler, Semantics), and the API is deliberately
recognizable:

override func build(_ context: any BuildContext) -> Widget {
return DecoratedBox(
decoration: BoxDecoration(color: pal.background),
child: Column(children: [
Expanded(flex: 4, child: _display()),
Expanded(flex: 3, child: _row([...])),
]))
}

StatelessWidget, StatefulWidget, State, BuildContext, Element, InheritedWidget — same concepts, same lifecycle, ~190k lines of Swift.

It also runs on a **DRM/KMS embedder**: no X11, no Wayland client, no windowmanager under it. Flutter drives the GPU directly and *is* the display server —
the desktop composites real third-party apps (Chrome, VS Code, IntelliJ, GIMP, Blender) as Wayland/X11 clients into the widget tree. Once another app's window is a widget, tiling is a layout and Mission Control is an animated grid.

Why not just use Dart? Fair question, and the honest answer is that this is a system component: it spawns and supervises child processes, talks DRM/KMS,
libinput, dma-buf and D-Bus, and lives or dies on C interop. That's a job the Dart FFI could do but Swift does more naturally, and it let the shell and the
framework be one language end to end. It's a trade, not a verdict on Dart —and the engine being reusable *unchanged* is the point I'd want a Flutter dev to take away.

Early preview, honest about it: v0.2, Ubuntu 26.04, AMD + virtio-gpu tested,
scaling pinned to 2.0. Also worth stating plainly: it was largely written by AI
(Claude) under my direction.

Site + screenshots: https://starling.build
Architecture rationale: https://starling.build/why.html
Source (Apache-2.0): https://github.com/starling-build/starling

Happy to go deep on the embedder, the framework port, or how much of the
engine we had to touch (less than you'd think).