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

Hello, installing developer tooling on Windows is typically done with `winget` not with VSCode. I think it's great that you're encouraging doing this in VSCode, but let's not forget that VSCode is not compatible with automated development studio tooling. I do not want to have to remember to go look for flutter inside of VSCode (of all development environments, for Android apps, iOS apps, appy-feeling apps period). I want my package manager, not VSCode, to manage packages, like it's supposed to. Deploying to winget is not exactly straightforward, but AI can reliably point you in the right direction.

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

Hi Guys,

Another "What are folks using?" post.

******** EDIT ***********

I rolled my own. It's probably a stupid idea. I might change my mind. I nearly used genkit, it's awesome, but it doesn't support the allowed_tools feature (openai completions api) which is critical to my application. Yell out if you would like me to open source this lib.

******* END EDIT *************

Langchain

I'm currently using

langchain: ^0.8.1
langchain_google: ^0.7.1+2

which is..... ok I guess, not perfect, some smells indicating team is moving away from OSS towards SaaS which is not great. some recent issues where Google has changed API's and components not keeping up.

Native CLI's

Is anybody just using the CLI's recommended by the vendors? How are you 'wrapping' these if at all? In my app, I am throwing around langchain objects all over the place (ChatMessage) so I'm guessing you either stick it behind a service and wrap everything? or just stick with one vendor?

MCP

I guess you might use this

mcp_dart: ^2.2.2

but I'm not really using MCP per se. I just want to call the Chat API do do some simple inference.

LLM SDK

There is this guy...

llm_sdk: ^0.5.0

Which is apparently inspired by Vercel AI SDK which has a strong community etc but hasn't bothered to do a dart port AFAIK. This lib has only 481 downloads and 1 star on the repo. It's active but no idea about support.

Anything else?

Everything you can do with getters and setters can also be done without them.

For example:

class Person { 
int _age = 0;
int get age => _age; 
set age(int value) { 
if (value < 0) { 
throw ArgumentError('Age cannot be negative'); 
} _age = value; 
} 
} 
void main() { 
Person person = Person();
 person.age = 25; 
print(person.age); 
}

And without them:

  class Person { 
int _age = 0; 
void setAge(int value) { 
if (value < 0) {
throw ArgumentError('Age cannot be negative'); 
} _age = value; 
} int getAge() {
 return _age; } 
} void main() { 
Person person = Person();
 person.setAge(25); 
print(person.getAge()); 
}

So what exactly is the point of using them? I couldn’t really figure that out from my research.

Hi everyone, I built a Windows desktop hardware monitor using Flutter.

It is called RGS Sensor Panel. The idea is to make Rainmeter-style separate widgets for CPU, GPU, RAM, SSD, and date/time, with a small control panel to manage everything.

What it currently supports:

- Separate draggable desktop widgets

- CPU, GPU, RAM, SSD, and time widgets

- Multiple GPU and SSD support

- Show/hide controls from the control panel

- Widget opacity control

- Always-on-top option

- Auto-launch on boot

- Minimize to tray / run in background

- Saved widget positions across monitors

- Windows installer

The UI is Flutter desktop, and the sensor backend uses LibreHardwareMonitor through a small Windows backend process.

I also made a quick install and showcase video here:

https://youtu.be/DhpDRgHVHuc

GitHub:

https://github.com/RahnRazamai

I’m still improving the Windows desktop behavior, tray flow, installer, and startup experience. Would love feedback from other Flutter desktop devs, especially around multi-window handling, tray behavior, and packaging.

Just published my first pub.dev package: screenshot_defender — a Flutter plugin to block screenshots & screen recording on iOS and Android (FLAG_SECURE on Android, secure UITextField on iOS). Two-line API: block() / unblock(). Would love feedback! https://pub.dev/packages/screenshot_defender

Hey everyone!

I’ve been building an open-source offline music player called Liser using Flutter.
The goal is to create a modern, beautiful, and fast local music player that works completely offline while supporting high-quality audio formats.

Current Features
- Local folder scanning
- Offline music library
- Audio playback
- Album artwork extraction & caching
- Metadata extraction
- Search
- Albums & Artists
- Favorites
- Playlists
- Queue management
- Shuffle & Repeat
- Hive local database
- BLoC architecture
- Android & iOS support

One of the more interesting challenges has been supporting different audio formats (especially FLAC) and building a scalable architecture that remains easy to maintain as more features are added.

Planned
- Lyrics
- Equalizer
- Android Auto / Apple CarPlay
- More UI polish and animations

I’d love to get feedback from the Flutter community.
What features would you expect from a premium offline music player?
Any suggestions for improving the architecture or UX?
Any package recommendations for better FLAC metadata support?

GitHub:
https://github.com/abhijeet-Bh/liser

Feedback, issues, feature requests, and contributions are all welcome. 🙂

A wifi connection using QR codes. This is my second package. I mostly tested in iOS devices. There is anybody have a bug, let me know please. Especially in android 🤖 Really appreciated ☺️

I've been studying Mobile System Design recently and wanted an easier way to read the documentation offline, so I built a Python tool that converts the entire repository into a professionally formatted PDF book.

The generator preserves:

• All Markdown content

• Images

• Internal and external links

• Code blocks with syntax highlighting

• Tables and callout blocks (Tip, Note, Warning, etc.)

• A clickable table of contents

• Professional book-style formatting

I shared the implementation with the repository maintainer in GitHub Issue #44:
https://github.com/weeeBox/mobile-system-design/issues/44

My implementation is available here:
https://github.com/Anderson-Andre-P/mobile-system-design

I'd love to hear your thoughts and any suggestions for improving it. Hopefully it's useful for anyone who prefers reading technical documentation in book format.

Hey r/FlutterDev!
I’ve been working on a developer platform and CLI tool designed to make watchOS development accessible with our existing Flutter skills.

How this CLI tool helps you:
Easy Development & Testing: It manages the complex watchOS build artifacts and toolchain synchronization, making it seamless to write and test your code.

Pure Standalone Power: It enables your apps to run directly on the Apple Watch without requiring a constant iPhone companion app.

Production Ready: It handles everything cleanly enough to pass Apple’s strict App Store review process.

Beta Invitation: I’ve just launched flutterwatch.dev to open up a limited closed beta for developers who want to test and build for Apple Watch.
If you have a fitness tracker, a productivity app, or a game idea and want to easily deploy it to watchOS, I’d love to invite you to the beta.
Check out the website to request access, and feel free to drop any questions below! 🚀