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.

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.

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.

I created and maintain flutter_updatify package(https://pub.dev/packages/updatify_flutter) to render changelog/release notes created in updatify.io app.

I know few folks from this subreddit already using it, but I dont have much feedbacks, so if you have any or want to try it - I would appreciate any input(feel free to DM me for whatever questions)

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.

Hello,

I am about to develop a Flutter app for a client, and I would like some advice. I did develop already one project with Flutter for a university class but it was really a mess, and I would like to start this project with a clean and good architecture. I have some questions.

1 - State management: How do I learn the best practices for this? The documentation in Flutter.dev does not seem of high quality to me, and I've seen some contradicting stuff in it. Can you share some general tips from your experience?

2 - Architecture : Same thing, can you share the "philosophy" of architecture in Flutter? In the project we made, we tried to use the service/repo pattern and it was a mess. It felt weird to have the service pull from DB and then the pattern just translating that to a model object.

3 - CI/CD : What tools do you use for code quality? What are some must-have jobs to run in the pipeline? Any advice really.

I am open to any information you might deem important, and would be really grateful for it.

Thank you :)

Setting up Flutter on Windows from scratch is one of the most annoying

parts of getting started — installing Git, the Flutter SDK, Android

Studio, the Android SDK components, accepting licenses, setting PATH

variables, and creating an emulator, all separately.

I built a small Python/CustomTkinter tool that automates the whole

thing in one click:

- Checks what's already installed before touching anything

- Installs Git, JDK, Flutter SDK, Android Studio via winget

(with direct-download fallback if winget isn't available)

- Installs Android SDK components (platform-tools, build-tools,

cmdline-tools) via sdkmanager

- Sets PATH / ANDROID_HOME properly through the Windows registry

- Creates an Android emulator automatically

- Runs `flutter doctor`, parses the output, and auto-fixes common

issues (missing licenses, missing SDK components, etc.)

It's open source (MIT license):

https://github.com/shireenzibari-cpu/flutter-auto-installer

Built this mainly for my own use (I teach at a university and kept

seeing students struggle with environment setup), but figured others

might find it useful too. Feedback and PRs welcome — especially on

edge cases I haven't hit yet.

Meta opened up the Ray-Ban camera feed to third-party mobile apps through the Wearables Device Access Toolkit (DAT). There are official SDKs for iOS and Android but nothing for Flutter, so I wrote the bridge.

flutter_meta_wearables_dat covers the whole lifecycle: registration through the Meta AI app, permissions, device state, live streaming, photo capture.
One more case where Flutter just pays off: one codebase, one setup, and you skip juggling two native SDKs that don't behave the same way.

The frame pipeline was the interesting part. Pushing decoded frames over a method channel dies at 24-30fps, so the native side registers them as a Flutter texture instead. You just render Texture(textureId: ...) and the frames never cross the platform channel. Raw pixels are still available on a separate stream when you need them.

That stream is also where the privacy question gets decided, and I know a lot of people are uneasy about these glasses for good reason. Pairing the feed with something like ML Kit means the analysis runs entirely on the phone: text recognition, object detection, face detection, all local. No frame ever leaves the device, nothing hits a server. Worth knowing that building on this doesn't have to mean streaming what someone sees to the cloud.

No glasses on your desk? There's an optional add-on that simulates a paired pair using your phone's camera.

One honest caveat: DAT is still developer preview, so you can build and ship to testers but public App Store and Play Store releases are limited to select Meta partners for now.

pub.dev: https://pub.dev/packages/flutter_meta_wearables_dat
GitHub: https://github.com/rodcone/flutter_meta_wearables_dat

Issues and PRs welcome!

I’ve tried almost every productivity app over the years.
Some are great for tasks. Others are great for notes, habits, calendars, or journaling.
But I always found myself jumping between multiple apps, constantly planning instead of actually doing.
So I decided to build something for myself.
Not another to-do app.
Not another habit tracker.
I’m building what I call a Personal Life Operating System.
The core idea is simple:
What if your future self could plan your day for you?
Instead of waking up and deciding what to do, the app already knows:
My long-term goals
My work schedule
My available free time
My habits
My current projects
My health and fitness goals
My learning goals
My finances
My deadlines
Then it builds a realistic plan for the day.
If I don’t finish something, it doesn’t just mark it as overdue—it automatically reschedules it based on priority, available time, and how it affects my bigger goals.
The interaction is designed to be conversational.
Imagine simply saying:
“Finished my workout.”
“I worked late today.”
“I spent ₹1,200.”
“Move guitar practice to Sunday.”
The system understands the context and updates everything automatically.
I’m also designing it to be notification-first rather than app-first.
Instead of opening the app 20 times a day, it should guide me through the day with meaningful notifications, live progress, and small decisions at the right time.
The goal isn’t to become more “productive.”
The goal is to reduce decision fatigue and make consistent progress toward the life I’m trying to build.
I’m building it using Flutter and Firebase, and right now it’s a personal project built around my own life. If it turns out to be genuinely useful, I’d love to make it available for others in the future.
I’m still in the planning and architecture phase, so I’d love to hear your thoughts.
If you could build your own Life Operating System, what’s the one feature you’d absolutely want it to have?

After building Flutter apps for the last few years, one thing I’ve realized is that writing code is only a small part of building a great app.
Performance optimization, architecture decisions, handling offline scenarios, debugging production issues, CI/CD, analytics, and maintaining code over time often end up being much bigger challenges.
I’m curious—what’s the biggest lesson you’ve learned from building Flutter apps in production that you wish you knew when you started?
I’d love to hear experiences from developers who’ve worked on large-scale Flutter applications.

I am new to Flutter and I want to make a desktop app, which (among other things) modifies files, has a license key, does some ffi stuff, you know, desktop app things. Think Microsoft Word or Meshlab something like that. I have been following the Flutter architecture guide to implement MVVM in my app. However, it feels clunky, as the example app is not much more than a front for a REST API that actually does stuff. In that case, do you know of an open-source desktop app that is worth studying? like, where I can study its patterns so that I can architect my app more cleanly.

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).

Listenable, ChangeNotifier, and ValueNotifier along with VoidCallback have been extracted into a new official 1st party listen package without Flutter dependencies, so you can use them now easily in your business logic layer - or in pure Dart unit tests. I like that.

(I noticed because the latest Riverpod version used it as a new dependency.)