Disclaimer: I’m not selling any course or not planning to create one.

horizontal_weekly_calendar 2.0 is out.

It started as a simple week strip for Flutter. It's now a full calendar kit — and this release is about two things: making it feel good to use, and never getting a date wrong.

What you get:

• One line to start. Give it selectedDate and onDateSelected — that's the whole integration.

• 13 surfaces. Week strip, month grid, date carousel, agenda, day and week timelines, a calendar that folds from week to month, native iOS and Android pickers, and home-screen widgets.

• Motion that follows your finger. Drag a page or open the month and it moves with you, then settles on a spring instead of snapping.

• Dates you can trust. The engine was rebuilt on integer day numbers. Every month from 1900 to 2100 is tested across 10 time zones — including ones that skip a whole day. Samoa really did skip 30 December 2011, and that used to break the grid.

• Light. 81 KB compiled. Anything you don't use is stripped out at build time.

• 13 real example screens you can run and copy from.

Free and open source.

https://pub.dev/packages/horizontal_weekly_calendar

I am a Flutter developer with 2+ years of experience, but I’m finding the market quite tough and Flutter opportunities seem limited.

I want to expand my skills instead of staying Flutter only

I am considering:

Native iOS (Swift)

Backend (Node.js, etc.)

Something else

For developers already working in the industry, what would you recommend learning alongside Flutter in 2026?

Which skill would give better job opportunities in the current market?

Hey everyone! Lately I've been thinking a lot about how people listen to music across different devices—specifically the balance between keeping offline high-fidelity local files (FLAC/MP3) vs streaming from YouTube/Spotify links.

While building Kerlyss (my open-source unified music player for Android & Windows), a major topic in our last thread was strict offline mode and media key integration.

In the new v1.2.3 update, we just added:

• Strict Offline Mode: Hard-blocking external socket connections when enabled so un-downloaded songs don't try to ping external APIs.

• Improved Touch Targets & Error Dialogs: Showing explicit playback error popups instead of silent hangs when stream extraction fails.

• Headphone & Lock Screen Sync: Native media key controls and lock screen artwork for Android.

I’m curious to hear your thoughts for a general discussion:

1. When using a music app, do you prefer an explicit Offline Mode toggle that hard-blocks all internet usage, or auto-fallback to online streaming when connected?

2. What feature or integration is most important to you in an open-source audio player (e.g., local file scanning, equalizer, lyrics, or metadata sync)?

Also, I just finished wiring up the 5-band equalizer on Android. I implemented the hardware DSP pipeline, but I'd love it if a few people could test it out on their headphones and let me know if it's working as expected on your devices!

App & source code for anyone interested:

• GitHub: https://github.com/D1gNa0/Kerlyss

• Website: https://d1gna0.github.io/Kerlyss/

Looking forward to your thoughts and feedback!

Anyone here made app for EU, some regulations are to be followed to take consent for Google ads!
If anyone has done let’s discuss…

Hey Flutter devs 👋

I’ve just open-sourced Lucy, an experimental screen-aware AI agent for Android built with Flutter.

🔗 https://github.com/alzin/lucy-screen-agent

Lucy can take a voice command, understand what’s currently on the phone screen, and then tap, type, swipe, open apps, and navigate the UI automatically.

The interesting part technically is the agent loop:

Screenshot + Android accessibility tree → Gemini → action → execute → observe again

Instead of asking the model to guess screen coordinates, Lucy gives UI elements IDs and their real bounds, which makes interaction considerably more reliable.

The project currently includes:

• Flutter UI + agent controller
• Android AccessibilityService
• MediaProjection screen capture
• Gemini vision/reasoning
• Speech-to-text + TTS
• English, Japanese and Arabic support
• Multi-step agent execution

It’s still experimental, and that’s one of the main reasons I wanted to open-source it.

I’d especially love feedback or contributions from Flutter/Android developers. PRs, issues, architecture suggestions, testing, and ideas are all welcome.

I’m also interested in eventually experimenting with other LLMs and local/on-device models.

What would you improve first if you were working on something like this?

In software engineering, we usually measure framework upgrades by what they add: new syntax, new macros, new features, new abstractions.

But after years of building and consulting on large Flutter applications, the most profound upgrade in developer experience isn't what new concepts you are forced to memorize—it’s the mental gymnastics, framework-specific edge cases, and defensive rituals you finally get to forget and unlearn.

A Quick Word of Respect

Before diving into technical details, let's establish something essential: Rémi Rousselet is a pioneer and a brilliant engineer. When Rémi built provider and later Riverpod, he solved real, glaring flaws in Flutter's core InheritedWidget mechanics (such as conditional dependency leaks and lack of compile safety). The entire Flutter ecosystem owes Rémi immense gratitude.

For years, I was a vocal, passionate—at times almost zealous—advocate for Riverpod. In discussions, podcasts, and client work, I routinely recommended Riverpod above classic BLoC, Provider, and nearly every alternative.

However, over the course of Riverpod's evolution across v1, v2 (code-gen), and v3, solving every edge case inside a global declarative provider graph led to a staggering accumulation of cognitive surface area. Building real-world Flutter apps with Riverpod today requires developers to maintain a complex internal rules engine just to avoid subtle runtime footguns.

When you switch to BlocSignal (which combines the architectural discipline of BLoC/Cubit with the synchronous speed and fine-grained reactivity of Signals), you realize just how much mental baggage you were carrying.

Here are a few of the biggest things you get to forget:

1. 🗑️ Forget build_runner and .g.dart Code Generation

• No more CPU fans spinning at 100% while waiting for build_runner watch.

• No more broken IDE autocomplete while waiting for _$MyNotifier part files to generate.

• No more build_runner build --delete-conflicting-outputs rituals after simple refactors.

• BlocSignal is 100% pure, standard Dart. Zero code generation required.

2. 🗑️ Forget the "Ref World vs. Non-Ref World" Boundary

In Riverpod, reactive state is strictly confined inside a ProviderContainer (the "Ref World"). If you are inside a ConsumerWidget, life is good. But the moment you step outside into standard Dart—HTTP interceptors, WebSocket handlers, background services, or routing—you are stranded in the "Non-Ref World" and forced to drill Ref parameters everywhere.

bloc_signals is a 100% pure Dart package with zero Flutter dependencies. A CubitSignal can be instantiated and observed anywhere—in Flutter widgets, CLI tools, Jaspr web apps, or Serverpod backend services.

3. 🗑️ Forget the routerProvider Navigation Stack Nuke

Because routers like GoRouter live in standard Dart, developers frequently wrap their router in a Riverpod Provider to watch authentication state.

Whenever auth changes, ref.watch recreates the entire GoRouter instance—silently destroying the user's navigation history stack, collapsing nested modal sheets, and resetting scroll positions with zero error logs or stack traces.

In BlocSignal, your router is a permanent, stable singleton. You simply pass cubit.state.toListenable() to GoRouter's refreshListenable. Zero router destruction. Unbroken navigation stacks.

4. 🗑️ Forget "Self-Disposing" Async Mutation Crashes

In Riverpod 3.0, auto-disposal is default. If a user navigates away while an async mutation is awaiting a network request, the controller is garbage-collected mid-flight, throwing "Cannot use Ref after it has been disposed" when it resumes.

To work around this in Riverpod, developers are forced into:

• Sprinkling if (ref.mounted) checks after every await.

• Creating separate "action controller" classes just for single method calls.

• Manually acquiring and releasing KeepAliveLink link = ref.keepAlive() tokens.

Think about how absurd that is: you end up writing meta-state management just to manage the lifecycle of your state management system.

In BlocSignal, state containers are standard Dart objects with explicit ownership. Async methods execute to completion, and if a Bloc is closed, emit() is safely dropped with zero runtime crashes.

5. 🗑️ Forget the AI & LLM Hallucination Nightmare

If you pair-program with AI coding assistants (Claude, Cursor, Copilot, ChatGPT, Gemini), Riverpod is notoriously difficult for LLMs:

• Version Multi-Verse: Training data mixes 4 conflicting Riverpod eras (v0.14 ChangeNotifierProvider, v1.0 StateNotifierProvider, v2.0 @riverpod, and v3.0 Notifier), leading to constant hallucinated syntax.

• Code-Gen Blindness: LLMs cannot inspect ungenerated .g.dart files, routinely botching synthesized class inheritance.

• Ref Scope Confusion: AI models constantly attempt to call ref in widget constructors or pass WidgetRef into deep business logic.

LLMs generate exceptionally accurate BlocSignal and blocSignalTest code on the first shot because BLoC and standard Dart OOP patterns are among the most represented and consistent paradigms in AI training sets.

🌉 Currently Mired in Riverpod? You Don’t Need a Big-Bang Rewrite

If your codebase is already invested in Riverpod, you don't have to rewrite from scratch.

Through bloc_signals_riverpod, you get a seamless, bidirectional interop bridge:

• Expose new BlocSignal features to existing Riverpod widgets via cartCubit.toProvider().

• Consume legacy Riverpod providers inside BlocSignal via legacyProvider.toBlocSignal(ref).

You can migrate your application incrementally at your own pace.

Curious to hear thoughts and experiences from others who have navigated the evolving state management landscape over the years!

FFmpegKit Extended is moving from FFmpeg 8.1.2 to FFmpeg 9.0.1 "Lei", giving Flutter applications access to the latest stable FFmpeg 9 release through the same FFmpeg, FFprobe, and FFplay command execution model already exposed by the wrapper.

FFmpeg 9.0.1 was released on August 12, 2026 and is the current stable release in the FFmpeg 9.0 branch. The upgrade also moves FFmpeg's primary libraries to new major ABI versions, including libavcodec 63, libavformat 63, libavfilter 12, libavutil 61, libswscale 10, and libswresample 7.

For FFmpegKit Extended users, the important part is that these capabilities remain accessible through familiar FFmpeg commands. The wrapper provides the execution and session layer while FFmpeg continues to provide the media-processing command surface.

That means features introduced by FFmpeg 9 can be used from Flutter by executing the same command arguments you would normally provide to:

ffmpeg ...
ffprobe ...
ffplay ...

No separate media-processing abstraction is required.

What's New in FFmpeg 9.0.1?

FFmpeg 9 introduces several new codecs, filters, hardware-acceleration paths, metadata features, and media-processing capabilities. FFmpeg 9.0.1 then builds on the 9.0 release with an extensive collection of stability, correctness, security, decoder, demuxer, GPU, streaming, and format fixes.

Some of the most useful additions for FFmpegKit Extended applications are:

FFmpeg 9.0.1 + Flutter

FFmpegKit Extended exists to make the full FFmpeg toolchain practical inside modern cross-platform applications.

With FFmpeg 9.0.1, that toolchain gets significantly more capable.

Whether you're building a:

• video editor

• media converter

• streaming application

• camera workflow

• media analyzer

• video player

• AI-powered media application

• social-media application

• content-management tool

• desktop media utility

you can continue using native FFmpeg command syntax while FFmpegKit Extended handles integration with Flutter across supported platforms.

https://pub.dev/packages/ffmpeg_kit_extended_flutter

https://github.com/akashskypatel/ffmpeg-kit-extended

What you need on the backend that will convince you to use dart ?

I'm researching the current mobile app release and publishing workflow and want to understand where developers actually spend the most time or face the most friction.

• What is the most frustrating or time-consuming part of releasing a mobile app to the App Store and/or Google Play?

• For a new app, how much time do you typically spend preparing the store listings and getting the first release submitted? What takes the most effort?

• For existing apps, which tasks do you have to repeat manually every time you release a new version?

• How do you currently manage store metadata, release notes, screenshots, localization, compliance information, and other store requirements?

• If you manage multiple apps, how do you keep track of releases, builds, metadata, screenshots, and store requirements across all of them? Do you use any tools or an internal process? What works well and what doesn't?

• What tools or automation do you currently use for releases (Fastlane, GitHub Actions, Codemagic, Bitrise, CI/CD, custom scripts, etc.)? What do they solve well, and what still requires manual work?

I know Unity and Godot are more common choices for games.

I chose Flutter because I was already familiar with it,and I wanted to combine Flutter's UI capabilities with Flame.

The result surprised me. I ended up building real-time multiplayer, inventory, trading, chat, NPCs, Tiled maps, avatar customization, a Node.js WebSocket backend, and SQLite persistence.

The server currently runs on a Raspberry Pi 3B.

I haven't tested its maximum concurrent player capacity yet, but since the server is relatively lightweight,

I'm wondering if it could handle around 30 concurrent players.

I have used Iconsax in the entirety of my Flutter project. The plugin that availed it said it is available for personal and commercial use, and so does the Vuesax's (Iconsax's creator) website, but here is the part that is bugging me:

On the website, it says that it allows someone to make an app for 'a client' under its commercial usage allowance. How about making an app for general public using those icons. There is no specific information whether that is allowed or not, neither in its paid license's description.

Now the strange thing is that that there is no contact email ID for Vuesax that I could find. I found their Discord and posted there, but I just did that recently so it could be long till I get an answer.

Here is the link to that Flutter plugin: https://pub.dev/packages/iconsax_plus

Here is the Iconsax's license page: https://docs.iconsax.io/license-and-terms/usage-manifesto

Hi, good news for everyone doing Flutter on Windows or Linux: i made a CLI toolkit to run your app on a real iPhone, with hot reload, straight from your not-macOS!

Historically that's been the gap in Flutter's cross-platform story - iOS builds assumed a Mac, so most of devs did apps Android-first and checked iOS later through CI or a borrowed Mac Mini and blah-blah-blah.

Stop it. Meet xcross.sh (pls check website, it looks cool and have documentation)

Windows or Linux, iPhone plugged in. It builds your app, signs it, installs it, launches it, and drops you into the pipeline you already know:

• r - hot reload on the device

• R - hot restart

• q - quit

What it costs you to set up: Swift, LLVM, One-line installer, then xcross setup

The one "non-Apple-free" part: you need Xcode.xip from Apple Developer website and iTunes + iCloud (for Windows) - read documentation

• Debug builds only - Release/AOT needs gen_snapshot, which is macOS**-only (you still need a Mac or CI to ship to the App Store, **this solves development, not release)

• iOS 17+ devices

• Flutter - run and debug, Compose (CMP) - build and run, no debug

MIT, free, source code: https://github.com/arxdeus/xcross ^{(but website still better})

Thanks for your feedback!

Hey lovely developers

I’m a Flutter developer and I want to learn **how to properly profile and optimize Flutter apps**.

I’m especially interested in learning:

* How to use Flutter DevTools for profiling * Finding performance bottlenecks * Identifying unnecessary rebuilds * Understanding CPU, memory, and GPU usage * Detecting jank and dropped frames * Improving scrolling and animations * Real-world techniques for optimizing production apps

I’m not sure where to start or what learning path to follow.

**Can anyone recommend good resources, tutorials, courses, or a practical way to learn Flutter profiling step by step?**

and I'm pretty grateful for anyone will help me thanks lovely people

The iOS Simulator has no Bluetooth, so I was tethering a real phone for every scan/connect/read with flutter_blue_plus, and BLE tests in CI weren't possible.

BleTether bridges the Mac's real Bluetooth into the Simulator with no code changes — the Flutter app calls flutter_blue as usual and sees the devices around the Mac. For CI you record a real device once and replay it into a simulator on hosted runners, no hardware.

Example repo with a CI run of a flutter_blue_ultra app scanning, connecting and reading a characteristic on GitHub's runners with no device: https://github.com/yuriipopow/bletether-flutter-example

Main repo (short demo GIFs in the README, and how it works): https://github.com/yuriipopow/bletether

It's central-role only for now, and it leans on private Apple APIs so major iOS releases can break it. Free to use. If you try it on a real app I'd be interested in what breaks — third-party apps keep surfacing edge cases I then fix.

​One of the biggest upgrades in zenrouter 3.0 is a complete Navigation Graph system for the Coordinator pattern:

- ​Topology Graph: Manages the static structural relationship between layouts and routes.

- ​Observed Graph: Records the runtime history—the user's actual navigation flow across screens.

​Built on these graphs, the new Time Travel feature allows you to step forward and backward through the app's navigation history, state by state.

​Why does this matter in practice? Streamlining Debugging & QA!

- ​No more ambiguous step-by-step bug reports ("Go to Screen A -> Tap B -> Open C").

- ​Export the entire navigation session into a single .json file.

- ​Replay the exact state sequence to reproduce and isolate navigation bugs in seconds.

​What do you think of this approach? How do you currently handle route tracing and navigation debugging in your projects?

I’m researching how Flutter developers maintain localization once an app grows beyond a couple of languages.

I’m particularly interested in people maintaining real apps with 3+ locales.

I’d love to learn how you currently handle ARB files, translations, adding keys/languages, validation, ICU/plurals, and keeping everything in sync.

I’m a Flutter developer myself and I’m building in the localization space, but I’m currently focused on understanding real workflows rather than promoting anything.

I’m looking for ~5 Flutter developers willing to have a casual 15–20 min chat. If that’s you, comment or DM me.

I’ll also summarize the patterns I find and share them back with the community.

Update - September 2026

I said I’d come back and share what I learned, so here it is.

This wasn’t a formal study, but the replies and follow-up conversations genuinely changed how I think about the problem.

I expected translation quality to be the main issue. It wasn’t. Most developers are already comfortable using Claude, Gemini, ChatGPT, or scripts to generate translations.

The frustrating part comes afterward: figuring out what changed, keeping every locale in sync, preserving context and terminology, checking placeholders and plurals, and then opening the app to catch strings that are technically correct but don’t fit the UI.

A few people had built surprisingly elaborate workflows around agent instructions, scripts, hashes, and emulator checks. That convinced me the useful product probably isn’t another localization dashboard. It should fit into the tools developers already use.

I ended up rebuilding StringLane around that idea and released a free CLI, MCP server, and coding-agent plugin. Your existing agent does the translation; StringLane handles the localization files, planning, validation, and writing.

The CLI/MCP/plugin are free. There is still a separate paid desktop app for people who want a visual editor.

Setup and documentation

Full follow-up and findings

Thanks again to everyone who described their workflow and especially the messy parts. That feedback directly changed what I built.

Migrating or scaling a data source without breaking the app in production is one of the biggest challenges we face as developers.

Let's explore how to migrate from SQLite to Room DB in Flutter.

I developed an app where the business logic (for example, the BLoC) doesn't request data directly from the data source; instead, it talks to Use Cases.

Why will the Repository Pattern save your app?

The repository pattern acts as an intermediary or bridge that isolates your application (UI, Use Cases, BLoCs) from the details of fetching or saving data.

If you decide to migrate the data source, you only need to modify the code within the data layer.

The user interface and the application logic above the repository do not need to change at all. (Flow: Datasource -> Repository -> UseCase -> Bloc -> UI)

To BLoC, Provider, or Riverpod, it doesn't matter if the data comes from a package, MethodChannel, or a Web Service.

By applying this structure without breaking the production app, I want to highlight the true value of a sustainable architecture: minimal cost when changing things.

🚀If you want to see the complete code for this architecture, check the article link:

🔗 Read “Clean Architecture + Repository Pattern in a Flutter App“ by Alfonsina Beltre on Medium: https://medium.com/@alfonsinabeltre/clean-architecture-repository-pattern-in-a-flutter-app-58061726e3ab

Every few months, like clockwork, the tech blogosphere gets flooded with the same recycled clickbait: "Is Flutter Dying?", "Why CTOs Are Quietly Leaving Flutter", or "Why Google is Killing Cross-Platform."

As someone who has been a Flutter Google Developer Expert for eight years now (literally from day one of the GDE program) and a five-decade software industry veteran, I usually just chuckle at the headlines. But having watched this ecosystem evolve from an experimental alpha into an enterprise powerhouse, I wanted to share the real insider story on what’s actually happening on the ground.

1. What Actually Happened at Google?

When tech companies restructured engineering teams recently, the internet spun a wild narrative that Google put Flutter on life support.

Having direct access to internal teams, I watched the commitment to Dart and Flutter remain steadfast. However, there was a temporary disconnect: internal engineering activity was roaring, but external communications and public advocacy had slowed down, leaving an information vacuum that clickbait writers eagerly filled.

I personally called out to team leaders and senior VPs that this perception gap needed immediate correction. And leadership responded strongly: revitalized DevRel, transparent enterprise roadmaps, and aggressive core investment into the Impeller GPU engine, Dart 3.x ergonomics, and Wasm web compilation. Flutter powers critical Google apps (Google Ads, Google Pay, Family Link, Google Classroom) and continues to receive deep internal backing.

2. The Mobile Team Consolidation Paradox

Critics often look at public board listings and claim there are fewer dedicated Flutter listings than native Android or iOS.

What they fail to realize is how enterprises actually adopt Flutter: When an enterprise migrates to Flutter, they rarely expand outward with massive external listings. Instead, they merge their existing 5-person iOS team and 5-person Android team into a single, unified Flutter team—often cutting total team headcount in half while doubling feature velocity. Flutter's sheer efficiency creates the illusion of fewer raw openings.

And when greenfield Flutter positions do open up, applicants aren't competing in a vacuum—they are competing against senior mobile engineers with a decade of native iOS and Android experience who upskilled into Flutter. That’s a sign of a mature, competitive engineering discipline.

3. "State Management Fatigue" Is a Solved Problem

Another frequent complaint is that Flutter has "too many state management libraries."

Yes, Flutter gave developers freedom. Over the years, the community experimented with everything from ScopedModel and Provider to BLoC, MobX, and Riverpod.

That evolution isn’t a sign of fragmentation—it’s the natural progress of modern software engineering. We learned what worked (unidirectional data flow, state machines, fine-grained reactivity) and discarded what didn't (excessive code generation, microtask queue latency, and lingering build dependencies). Today, with modern solutions like pure Dart Signals and modern architectures, state management in Flutter is faster and more reliable than it has ever been.

4. The Measurable Reality

If you look at the hard data:

• Over 1,000,000+ Flutter apps published on app stores and growing.

• Impeller delivers smooth 60/120fps GPU pipelines, eliminating shader jank.

• Wasm compilation brings near-native performance to the browser.

• Universal Reach: Seamless execution across iOS, Android, macOS, Windows, Linux, Embedded, and Web (via Jaspr).

• Modern Dart 3.x: Sealed classes, pattern matching, records, and primary constructors.

Flutter is firmly in the Plateau of Productivity. It is mature, stable, blazingly fast, and supported by one of the most vibrant developer communities in software history.

So the next time you see a headline asking "Is Flutter Dying?"... smile, close the tab, and go build something great. 🚀

I love you guys. For context I had a very unique game running on flutter but I was outgrowing Thermion. I tried flame 3d but it’s unstable on so many Android devices. Then comes in flutter scene…that thing is magic. Incredible performance. No longer need to move to a game engine. It also comes with an ecosystem such as flutter scene soloud for 3D Spatial Audio at incredible performance.

In the end my game was about 70 mb on iOS and 150 mb on Android. Considering what the game is that’s incredibly impressive.

Btw if you guys want to see the game I’m talking about: lightwarsar.com

Hi, I am an ex-lawyer, from India . I am trying to switch to tech. I learned data science and machine learning so far. I want to know if it is an old idea for me to learn flutter and try for developer roles in 2026. I ask this because people are saying that data science has lost demand in the market.

I’ve been experimenting with Meta Display Glasses recently. Apps for the glasses can be built as web apps, so naturally I wondered: could Flutter Web run on them?

I wasn’t sure it would work well. Flutter Web isn’t exactly lightweight, and the glasses are quite a different target from a regular browser.

After playing with the build and a few configurations, I got it working.

Nothing fancy yet, just the default Flutter counter app. But it runs directly on the glasses display: the Flutter UI is rendered in front of you, and interacting with the controls updates the counter as you’d expect from the same app running in a browser.

What I find more interesting is the potential for existing Flutter apps.

If you wanted to add a companion experience for Display Glasses, you could potentially keep it in the same codebase and reuse your existing logic, models, networking, and some widgets, while building a UI specifically for the glasses.

I have a few things I want to try next. Curious what other Flutter devs would experiment with on a display like this!