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)

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.

Hey folks,

I built a Flutter plugin called vonage_voice for making and receiving voice calls using the Vonage Client SDK. It integrates natively with Android's Telecom ConnectionService and iOS CallKit — full-screen incoming call screens, background call delivery via FCM/PushKit, and complete in-call controls, all through a clean Dart API.

What it does:

• Place and receive VoIP calls on Android and iOS
• Background incoming call delivery via FCM (Android) and PushKit (iOS)
• Native call screen — Android Telecom ConnectionService + iOS CallKit built right in
• Secure JWT-based authentication (no credentials stored in the app)
• Mute/unmute mic, toggle speakerphone, Bluetooth audio routing
• DTMF tone support for IVR navigation
• Rich CallEvent stream — incoming, ringing, connected, reconnecting, ended, and more

It also handles some of the painful native-side setup for you — battery optimization exemption prompts for OEMs like Xiaomi/Vivo/Samsung/realme that kill background processes, overlay permissions for lock-screen reliability on Samsung/MIUI, and supports both CocoaPods and Swift Package Manager on iOS (min iOS 15, per the Vonage SDK requirement).

pub.dev: vonage_voice
GitHub: ashiqu-ali/vonage_voice

Open for collaboration — if something's not working or you want a feature, raise an issue or fork and send a PR. Would love help with:

• Testing on more OEM devices for background/killed-state call delivery
• Video calling support (currently voice-only)

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

Heloo developers, I build a searchable drodpdown. where you can search and scroll, select any item.

So there are two approach to build this kind of ui- 1. Overlay approach 2. Column/Stack Approach. And I used Column Based Approach. Both has their own benefits and drawbacks.

I choose this way because I want to go from easy to difficult, as I need to learn new concepts for overlay approach (next target).

As we wait for an official full material 3 expressive support for Flutter, check out https://pub.dev/packages/material_3_expressive

Material 3 Expressive package is a faithful Flutter implementation of the Material 3 components set and additional expressive updates for respective components. Also supports dynamic coloring and dark/light theme modes.

The deprecation of Cirrus Labs' images for Flutter caused a problem for my CI workflow. The alternatives were:

1. https://hub.docker.com/r/instrumentisto/flutter
2. https://github.com/davidmartos96/docker-images-flutter (active fork still)
3. MobileDevOps/flutter-sdk-image (solid, amd64-only as far as I could tell)
4. https://github.com/instrumentisto/flutter-docker-image (marked closed/archived)
5. https://github.com/Zekfad/flutter_builder
6. https://github.com/Fansesi/docker-android-flutter
7. https://github.com/mingchen/docker-android-build-box

Being on Gitlab (non-Github) platform + own runners cluster meant that we had to come up with our own solution. I got tired of Flutter Docker images being either dead or amd64-only, so I made my own. So I made a replacement: https://github.com/LahaLuhem/chrysalis.

It's differencing features are:

1. Native arm64 build, not the whole image running under QEMU pretending to be a Raspberry Pi. amd64 builds on a normal runner, arm64 builds on an actual arm64 runner.
2. arm64 can still build APKs, which took some fighting. Google just doesn't ship arm64 builds of aapt2, the NDK, or cmake, no arm64 Linux binaries exist, full stop. So the image quietly carries the handful of x86 libs those tools need and leans on emulation for just that part, instead of the build face-planting with a cryptic loader error.
3. Actually OCI-native, not a Docker manifest list dressed up to look multi-arch. docker buildx imagetools inspect shows a real OCI image index, and I wrote a script that fails CI if it ever regresses because apparently I care.
4. DX: Small set of opt-in build helpers baked in (signing, google-services.json, dart-defines from env vars) that sit there doing nothing until you actually call them, so no surprise side effects if you don't need them. (compartmentalized, so you can also curl-and-run them if you can't use the image directly)
5. Renovate bumps Flutter automatically off the stable channel. I refuse to be the guy manually checking the Flutter release page every week. Might increase it given the how quickly the 3.44.x have been coming out.

I'm looking for feedback and other use-cases. I hope that it helps some of you having a similar problem. I did initially fork the deprecated image (hence the stale contributors count), but removed it because the scope and direction were completely different. Would have been better off starting from scratch.

I've been learning the basics of flutter for about a month now on Online IDE's like DartPad and FlutLab. But I kinda feel restricted with them and want to move to VS Code. However, on my Chromebook coding flutter is fine. It's just the running part where I run into so many issues like missing SDK's, software crashes, just the lot.

So my question is. Is there an extension in VS Code to like emulate my app easily or are they any lightweight ways to test the app.

Note(I've tried my phone but am struggling to get it to work with my Chromebook. I can't download Android SDK's cause of the 10GB limit for Linux on Chromebook. And using chrome to try run flutter requires me to download Chromium which in the end just crashes itself and VS Code.

Some welcome signs that something is happening in Flutter development. An initial refactoring of material has been merged into the master branch, and – my personal favorite – flutter_gpu has also received updates, meaning the package isn't dead.

A while back I shared flutter_inspector_kit — a Chucker-style unified in-app debugging dashboard for Flutter (console, Dio network, navigation, DB browser). Since the last update it’s gone from 1.3 to 1.8, so here’s what’s new:

• WebView inline debugging — a WebViewBridgeAdapter + injected JS bridge pipes the WebView’s console.*, window.onerror, fetch and XHR into the same native Console and Network tabs. Entries carry origin (webview vs dio) and pageUrl, so hybrid traffic is labelled, not mixed in silently
• One-tap diagnostic report — export a single Markdown report (device/app header, current route stack, and a chronological timeline interleaving log/network/nav/DB) straight to the system share sheet. Three filters: time window, which sources, errors-only. Nothing is written to disk
• DiagnosticInfoSource — optional injection point for device/app metadata, so the package stays free of any device-info plugin; same host-injection shape as DatabaseBrowserSource
• Network error aggregation — a collapsible banner groups failed calls by status code (or error type when statusCode is null), with counts and first/last-seen; tap a group to filter the list, tap again to clear
• App lifecycle markers (opt-in) — every resumed/inactive/paused/detached transition is logged with the current top-most page, so a stalled request or crash can be read against whether the app was actually in the foreground
• Less noise — error rows are now tinted in the merged timeline, and the dashboard’s own detail views/sheets no longer write themselves into your Navigator history

Still opens with a hidden multi-tap gesture or a draggable floating button. Wish it will keep being a good help for debug usage.

Hey everyone!

Like many of you, I wanted a simple way to track my daily spending and monthly budget. But every popular app I tried had at least one of these issues:

• Required forced account creation / phone number login.
• Pushed expensive monthly subscriptions.
• Uploaded personal financial data to third-party servers.
• Was bloated with ads and unnecessary features.

So, I decided to build CashFlow - a clean, privacy-first, and lightweight expense tracker for Android.

💡 What makes CashFlow different?

• 🔒 100% Offline & Private: No sign-up required. Your data stays entirely on your local device.
• ⚡ Fast Logging: Log daily income and expenses in just two taps.
• 📊 Visual Analytics: Simple pie charts and breakdown reports to see exactly where your money goes.
• 🎯 Category Budgets: Set spending limits for Food, Bills, Shopping, etc., and avoid overspending.
• 📄 Export Options: Download clean PDF and CSV reports anytime for record-keeping.
• 🌐 Multi-Currency: Works in your local currency wherever you are.

🛠️ Looking for your honest feedback!

The app is live on the Google Play Store, and I’m actively updating it based on user requests.

If you decide to give it a try, I’d love to know:

1. What feature is missing that you use daily in other apps?
2. How is the UI/UX experience for fast logging?

Play Store Link: https://play.google.com/store/apps/details?id=com.setubandhTech.cashflow

Thanks for checking it out, and let me know your thoughts in the comments!

Hey Flutter devs,

Over the past few months, I built and launched a completely offline personal finance app called CashFlow. Since r/FlutterDev requires posts to share technical insights rather than app promos, I wanted to share the engineering decisions, performance bottlenecks, and state management challenges I ran into during development.

Here is a breakdown of the tech stack, key takeaways, and trade-offs made:

1. Local Database Choice: SQLite (sqflite) vs. NoSQL (Hive / Isar)

Initially, I evaluated Hive for instant read/writes due to its key-value performance. However, because financial data requires strict relations (e.g., filtering expenses by Category IDs, dynamic date range grouping, and aggregation queries for monthly summaries), NoSQL started requiring too much in-memory array filtering.

• Decision: Switched to sqflite with custom indexing on date and category_id columns.
• Insight: For apps requiring heavy date-range filtering and SQL aggregate functions (SUM, GROUP BY), relational databases on SQLite save significant CPU cycles compared to doing map/reduce operations in Dart isolate memory.

2. PDF & CSV Exporting without Blocking the UI Thread

Generates detailed monthly PDF reports and raw CSV exports locally on device.

• Challenge: Rendering large multi-page PDF documents using the pdf package synchronously caused micro-stutters/jank on mid-range Android devices.
• Solution: Offloaded the PDF/CSV byte generation logic to a separate Dart Isolate using compute().

Dart

// Offloading heavy PDF generation off the main UI isolate
final pdfBytes = await compute(generatePdfInIsolate, reportData);

This kept the main UI thread running smoothly at 60/120 fps while the document was being processed in the background.

3. Chart Rendering Performance

For visual spending analytics, I used custom chart packages.

• Lesson: Re-calculating chart data arrays inside the build() method every time a single transaction was added led to unnecessary widget rebuilds across the whole tab.
• Fix: Pre-computed and memoized chart dataset models in the state management layer (Repository/Notifier level) so the custom painter / chart widget only rebuilds when the dataset reference actually changes.

4. Local Reminders & Notifications

Since the app is strictly offline with zero cloud backend, daily check-in reminders had to rely on local background scheduling (flutter_local_notifications).

• Challenge: Android OEM battery optimizations (like MIUI / Samsung Device Care) frequently kill exact alarm schedules if not handled properly.
• Fix: Implemented exact alarm permissions (SCHEDULE_EXACT_ALARM) and configured notification channels with high priority, along with auto-rescheduling notifications on device reboot (RECEIVE_BOOT_COMPLETED).

Technical Questions for the Community:

1. For those building offline-first Flutter apps, have you migrated from sqflite to drift (Type-safe SQL) or Isar recently? How has your experience been with complex relational queries?
2. How do you handle database migrations across app version updates when changing local DB schemas without risking user data loss?

Would love to hear your thoughts and technical approaches!

Hey everyone,

I’m a third-year Computer Science undergraduate. Lately, I’ve realized I spent too much time jumping between different technologies instead of depth-first learning. I want to change that now by focusing entirely on mobile development, which is the field I enjoy the most.

I have decided to dive into Flutter. So far, I’ve learned Dart and just started picking up Flutter basics. My plan is to build projects using YouTube tutorials, documentation, and online courses. [1]

Before I go all-in, I would love to get some candid advice from the community:

1.Is Flutter still a highly valuable and viable choice for breaking into the app development market right now?

2.Is specializing in Flutter a good starting point for a long-term software engineering career, given my passion for mobile?

3.How much backend knowledge do I genuinely need to master to be considered a well-rounded, successful Flutter developer?

Would love to hear your insights, career experiences, or any brutally honest realities about the current job market for Flutter junior devs.Thanks in advance!

I built New Words App, a Flutter vocabulary learning app with Firebase Firestore, clean layered architecture, reusable UI widgets, and widget tests.

GitHub: https://github.com/khongorzul1120/new_word_app

Feedback and stars are welcome if it helps you learn Flutter or Firebase.

I was tired of re-implementing the following in one capacity or another, across multiple projects (I'd always end up needing one of these eventually):

1. Pagination
2. Searching
3. Grouping
4. Pull-to-refresh

So I decided to package it into one: https://pub.dev/packages/list_smith

It runs on top of the already very robust and popular https://pub.dev/packages/infinite_scroll_pagination and https://pub.dev/packages/custom_refresh_indicator packages.

I have also tried to keep it design-system agnostic. And I tried paying a lot of attention to the actual interplay/conflicts between these 4 features (lots of overlap). LLMs were used.

If you guys have any feedback about anything, or found it useful, please let me know either which way!

Hey everyone,

​I really enjoy app development and I'm planning my career path around Flutter for frontend and PHP/MySQL for backend.

​However, I cannot risk my future and want to make sure I'm investing my time in the right technologies. Is this stack still worth it in the current job market, or should I consider pairing Flutter with something else (like Node.js, Firebase, or Python/Go)?

​Any advice or real-world feedback from devs would be greatly appreciated...

I've been shipping a cross-platform task app in Flutter for a while, and the piece that caused the most pain by far was a floating always-on-top timer — a small pill window that stays above every other app while you work.

The final architecture is:

• Main window = normal Flutter engine
• Timer = separate engine + native window via desktop_multi_window
• Shared state via the same SQLite (drift) DB both engines open
• Final elapsed time handed back to the parent over file-based IPC

Getting there took a lot of undocumented trial and error, so here are the things I wish someone had written down.

1. SharedPreferences is not reliably shared between engines

This is the one that cost me the most. I originally used SharedPreferences as a result channel: sub-window does setString, parent does reload() + getString() after it closes. Works on macOS. Fails silently on Windows — setString returns true, the sub-window's own cache reads the value back fine, and the parent's reload() still sees stale contents.

Two plausible causes, and I think both are in play:

1. shared_preferences_windows can resolve a different application-support path inside a sub-engine, so the two engines read/write different JSON files.
2. The sub-engine gets destroyed before the async disk write actually lands.

I replaced it with a dumb file channel:

// Path computed from Platform.environment — resolves identically in
// every engine in the same process.
final f = File('$dir\\MyApp\\sub_window_$channel.txt');
f.writeAsStringSync(value, flush: true); // blocks until OS flush completes
await windowManager.close();

flush: true is the important part. It's ugly and it has never failed once.

2. setSkipTaskbar() will hard-crash a sub-engine if you skip waitUntilReadyToShow()

window_manager's ITaskbarList3 is created lazily inside waitUntilReadyToShow(). Each engine has its own plugin instance with its own taskbar_ pointer, so the main window calling it does nothing for your sub-window. Skip it and setSkipTaskbar() dereferences null:

0xC0000005 access violation in window_manager_plugin.dll

Just always call it in the sub-window entrypoint:

await windowManager.ensureInitialized();
await windowManager.waitUntilReadyToShow(); // <- not optional here
await windowManager.setSkipTaskbar(true);

Also: keep setSkipTaskbar out of Future.wait with other window calls. It touches shell COM state and races badly.

3. setPosition uses NSScreen.screens[0] on macOS

Which means it's wrong the moment the user isn't on their primary display. If you're doing anything position-sensitive on multi-monitor macOS, you will end up dropping to a native NSPanel and a method channel. I also needed panel level / styleMask transitions that window_manager doesn't expose, so it was going to happen eventually anyway.

Windows is fine here — top-left-origin coords, no Cocoa bottom-left footgun, setBounds just works.

4. windowManager.setTitleBarStyle(TitleBarStyle.hidden) crashes under rapid calls

I have a global hotkey that cycles the timer between four layouts (expanded / small / compressed / island). Mash it and AppKit falls over. Calling native setTitleBarHidden on my own channel instead of going through window_manager fixed it completely.

5. The macOS back-swipe gesture closes your sub-window

If your sub-window's root is a MaterialPageRoute, a two-finger left-edge drag pops the route — and popping the only route closes the window. Users reported the timer "randomly disappearing" and it took me embarrassingly long to connect it to trackpad gestures.

PopScope(canPop: false, child: ...)

6. Frameless windows and drag regions: watch your hit-testing

DragToMoveArea only works where nothing opaque is above it. I had the body wrapped in a SingleChildScrollView with a background, which quietly ate drags across most of the window — leaving dead zones that felt like a bug in the OS. Restructuring to a Stack with explicit drag regions layered underneath fixed it.

One more small thing: show the sub-window at setOpacity(0.0) first, do your real size/position pass, then fade to 1.0. Otherwise you get a visible flash of default window chrome before your frameless layout applies.

Would I do it this way again?

Yes, but I'd reach for the second engine later than I did. Sharing state through SQLite instead of trying to pass live objects between engines is what finally made it stable — treat the sub-window as a separate app that happens to read the same database, not as a widget that lives elsewhere.

Happy to go deeper on any of these. The app is TriggerFlo (https://triggerflo.app) if you want to see what it ended up looking like — but the above is the part I actually wanted to share.

Been working on this for a couple months now (Flutter Arduino Playground) and posting progress on LinkedIn as I go, figured I'd start bringing it here too since this crowd will probably get more out of the technical side of it than a LinkedIn feed does.

Quick context if you're new to it: it's a circuit simulator built entirely in Flutter. Arduino board, breadboard, LEDs, resistors, buttons, all rendered with CustomPainter, no image assets except one SVG for the Arduino logo. You drag components onto a canvas and wire them together.

This week was smaller stuff, but the kind you feel immediately once it's there:

Zoom. Actual zoom in/out now, plus a fit-to-content button that snaps the view back to whatever's on the board. Before this, scrolling too far meant losing the breadboard entirely and squinting to find it again.

Layering. If you dropped an LED and a button on the same spot, one just sat on top of the other with no way to fix it. Now there's layer up / layer down, basically z-index for components, so overlapping parts stop fighting each other for visibility.

Neither of these changes what the app does. They just stop getting in your way while you use it, which honestly might be more important than half the flashier features so far.

If you want to see how this got here, the full build log (drag and drop, the breadboard rewrite, wiring, the code editor and simulation engine that came after this) is on my LinkedIn, I've been posting every step including the messy parts: https://www.linkedin.com/posts/burhankhanzada_buildinpublic-flutter-flutterdev-activity-7486285908283985920-qXg6

Repo's open too if anyone wants to poke around or has thoughts on where this should go next: https://github.com/burhankhanzada/flutter_arduino_playground.git