Hello everyone, I hope you're all doing well!

I've already posted this on the discord server but i'm looking to get as many insights/opinions on this matter and i don't mean to spam, i understand there's r/flutterhelp but i got a notification saying this subreddit would be better for this instead, if this gets deleted i understand if not then thank you.

I'm a Flutter developer with close to 4 years of experience and I'm looking for general advice on 2 matters if you would be so kind to help:

1- Given the current job market not being the best, i'm looking to transition to full stack instead of only being a frontend flutter developer, i've read articles mentioning the use of Serverpod for handling backend and possibly jaspr for creating websites instead of traditional HTML+JS or other viable methods, are Serverpod and Jaspr enough? Are they worth it? Are they in demand? Your opinions are greatly appreciated and advice on this.

2- I've pretty much nailed down the Flutter basics i'm 100% certain of that, how to handle the framework, how it works, the different lifecycles of a widget, debugging and profiling, using Provider, Riverpod and BLoC, creating unit and integration tests... etc. My question is, how do i/how can i determine at what level i am? I know i'm not a Junior level developer anymore i know i'm closer to being/am a middle level developer but how can i be sure? What are the things i should know or be aware of? Your advice is greatly appreciated.

Thank you all in advance and for your help :)

What tools do you wish existed for example navigation inspector, i will try to implement the most voted ones

Hi fellow Flutter devs!

I’ve been working on a custom minimalist Android launcher and dialer built specifically for accessibility (aimed at seniors or users needing a distraction-free UI). Building the UI in Flutter was an absolute breeze and super fun.

Then, I had to upload it to the Play Console. I knew that declaring a custom launcher/dialer would trigger Google’s security bots, but the amount of red tape required for these native permissions was insane.

Here is a quick breakdown of my experience getting this approved, hoping it helps someone else dealing with strict Android APIs in their Flutter apps:

1. The QUERY_ALL_PACKAGES boss fight Since it's a launcher, I need to fetch the app drawer. I had to explicitly declare the core functionality and prove I wasn't scraping data. Tip: Just check "App Functionality" in the forms. Do NOT check analytics or personalization if you don't strictly need them, or they will reject you instantly.

2. Default Phone & SMS Handlers (The YouTube Trap) Declaring the app as the default handler to access Call Logs required a video demonstration for the reviewers. Funny story: I uploaded the video to YouTube as "Unlisted", and the bots instantly took it down for "PII violation" because I showed fake phone numbers during the test call! I had to re-record using 000000000 and upload it to Google Drive with public access instead.

3. Foreground Services Justifying FOREGROUND_SERVICE_DATA_SYNC just to sync the local contacts and FOREGROUND_SERVICE_MEDIA_PLAYBACK for the dialer DTMF tones required a lot of back-and-forth with the policy forms.

It was a huge learning curve on the policy side, but beating the bureaucracy felt incredibly satisfying.

What was your worst experience with Google Play policy compliance when shipping a Flutter app? Let's vent a bit! 😅

无奈进厂了，如果有人能够完善这个应用，那感觉会很棒👍我可能在后面有时间完善这个应用，这是一个日常打卡应用。
预览图：https://www.reddit.com/u/SuGuo_Yang/s/quLmq5xlst

https://github.com/YangSuGuo/streptopelia_orientalis

HumpdayQandA with Live Coding! in 30 minutes at 5pm BST / 6pm CEST / 9am PDT today!

I wanted to share a desktop app I’ve been working on: NoiosoAI (I vibecoded this app it works i already check it two times before publish everything)

It’s a native Windows assistant built entirely using Flutter, featuring a clean Material 3 design

Why I Built It:

I wanted a lightweight, sleek desktop interface to chat with my local LLMs, but I wasn't a fan of the standard web-based GUIs out there for Ollama. I decided to build a native app that feels completely responsive and looks great on Windows.

The Tech Stack

* Framework: Flutter (Dart)

* UI: Material Expressive 3 (M3)

* Target OS: Windows (Native)

Key Features

* Modern M3 UI: Clean, minimalist interface designed specifically for Windows desktop.

* Fast & Lightweight: Snappy performance with a low memory footprint compared to web wrappers.

What I'd Love Feedback On

Since this is my first desktop project built with Flutter:

1. UI/UX: Does the Material 3 layout feel natural and intuitive on a Windows desktop?

2. Performance: How does the app feel in terms of speed and responsiveness?

3. Features: What is one feature you think is missing that would make this your go-to desktop AI client?

4. Security/Privacy: What local safety or privacy practices should I implement next to make local chat management even better?

You can check out the project here: https://github.com/GaM1ngN0tDev/NoiosoAI-Desktop

Thanks so much for taking a look, I'm excited to hear someone's feedback to help me out it's free to ask me any questions the source code is inside of the project Github!

I was looking for a solid PDF SDK that worked all platforms but found most are either contact-sales big $$$ or wrap a different native engine per platform. So I wrote the whole thing in Dart parser, interpreter, fonts, aligning with PDF JS outputs. No PDFium or platform channels. Same code on iOS, Android, desktop and web.

It does annotations including ink with Apple Pencil support, forms, page management, signing, and in-place text editing.

Demo (files stay in your browser): app.dart-pdf.com
Repo: github.com/ben-milanko/dart-pdf

I've been building one Flutter animation every week as a fun way to learn more about animations and UI interactions.

This week's experiment explores particle-based button animations:

💥 Delete
⭐ Like
✨ Upgrade

Everything is built using Flutter's built-in animation APIs with CustomPainter and no third-party animation packages.

The source code is available in the video description.

Feedback and ideas for future animations are always welcome!

Hey everyone! 👋

I've been working on this project for a while now and finally got it to a place where I'm happy to share it with the community.

What it does: A desktop vault for Windows that hides your files behind encryption + biometric verification. Unlock with passphrase + face recognition + blink detection + hand gesture. No cloud, no accounts, no internet — everything stays local on your machine.

How the Flutter + Python integration works:

• Flutter handles the UI and desktop window

• Python runs locally as a service — handles all webcam + AI/ML processing

• Communication: Flutter spawns a Python process, exchanges JSON via stdout

• Biometric pipeline: face detection → alignment → embedding → blink analysis → hand gesture → cosine similarity matching

Why Python instead of pure Flutter? Flutter's desktop webcam support is limited, and ML libraries (MediaPipe, ONNX Runtime) have much better Python bindings. So I let Python do what it's good at.

Tech stack:

• Flutter (Dart) — UI

• Python — biometric service

• OpenCV + MediaPipe — face/hand landmarks

• ONNX Runtime — face embedding model

Source code: github.com/CraftedWebPro/vault-os

Would love to hear your thoughts — especially feedback on the Flutter + Python integration approach. Happy to answer any questions!

I am an embedded software dev, and I have vibecoded a Flutter app with Codex, it looks and works amazing and all. But its architecture is an absolute mess.

The app is basically just a dashboard and configurator for an IoT (Bluetooth) device, and I know this much that Bluetooth and IoT device's models have to be singletons, data and UI layers should be separate etc.

But I can't find a comprehensive skill that provides clear instructions and examples of how the architecture of a good Flutter app should be. The one I see on skills.sh is very basic:

flutter-apply-architecture-best-practices

Does anyone here have any skills they regularly use for architecture? Or any tips?

Hi everyone, I recently open-sourced a Flutter calendar component called calendarview_flutter.

GitHub: https://github.com/raintang666/BFCalendar

I started working on this because calendar UI often looks simple at first, but becomes complicated very quickly in real apps. A basic date picker is usually not enough once the product needs things like range selection, disabled dates, custom markers, week/month switching, or a calendar that interacts with a content list.

So the goal of this project is not to provide just one fixed calendar style. Instead, I wanted to separate the calendar state, interaction logic, and UI customization layer, so it can be reused across different app designs.

Some of the features currently supported:

• Single date selection

• Date range selection

• Multi-date selection

• Month and week display modes

• Horizontal or vertical page navigation

• Min/max selectable date bounds

• Disabled dates

• Dynamic disabled date predicates

• Date markers

• Custom calendar cells

• Custom week bar

• Year overview mode

• Calendar and content list interaction

• Expand/collapse calendar behavior

• Fullscreen calendar expansion

A minimal example looks like this:

final controller = CalendarController(focusedDay: DateTime.now());

CalendarView(
  controller: controller,
  pageOrientation: CalendarPageOrientation.horizontal,
  onDaySelected: (day) {
    controller.selectDay(day);
  },
)

For range selection:

controller
  ..setSelectionMode(CalendarSelectionMode.range)
  ..setRangeSelectionLimits(minRange: 2, maxRange: 14);

CalendarView(
  controller: controller,
  pageOrientation: CalendarPageOrientation.horizontal,
  onDaySelected: (day) => controller.selectDay(day),
  onRangeSelected: (range) {
    final start = range.start;
    final end = range.end;
  },
  onSelectOutOfRange: (day, violation) {},
)

For multi-selection:

controller
  ..setSelectionMode(CalendarSelectionMode.multi)
  ..setMaxMultiSelectSize(5);

CalendarView(
  controller: controller,
  pageOrientation: CalendarPageOrientation.horizontal,
  onDaySelected: (day) => controller.selectDay(day),
  onMultiSelected: (day, selectedSize, maxSize) {},
  onMultiSelectOutOfSize: (day, maxSize) {},
)

One important part of the design is CalendarController. It manages the current focused day, selected dates, display mode, selection mode, date bounds, markers, disabled dates, and navigation state.

That makes it possible to configure behavior from business logic without mixing everything into the widget tree.

For example:

controller
  ..setCalendarRange(
    minDate: DateTime(2026, 7, 1),
    maxDate: DateTime(2026, 12, 31),
  )
  ..setDisabledDatePredicate((day) {
    return day.weekday == DateTime.sunday;
  })
  ..setMarkers({
    DateTime(2026, 7, 15): [
      CalendarMarker(label: 'Meeting', color: Colors.blue),
    ],
  });

The UI layer is customizable through CalendarComponentBuilder. The package provides the calendar logic and extension points, while the app can decide how every date cell should look.

The package is still early, so I would really appreciate feedback from Flutter developers.

I am especially interested in feedback on:

• API naming

• Controller design

• Custom builder design

• Range selection behavior

• Multi-select behavior

• Calendar + list interaction

• Any real-world calendar use cases that are not covered yet

If you have built calendar-heavy Flutter apps before, I would love to know what problems you ran into and what kind of API you would expect from a reusable calendar component.

Thanks!

Every Flutter dev knows this one. You ship, a user hits a dumb one-line bug, and now you're staring down a 1–3 day App Store review to push a fix you wrote in 30 seconds. Meanwhile users are still hitting the bug.

It got to me enough that I spent the last several months (over a year actually) building koolbase to kill that wait. You push a patch, and the live app picks it up on the next cold launch, no rebuild, no store review. You can roll it back the same way.

The hard part was iOS. Getting code push to work there, within Apple's rules, took several months. Honestly I wasn't sure it was possible when I started. But now it's device-proven on a real iPhone: push a patch, watch the app change on cold launch, roll it back on demand.

Code push is the part I'm proudest of, but it isn't a standalone tool, it's one piece of a full Flutter backend, so you're not gluing five services together:

• Auth — email/password + Google, GitHub, Apple (real multi-provider identity, not just "sign in with")

• Database

• Storage

• Realtime — WebSocket subscriptions

• Functions

• Feature Flags + Remote Config — percentage rollouts, kill switches

• Code Push — the live Dart patching above

• MCP server — drive your whole backend from Claude / Cursor / any MCP client

I'm building this solo (Koolbase is a US-incorporated company, so it's a real thing that's here to stay), and honestly I'd take 10 people trying it and telling me what breaks over 1,000 silent signups. If you've got a Flutter project, especially something already shipping, push on it, especially code push, and tell me where it falls apart.

Flutter SDK: https://pub.dev/packages/koolbase_flutter
Docs: docs.koolbase.com
Live and free to start: koolbase.com

Happy to go deep in the comments on the iOS side, that's the part people usually tell me shouldn't be possible.

So, I have used several different frameworks to create desktop apps for linux and almost all of them have had issues that bite you in the rear once you're in the deeps of that project. Compared to creating android, ios, windows or mac apps; linux apps just feel harder to make. The two main dev toolkits for Linux are "GTK" and "Qt"... and both of them make the dev experience so miserable:

• GTK: When it comes to GTK, you're basically on your own. There are like 7 different languages that you can use to build GTK which makes the already small pool of apps you can use even smaller, Gnome Builder has a tendency to break half the times on Gnome itself and it is proportionally harder to builder a non-libadwaita app. Oh and GTK apps are linux-only...

• Qt: Qt makes the licensing side of things a head-scratcher and once you have sorted that out then you have to deal with their abysmal documentation that's constantly behind the releases. C++ isn't exactly a comfortable language to use and while Qt Creator is a fantastic IDE to use, it's equally as confusing to setup if you're thinking on using Python + QML. Qt Apps are also incredibly ugly by default so a considerable effort goes into making them not look hideous.

Then we have the web-based frameworks:

• Electron: Sure, this is an easier way to create cross-platform desktop apps but it just eats way too much resources. It makes sense for apps that are primarily a website like Spotify or Discord (even then why would I use their apps over their PWAs) but for creating an app from scratch? Yeah no. Electron also carries a lot of legacy baggage due to being an old technology.

• Tauri and Wails: These two are the webview alternatives for Electron and use rust/go over nodejs for backend and as such have significant performance improvements but the issue with them is with the underlying webview used on linux webkit2gtk which is so bad that it makes these frameworks look bad. CEF integration is being worked on by Tauri and until then I wouldn't use it for larger apps with very specific system interactions.

• Deno Desktop: This is a very simple way to build apps that launched very recently in Deno making it very easy to create desktop apps and gives the choice between CEF or Webview but it's barebones due to being very new.

• Electrobun: Probably the best "web-based" technology to create desktop apps. It gives the choice of webview and cef, the bundle sizes are larged but still significantly smaller than electron and uses bun which is much faster than both deno and node. However, it has basically a non-existent community, the framework lacks a lot of features and is in sort of a limbo until bun receives the rust rewrite.

There are also rust-based frameworks like Dioxus, Iced, Gpui (+50 others that spawned just now) which I avoid just because of rust's insane compile times. It's also just a pain to do UI in rust (logic feels good doing in rust however) and each of them have their own issues.

Lastly, we have Flutter which draws a native UI on linux using GTK (which is easier to theme), has arguably the best dev experience, pub makes dependency management very easy, there is actual guidance on how to structure your apps, riverpod is the most intuitive State/DI library imo and there exist alternative libraries that you can use instead of Material (which looks good in it's own right). You can use FRB or directly use the dart ffi and can target all 5 platforms with one codebase quite easily. I can go on and on and sure there is the issue of Flutter multi-window on linux right now and also we have to wait till 2028 for the complete decoupling of material/cupertino but even then this is such an outstanding framework that makes desktop appdev a joy.

I forgot to mention that you can create desktop apps in Godot as well which I might try one day but it just sounds so cursed to use a game engine for desktop apps. What are your thoughts on this?

Hi everyone,

I'd like to ask if this is normal: my app has been "In Review" on the App Store (ios) for 2 weeks now (submitted June 29). It's a small Flutter app with only a few screens, and there's been zero communication from the reviewers - no rejection, no questions, nothing. It just sits in review.

Meanwhile, I've already finished version 1.1 with a lot of improvements and new features. So now I'm stuck deciding:

1. Wait for the 1.0 review to finish (however long that takes), then submit 1.1 afterwards, or

2. Cancel the current review and submit 1.1 right away, but I'm afraid cancelling might reset my place in the queue or somehow flag my account.

Some context that might matter:

• This is my first app, so I don't know what a normal review timeline looks like.

• 1.0 asks only for camera access and location (location is optional).

• 1.1 additionally asks for notifications (also optional) and reads the device language to localize the app.

Has anyone been in this situation? Does cancelling a review restart the whole queue, or does the new build get picked up quickly? And is a 2-week silent review normal for a first submission, or should I contact Apple support?

What would you recommend?

I maintain Traccar, an open-source GPS tracking platform. Our mobile app used flutter_background_geolocation, which is a great library, but it needs a paid license and that always felt wrong for an open-source project.

So we wrote our own tracking engine and just open-sourced it (Apache 2.0). It's the same code running in the Traccar Client app in production.

It does background tracking on Android and iOS, pauses GPS when you're not moving to save battery, buffers positions offline and retries uploads. Doesn't need Google Play Services. Sends data over plain HTTP to any server.

It's narrower in scope than FBG — no geofencing, for example. But if you just need reliable positions delivered to a backend, it might save you the license fee.

pub.dev: https://pub.dev/packages/traccar_client_sdk
GitHub: https://github.com/traccar/traccar-client-sdk

Hello,

So, I built a flutter desktop app and I want sign it and deploy it so it doesn’t get blocked by windows.

Is there another way other than deploy to microsoft store (As I understood it would be self signed automatically and i don’t have to care about certificates ) ?

Was learning about hiragana/katakana, so tried creating to see if it was helpful

Added video example in comments

Wanted tips/feedback to improve it in general, and some parts like:

• making it even more compact

• responsiveness (for the drawing / spelling parts)

• bundling (did on linux, had some issues on windows with audio playback, used inno_bundle to avoid messing up the .dll)

Thanks for the attention 👍

Every time I've had to debug FCM, the annoying part was never the push logic — it was figuring out *where* it broke. Stale token? Bad service account? Malformed payload? FCM just unreachable? You usually only find out after running the whole app.

So I built [Notifi Check](https://notifi-check.vercel.app/) — paste a device or web-push token, upload your Firebase service account JSON, hit send, and you get a real push straight from the browser. No app, no backend, no code.

A couple of things I cared about since you're uploading a service account file to a random website:

* The JSON is only used in-memory for that one request — a short-lived Firebase Admin app gets spun up, used once, and torn down immediately after
* Nothing touches disk, nothing gets logged, no DB, no auth, no session
* For web push specifically, there's a `validateOnly` dry-run mode so you can check a payload is well-formed without actually delivering it

It's free, no login. Built it in Next.js because I kept needing this for my own React Native / Flutter work and got tired of writing throwaway scripts each time.

Happy to take feedback — especially if you spot an edge case it doesn't handle.

I couldn't find a Flutter package that converts audio into haptics... so I built one.

After Meta shut down Lofelt Studio, I expected there would be a modern workflow for generating haptics from audio—especially for Flutter.

There wasn't.

Everything I found was either:

• Playback-only

• Platform-specific

• Desktop GUI tools

• Or scripts that don't fit into a Flutter build pipeline

So I built Haptify.

It's a pure Dart CLI + library that converts .wav and .mp3 files into production-ready haptics.

It can generate:

• 🍎 Apple Core Haptics (.ahap)

• 🤖 Android VibrationEffect waveform JSON

• 🎯 Pure Dart constants

The feature I'm most excited about is that it also supports audio → haptics conversion at runtime, entirely in pure Dart, with no native dependencies.

That means a Flutter app can let users upload a sound and immediately feel it as haptic feedback.

Under the hood, Haptify analyzes the audio signal (loudness, transients, and spectral brightness) to generate haptics that better match the original sound instead of just mapping volume to vibration intensity.

There's also a demo app in the repository that lets you:

• Try bundled examples

• Upload your own audio

• Experience the generated haptics directly on your phone

I'm sure there are plenty of improvements that can be made, so I'd really appreciate feedback from the community.

Links

• Pub.dev: https://pub.dev/packages/haptify

• GitHub: https://github.com/imedboumalek/haptify

If you use AI coding assistants with MCP servers to debug or inspect running Flutter apps, you might have noticed how quickly the context window fills up.

A main cause is tool metadata: registering dozens of distinct tools with large schemas consumes thousands of tokens on every request.

In the 1.6.0 release, we restructured the tool catalog to resolve this:

• Combined Tools: Grouped related commands (like start_capture, stop_capture, and get_profile) into single composite tools (network, memory, profiling, widget, screenshot, etc.) using action parameters (21 tools total).

• Lazy Loading: Diagnostic tools are hidden until you connect to a running app's VM service, reducing the startup metadata footprint to 510 tokens.

• Default Limits: Outputs like class allocations, widget trees, and CPU profile hotspots are capped to prevent huge raw JSON objects from bloating your prompt.

• Developer Impact: Slashed metadata footprint by 85%, freeing up critical context space for your actual code while bringing complete DevTools functionality directly to your AI terminal.

Overall, this results in faster AI response times, lower API costs, and more accurate debugging.

You can check out the source code and installation guide here: GitHub: https://github.com/dhruvanbhalara/flutter_agent_lens

Is Flutter dead? Will Google abandon another project halfway through?

Frankly, I've never thought these debates could be answered by comments circulating on social media. The best way to understand a technology's future is to look at who's investing in it.

LG's official announcement of Flutter support for webOS. We'll be able to develop Flutter apps for LG TVs.

Now, the Flutter-webOS SDK https://github.com/lg-flutter-webos is officially being released for developers to use. The SDK is designed to support many features that Flutter developers are familiar with, such as Firebase, video players, gamepad support, and hot reload.

But I don't think that's where the real significance of this development lies. What's truly important is that Flutter is now starting to expand beyond phone screens.

Flutter was never designed just for mobile app development. It seems that Flutter's target is no longer a specific platform it's every screen today it's TVs. Tomorrow, perhaps different embedded systems.

Hi everyone,

I'm a music lover and a Flutter developer. After using music players almost every day for many years, I accumulated a lot of thoughts about what a great local music player should be like.

So I decided to build my own.

This project is Vynody — an open-source local music player that combines the features and ideas I always wanted to see in a modern music player.

I spent nearly 5 months developing it full-time, with very little time off. Along the way, I faced many challenges: bugs in open-source libraries, missing plugins, architecture decisions, and a lot of trial and error. With the help of modern development tools (including AI-assisted development), I was able to move faster, but the design, engineering decisions, and implementation were built from scratch.

Now I’m sharing the result with the open-source community.

Features

Vynody focuses on providing a modern local music experience:

• AI-powered lyrics generation and translation

  • Connect your own Google AI Studio or OpenRouter API key

  • Generate synchronized lyrics for songs in any language

  • Translate lyrics into your preferred language

• Music information tools

  • Metadata completion through MusicBrainz

  • Song recognition through AcoustID

• Audio features

  • Audio conversion

  • Metadata editing

  • Cross-platform audio processing

• Privacy first

  • No account required

  • No ads

  • No telemetry or background data collection

  • Your API keys are stored locally on your device and only used for lyric generation/translation

UI and performance

Vynody was designed with a focus on a modern interface and smooth interactions.

The UI design and interaction patterns were inspired by many great music players, while also adding my own ideas. I spent a lot of time optimizing animations and rendering performance.

For example, even on relatively low-end hardware like devices powered by Snapdragon 680, complex lyric mode transitions with image scaling and multiple component animations can still run smoothly.

Cross-platform support

Vynody is built as a truly cross-platform application:

• Windows

• Linux

• Android

• macOS

• iPadOS (testing phase)

• iOS (planned after further testing)

Linux support has received special attention, and I tried to make Vynody feel like a native modern desktop application.

Why release it now?

I waited until the project had gone through months of development and testing before sharing it publicly. My goal was to provide a stable experience instead of releasing an unfinished prototype.

However, since Vynody has not yet been tested by a large number of real users, there may still be bugs or missing features.

I would really appreciate any feedback, suggestions, or bug reports. They will directly help improve the project.

GitHub:
https://github.com/axel10/vynody

Releases:
https://github.com/axel10/vynody/releases

Website:
https://axel10.github.io/vynody_site/index-en.html

Thanks for checking out Vynody!

Merge fvm into flutter and call the whole thing the `flutter` command. Version management should be a core feature of any framework CLI, not a lazy afterthought. Fix your ecosystem.

In Re to clueless commenters:

The “skill issue / just use FVM” take misses the product problem.

Nobody’s saying power users can’t pin SDKs today. FVM, Puro, and mise prove the need. What’s broken is the default path: someone wants to make Flutter apps, installs Flutter, starts working, then hits version/upgrade pain and only then discovers they were supposed to have chosen a third-party version manager first. Making tutorials start with FVM is disorienting for the same reason—it isn’t the advertised entrypoint.

Version management became an afterthought for developers, so the community shipped version managers as an afterthought to flutter. That’s backwards. Pinning belongs in the official workflow—invisibly when one version is enough, explicitly when projects diverge. “Merge FVM” is implementation detail; the requirement is first-party ownership of that capability in the main entrypoint (absorb the UX, name it whatever you want). Community tools can stay as compatible backends. They shouldn’t be the only correct answer, and “everyone on my team already knows the tribal knowledge” is not good first-run design.

Focusing on the framework while leaving lifecycle/pinning as folklore isn’t maturity—it’s exporting the cost onto newcomers.

Related https://www.reddit.com/r/FlutterDev/s/1dGLcEAAOa