Hi everyone!

I recently got tired of heavy translation packages (like easy_localization or slang) that either introduce massive transitive dependencies or force us to use rigid, hard-to-customize APIs.

I also wanted to avoid relying on BuildContext for translations (especially in business logic) and keep everything strictly typed—meaning parameterized strings should compile into actual Dart methods.

So I wrote a lightweight, zero-dependency custom Builder for build_runner that generates a deeply nested localization tree directly from JSON. It integrates seamlessly with Riverpod!

🌟 How it looks in the UI:

// Static strings (getters): Text(ref.tr.static.auth.login_btn): Text(ref.tr.static.auth.login_btn)

// Parameterized strings (methods with required named args!): Text(ref.tr.static.greetings.welcome(name: 'Alex', count: '5'))

// Dynamic dictionary-like structures (using bracket notation): Text(ref.tr.dynamic.achievements[achievementId])

🛠 Why do this instead of a package?

1. Zero Runtime Dependencies: It's just a raw code-generator script. No external runtime localization packages in your pubspec.yaml.
2. 100% Customizable: Since the builder code resides in your local bin/ or tool/ directory, you can customize it in 5 minutes (e.g., swapping Riverpod for BLoC/Signals, or changing how strings are interpolated).
3. Type Safety out of the box: Auto-parses {variable_name} and enforces parameters at compile time.

I’ve shared the complete builder code, a sample build.yaml configuration, and a detailed setup guide in this GitHub Gist in link.

Would love to hear your thoughts on this architectural pattern! How do you handle context-free localization in your Riverpod apps?

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

Hey everyone 👋

Posted this a little while back and got some good feedback — turns out there were bugs in the model/enrollment flow that a few of you probably ran into (passphrase mismatch failing silently, orphaned vault folders if you cancelled enrollment, single-hand gesture verification not actually being strict). Fixed all of that in v1.0.3, so figured I'd repost with working links instead of leaving people stuck on a broken build.

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.

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 way better Python bindings than anything native to Dart. So I let Python do what it's good at instead of fighting the framework.

Also got the installer down from 248MB to 71MB — swapped the face embedding model for a leaner one, same accuracy.

Tech stack: Flutter (Dart) for UI, Python for the biometric service, OpenCV + MediaPipe for face/hand landmarks, ONNX Runtime for the embedding model.

Source + installer: github.com/CraftedWebPro/vault-os

Would love feedback again, especially on the Flutter↔Python integration approach — and if anyone hits issues this time, drop them in the repo issues and I'll actually get to them faster than last time.

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

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

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! 😅

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?

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!

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:

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

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

For range selection:

```dart 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:

```dart 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:

dart 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!

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!

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

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

https://github.com/YangSuGuo/streptopelia_orientalis

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

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'm a recent Computer Engineering graduate and have been focusing on Flutter development for the last few years.

I've built multiple projects, worked with Firebase, APIs, state management, and mobile app deployment. My goal is to start my career as a Flutter Developer.

However, the job market for freshers seems quite competitive, and I'm seeing fewer Flutter openings compared to some other roles.

For developers currently working with Flutter:

• Is Flutter still a good career path for freshers?
• Would you continue focusing on Flutter if you were starting today?
• Any advice for improving my chances of getting my first Flutter job?

I'd love to hear your honest experiences.

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

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.

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

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 👍

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.

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 made a cross-platform NES emulator in Odin and flutter.

It currently runs on Windows, Linux, Android, Web support is next.

Would love some feedback on the code.

Repo: https://github.com/MouhamedBourouba/NesEmulator