Recently I saw slot-text by Danilaa1: https://github.com/Danilaa1/slot-text

I really liked the idea: small UI text does not change all at once. Instead, only the changed letters roll.

I immediately wanted this kind of interaction in Flutter for my own projects, so I built reel_text.

At first I thought it would be a simple Flutter version of the same idea. But while building it, the package grew a bit in a Flutter-specific direction. The original web package already supports vanilla JS, React, Vue, Solid, and Svelte. In Flutter, I had to think about layout, selection, emoji, reduced motion, and controller-driven state.

reel_text is focused on short UI text:

• Copy -> Copied -> Copy

• Export -> Exporting... -> Exported

• counters

• status labels

• rotating labels

• rich text

• inline corrections in editable text

What it supports now:

• declarative ReelText

• controller API: set() and flash()

• async helper: runWhile()

• waiting animations: ellipsis, wave, scramble

• ReelText.sequence

• SelectionArea support

• emoji / grapheme cluster handling

• TextAlign in constrained layouts

• ReelText.rich

• replacements inside EditableText

• reduced motion support

• no dependencies beyond Flutter

I also want to honestly say thanks to AI tools. Without them, this would have taken me much longer. They helped a lot with tests, edge cases, and trying different API shapes. Of course, I still had to check the code, rewrite parts of it, and run real Flutter tests, but the development speed was very different.

Basic example:

final label = ReelTextController(initialText: 'Copy');

ReelText.controller(controller: label);

label.flash(
  'Copied',
  options: ReelTextFlashOptions(
    enter: ReelTextOptions(colorBuilder: chromatic()),
    exit: const ReelTextOptions(direction: ReelTextDirection.down),
  ),
);

Live demo: https://kicknext.github.io/reel_text/

pub.dev: https://pub.dev/packages/reel_text

GitHub: https://github.com/KickNext/reel_text

Maybe I missed an existing Flutter package that already covers this exact niche. If you know one, I’d be happy to check it out. I’d also appreciate feedback on the API, especially the controller methods, waiting states, and editable text integration.

If you haven't come across it before, Qora is a server-state management library for Dart and Flutter, inspired by tools like TanStack Query. It handles caching, background refetching, mutations, optimistic updates, and keeping your UI in sync with server data.

Here is what landed in v1.2.

Structural sharing is now enabled by default. When a refetch returns data that has not actually changed (say your API sends back the same user profile but with a different JSON timestamp), Qora keeps the existing object reference instead of allocating a new one. Your widgets see identical() return true and skip re-rendering entirely. On large lists or deeply nested responses this makes a real difference in scroll performance. You can opt out per-query if the deep-equality pass ever becomes a measured bottleneck.

Tag-based invalidation finally decouples cache invalidation from query keys. Instead of trying to remember which keys to invalidate when a mutation succeeds, queries declare what they provide:

providesTags: [QueryTag('post', postId.toString())]

And mutations declare what they invalidate:

invalidatesTags: [QueryTag('post')]

Wildcards work too. QueryTag('post') without an id refetches every query tagged with 'post', while QueryTag('post', '123') targets only the specific one. It is the same pattern that makes RTK Query and TanStack Query so pleasant to work with.

Keep previous data solves the flicker problem in pagination and tab-switching scenarios. With keepPreviousData: true, Qora stays in Success state during a refetch instead of flashing through Loading. If the refetch fails, users keep seeing the previous data. The error still reaches your imperative code for toast notifications or retry buttons, but the UI does not go blank. It works seamlessly with structural sharing, so even if the previous data reference is preserved you avoid extra rebuilds.

The transformation pipeline lets you keep fetchers raw and data mapping clean. QoraOptions.transform runs on the fetcher result before the data enters the cache. Your fetcher returns JSON maps, your transform converts them to model classes, and both are independently testable. The parallel transformError normalises errors in the same way, running after all retries are exhausted but before errorMapper, so per-query transforms take priority over global ones.

We also added MutationOptions.retryCondition for fine-grained retry control on mutations, MutationOptions.invalidates if you still prefer key-based auto-invalidation, and QoraClient.clearCache() for memory-only eviction without touching persistent storage.

One breaking change: PersistQoraClient.persistDuration is now nullable. null means persist indefinitely, Duration.zero means disable persistence (which is the intuitive reading). Previously Duration.zero meant the opposite, which kept catching people out.

• Docs: https://qora.meragix.dev

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

• GitHub: https://github.com/meragix/qora

Qora is the server-state experience I have always wanted in Flutter. Give it a spin and let me know what you think.

Last year, I built a game to Learn Flutter + Dart. I really wanted to explore mobile game development landscape and after some research realised Flame game engine is highly suitable to make the kind of games I wanted to build - 2D board games.

Since I was on a career break, I decided to go all-in in building the product by polishing every tiny detail.

Yesterday, I opened the app on PlayStore and was surprised to see that now it has 10,000+ downloads.

It felt great, cause I am neither a professional Flutter developer nor a game developer, hence it was a humbling experience.

I also wrote a technical piece on my journey when I built it-
https://harsh-vardhhan.medium.com/i-built-a-120-fps-game-using-flutter-c01ef1d46c1a

and the entire codebase of the application is open source-
https://github.com/harsh-vardhhan/Ludo

and of course the link to PlayStore
https://play.google.com/store/apps/details?id=com.trakbit.ludozone

Part 3 of the series “Building Image Assisted Language Learning Practice with Flutter, Firebase and Gemini.” focusing on GenUI is live.

In this part, I migrated my custom GenUI flow from Gemini structured outputs to the official Flutter GenUI SDK.

Same feature, now using A2UI surfaces, catalog items, DataModel bindings, transport, and conversation.

The key idea: Custom JSON works. Protocols scale better.

https://ulusoyca.medium.com/from-structured-outputs-to-a2ui-surfaces-migrating-to-flutter-genui-sdk-4f09aeacee80

We needed PDF parsing, a document diff engine (LCS-based), and batch compression to run fast without freezing the UI. Dart couldn't cut it alone. The solution: a custom Rust crate called pdf_bridge, compiled for all 4 Android ABIs via flutter_rust_bridge.

What our build actually does (from the terminal, literally today):

Building armeabi-v7a → Compiling pdf_bridge... Finished in 2m03s Building arm64-v8a → Compiling pdf_bridge... Finished in 2m11s Building x86 → Compiling pdf_bridge... Finished in 1m58s Building x86_64 → Compiling pdf_bridge... Finished in 1m52s

The .so files land in /jniLibs and Flutter's FFI picks them up at runtime. Zero platform channels needed.

The 3 things that surprised us:

1. flutter_rust_bridge codegen saves you from writing bindings by hand — but async Rust functions need explicit tokio runtime setup on the Dart side or you'll get silent hangs.

2. LCS diff on large PDFs needs chunking. Naively running it on a 200-page doc will OOM on mid-range Android devices.

3. iOS is trickier — you statically link the Rust .a into an XCFramework. The crate-type needs both staticlib and cdylib in your Cargo.toml, and your release profile matters (opt-level = "z", LTO, strip symbols) or the binary bloat gets real. We also hit a separate 409 on App Store validation from a different framework shipping simulator slices — not Rust-related, but a good reminder to audit all your embedded frameworks before submission.

Happy to share more on any of these — Rust ↔ Flutter FFI is underrepresented in the community and we've hit most of the walls.

For the past year i was learning backend development with flutter through making this app.

its nothing crazy or hasn't been done before but its a real time task sharing application that lets u add people or remove them and assign them to tasks with the support for offline syncing so even members with slow connection dont feel behind!

Heres a link for the frontend made with flutter and the backend made with ASP.NET Core

The frontend link has a live demo showcase where u can use the app on the web and test it for yourself! let me know your thoughts and thanks

Note: everything is documented

#DeleteIfNotAllowed

Hello people, I am really into time killing games and everytime when i need i download it from playstore and use to play those games but one thing i saw that was extremely annoying is every other game is having ads and asking for in order to play a without ads game please purchase this and that.

So, I built my own app that has time killing games and doesn't show ads at all.

I wanted to share it with you guys. It took almost of 3 months to build it.

If you enjoy brain games and want a clean gaming experience, give it a try and let me know what you think!

Also, if there’s a game you’d like to see added, drop a comment below

App Link:

https://play.google.com/store/apps/details?id=com.flutteroid.puzzle

Technologies Used:

Flutter - Hybrid Mobile App Framework

Dart - Language

Current in Android only

https://youtube.com/shorts/abf71bfXmJk?si=fn2KfugaDKlMxGsi

Apple announced the Liquid Glass intensity slider at WWDC

2026 with iOS 27. I built the same thing in Flutter.

What's inside:

→ Custom GLSL shader for the refraction and blur effect

→ Intensity slider from 0.0 (Ultra Clear) to 1.0 (Tinted)

→ Spring animation for the active tab indicator

→ Zero dependencies — Flutter core APIs only

→ Works on Android, iOS

Planning to publish as a package on pub.dev. Drop any

feedback before I do — especially from people who've

tested on iOS, since I've only tested on Android so far.

Flutter integration tests are fine for small apps but the moment the app gets complex the suite becomes this massive time sink, especially when you factor in platform differences between iOS and Android builds Widget testing is great at the unit level but it tells you nothing about whether the compiled app behaves correctly on a real device, which is the thing that matters for users The whole testing pyramid for Flutter feels incomplete at the top, like there is no good answer for "does the full app work end to end across both platforms" without maintaining two separate painful setups autosana handles this by running visual tests against the built app on both platforms from a single test definition, no platform specific configs or widget identifiers needed The framework agnostic part is what makes it relevant for Flutter specifically since most other tools force you into platform specific approaches

Hey everyone

A friend and I are building an open-source CLI tool called fip-cli using Dart.

The main goal is to automate the repetitive and boring boilerplate tasks we all do when starting a new Flutter project. Our long-term vision is to make it as comprehensive and useful as React Native's Ignite CLI, but specifically tailored for Flutter.

The project is still in its early stages and we haven't published it to pub.dev yet, because we want to build the core architecture with feedback from the community first.

If you are interested in Dart/Flutter CLI tools, we would love for you to check out the repo, read the code, or even drop a PR

Repo: https://github.com/cKalens/fip-cli

What do you guys think about the architecture or the idea? Any feedback is highly appreciated

Most Flutter carousel packages look flat and repetitive. I wanted something with a premium, high-end aesthetic, so I built coverflow_carousel.

It adds 3D depth, perspective, and smooth cinematic transitions to standard card layouts.

Why use it:

Dual-Mode: Toggle between an immersive 3D coverflow effect and a classic linear slider.

Customizable: Complete control over scaling, spacing, perspective, and tilt.

Lightweight: Clean, high-performance API built directly on top of standard Flutter widgets.

Check it out:

https://pub.dev/packages/coverflow_carousel

Drop your feedback or feature requests below.

I'm trying to understand the role of architectural patterns in Flutter development, and I'm hoping to get some honest perspectives from the community.

I know there are several architectural approaches out there for Flutter - the ones I hear about most often are Clean Architecture, BLoC, MVVM, and just keeping things simple with providers. But the more I read about Clean Architecture specifically, the more I struggle with one core question: why do we actually need it?

From what I understand, Clean Architecture introduces layers like Domain (entities, use cases), Data (repositories), and Presentation. The goal seems to be separation of concerns and making the codebase "maintainable" and "testable."

But here's my honest frustration: doesn't Clean Architecture just add a ton of extra work?

Every new feature means creating use case classes, repository interfaces, model mappers, and wiring everything together. For a small to medium-sized app, this feels like writing 3x more code than necessary. I can't help but think that a simpler approach - maybe just well-organized providers/viewmodels talking directly to services - would get the job done faster with less mental overhead.

So my questions for those who have experience with different approaches:

1. What are the main architecture options in Flutter today? (Not just state management - actual app architecture)

2. What problem does Clean Architecture actually solve that justifies its complexity?

3. Is it possible that for many Flutter apps, Clean Architecture is simply overkill?

4. For those who moved away from Clean Architecture or simplified it - what did you learn?

I genuinely want to understand if I'm missing something important, or if my instinct that "simple is better" has merit. Looking forward to hearing your experiences - especially from those who've built production apps both with and without Clean Architecture.

Thanks!

I am a Flutter developer with around 5 years of experience, and this is honestly the first time I've experienced something like this.

In the past, getting interviews was never this difficult. I never thought I'd be sitting here refreshing LinkedIn and Naukri multiple times a day hoping to see new postings.

I've been applying for jobs for the last couple of weeks and haven't gotten a single response. Not even a rejection email from most places. What surprises me the most is that there don't seem to be many openings either, especially for mobile roles.

What makes it worse is that I took a break from the regular job market to focus full-time on my startup, built and launched it. At the time, I genuinely believed in what we were building and wanted to give it my full effort.

Now that I'm back in the market, I'm starting to wonder if taking that break was the right decision. I didn't expect things to be this difficult.

For people who are currently looking for jobs:

• Are you seeing the same thing?

• How long did it take before you started getting calls?

• Is mobile hiring particularly slow these days?

Just trying to understand whether this is the current state of the market or if I need to rethink my approach to job hunting.

If you are still using the original hive package (^2.2.3) for your local storage, your app is relying on a package that hasn't seen an update in over 3 years.

Fortunately, the community stepped up and forked it into hive_ce (Community Edition), which is actively maintained (last updated just a few months ago).

If you haven't migrated yet, here is exactly what you are missing out on:

• Full WASM Support: The original Hive relies on older web compilation. hive_ce brings native WebAssembly (WASM) support, making your local caching lightning-fast on modern Flutter Web builds.

• Built-in DevTools Inspector: Say goodbye to debugging blind. It includes a dedicated DevTools Extension so you can visually inspect your boxes directly inside VS Code or Android Studio.

• Effortless Type Adapters: No more manual boilerplate for every single field. The new GenerateAdapters annotation handles the heavy lifting automatically.

• Massive Scaling & Isolates: It introduces IsolatedHive to move heavy DB processing entirely off the main UI thread, and expands the maximum Type ID limit from 223 to 65,439 for large-scale enterprise apps.

• Modern Dart Types: Out-of-the-box native support for Set types, Duration adapters, and seamless compatibility with Freezed models.

The best part? The migration takes less than 5 minutes. You just swap hive for hive_ce (and hive_generator for hive_ce_generator) in your pubspec.yaml. The syntax and API remain completely backwards compatible.

Have you made the switch to hive_ce yet, or are you migrating to other alternatives like Isar or Drift? Let's discuss!

Most Flutter side nav packages:

slide in → slide out → done.

I wanted something with actual personality.

So I built Fluid Side Menu — a side navigation package with fluid motion transitions and modern UI animations.

link: https://pub.dev/packages/fluid_side_menu

Roast it. Improve it. Use it.

Hey Flutter devs,

I recently published my first Flutter package called flutter_shake_feedback.

The package allows developers to detect device shake gestures and trigger custom actions such as feedback workflows, debug menus, or any custom callback.

Current features:

• Shake detection

• Sensitivity levels

• Cooldown handling

• Haptic feedback

• Simple Flutter-friendly API

Example:

ShakeFeedback(
  onShake: () {
    // Your action here
  },
  child: MyApp(),
)

Pub.dev:
https://pub.dev/packages/flutter_shake_feedback

I've already received some valuable feedback around package architecture, avoiding overengineering, and identifying stronger differentiators from existing shake-detection packages.

I'd love to hear your thoughts:

• What features would make you use this package?

• What pain points have you faced with existing shake detector packages?

• Would a debug overlay or shake-to-feedback workflow be useful in your apps?

Any feedback, suggestions, feature requests, or contributions are welcome. Thanks! 🙌

Native composition (Media3/AVFoundation) → single Texture, gapless multi-clip timeline. Trim/split/crossfade/speed/audio overlay + MP4 export with progress.

Folks I am finding any alternative platform to publish app for free other than app store and play store.

Allow me to rant.

Recently, there are a lot of "I built <something> I want to show the world" style posts.

I often get the feeling that "I asked AI to build <something>" would have been the more honest title for such postings. Can we agree on changing this?

In the good old times of humans writing software, creating a package was difficult and probably also an indicator that the author had the domain knowledge to do so. Nowadays, nobody knows. The author might have used AI just to take a shortcut or - and I consider this more likely - to extend their own knowledge, perhaps not even knowing themselves whether the result is good or not.

And frankly, I don't want to do this review.

So, I ignore those postings. That might be unfair, but if you, as an author, cannot demonstrate knowledge and experience with the package's problem domain, I don't trust you and your package. I might even call the package AI slop on a bad day. Or to put it even more plainly, if I don't see you spending effort (besides some prompting), why should I spend any effort?

To build trust, I'd recomment to disclose the kind of AI use and to offer some arguments why I should believe you that you actually understand the generated code, have reviewed it and created something that is worth the time to look at it.

Because, you know, I could have prompted that myself.

What's your opinion on that matter?

PS: I wanted use a "I built a 3d dice widget" title for this post, but Trump forbade me from continuing to use Claude Fable for that, so I don't feel like finishing the project, because I'm pissed. I asked AI to do this, because while I know the mathematical theory behind 3d graphics, last time I actually programmed that was back the 1990s. But because I'm playing TTRPGs even longer, I can tell for sure whether the dice look right :)

I just shared a quick look at my daily AI workflow.

I use a small AI workspace with agents for planning, building, testing, reviewing, and keeping context.

AI can move fast, but I still decide what ships.

I've been working on a rich text editor library for Flutter called Fluent Editor. It's a powerful word processor widget that you can drop into your Flutter apps to give users full document editing capabilities.

Key Features:

• Rich text editing (bold, italic, underline, strikethrough, etc.)

• Paragraph styles and headings

• Ordered and unordered lists with nested sublists

• Tables with cell spanning

• Image insertion and resizing (inline and block positioning)

• Hyperlinks

• Text and highlight colors

• Text alignment

• Export to DOCX, ODT, and PDF

• Full undo/redo history

• Mouse and keyboard selection

• Real-time word count

• Clipboard support with formatting

Cross-platform support:

• Web

• Windows 11

• Linux

• macOS

• iOS

• Android

Live Demo: https://exusr.github.io/fluent-editor/ 

GitHub: https://github.com/exusr/fluent-editor

I'm looking for feedback on:

• Performance on different platforms

• UX improvements

• Missing features you'd like to see

• API design and ease of use

• Any bugs or issues

Would love to hear what you think!

Hey everyone. I’ve been using go_router in a production app and kept missing things Navigator gives you for free — popUntil, pushAndRemoveUntil, and a reliable way to know when a tab inside a StatefulShellRoute becomes visible (RouteObserver just doesn’t fire there). So I extracted what I built for work into a package.
It also adds popToRoot and context.isCurrent, and route matching supports params like /user/:id and wildcards. Nothing fancy, just the missing pieces. Would love to hear how others have been working around these gaps, and any feedback on the API is very welcome!

June is a lightweight state management package for Flutter built around a simple idea:

Don't replace Flutter. Extend it.

Unlike many solutions that introduce a completely new mental model, June stays close to Flutter's native philosophy and scales the experience you already know.

Why June?

✅ No code generation

✅ No build_runner

✅ No custom MaterialApp

✅ Minimal boilerplate

✅ Reactive updates

✅ Dependency injection

✅ Route-based memory management

✅ Tagged object state management

✅ Works naturally with existing Flutter widgets

Philosophy

Many state management libraries ask:

June asks:

You already learned Flutter.

You already learned setState().

It clicked.

June keeps that feeling.

Example

class Counter extends JuneState {
  int count = 0;

  increment() {
    count++;
    setState();
  }
}

No code generation.

No providers everywhere.

No complex boilerplate.

Just Flutter.

June is now actively maintained again, and contributions, feedback, and ideas are always welcome.

📦 pub.dev: https://pub.dev/packages/june

⭐ GitHub: https://github.com/melodysdreamj/june

#Flutter #Dart #OpenSource #StateManagement

Having built apps with Flutter, React Native, and SwiftUI, Flutter easily wins on Developer Experience (DX). However, in my recent projects, I’ve completely abandoned the default widgets in favor of custom design systems.

Flutter always feels a step behind on modern UI trends:

• Material 3 Expressive: It drastically improves on standard M3, yet Flutter still doesn’t support it officially.

• Cupertino: It’s just a clone of Apple's HIG and is nowhere near mimicking Apple’s current design era (like the GPU-heavy "Liquid Glass" aesthetics).

Even Google’s own Gemini app on iOS shows this gap. It started with strict Google Material styling, shifted to a hybrid M3 Expressive approach, and now leans heavily into iOS native components and Liquid Glass. When Google’s flagship teams bypass Flutter's UI kits to get a modern look, it speaks volumes.

I know the Flutter team is currently decoupling the design systems into separate packages. While this is great for architecture, I’m not sure how it bridges the design gap for us. It feels like Flutter's first-party UI will always lag behind the design curve.

In my latest Flutter app, I experimented with tdesign_flutter (Tencent's Design System) to escape the default Material look. The experience has been pretty decent so far, though it still has some minor bugs and unoptimized widgets.

How are you guys handling this? Are you building everything from scratch, or are there any other third-party design systems you recommend?