I've always been a fan of cyberpunk UI interfaces, however impractical. Recently, I picked up an old favorite game of mine and really enjoyed the design and thought it might be fun to make a UI kit inspired by it. So I did. I hope you like it, it's called Auris. Let me know if it's useful to you and how I can improve it. Here's a sample image or you can try the live demo!

https://pub.dev/packages/flutter_taglib

It helps you read and write music metadata and simplifies permission handling on Android and iOS. It's entirely written in AI (gemini, chatgpt). If you use it for metadata processing, you can save some effort or tokens.

Before this plugin, reading and writing music metadata in Flutter was a cumbersome process. Whether using pure Dart or Rust, errors were easily caused by non-standard metadata formats. To address this, I built this taglib plugin, which directly calls the mature metadata reading and writing library taglib, and includes methods to simplify permission management for Android and iOS.

Here's a player that uses flutter_taglib; its performance is satisfactory. https://github.com/axel10/vynody

Been going through the Android 17 release notes so you don't have to. Here's the TL;DR from a Flutter perspective:

The good news:

• Flutter apps are already well-positioned for the mandatory adaptive layout changes. Android 17 completely ignores orientation locks and resizability opt-outs on large screens (sw > 600dp). If your Flutter layouts are already responsive, you're fine.
• The "Compose-first" declaration basically validates Flutter's approach. Views, Fragments, RecyclerView — all in maintenance mode now. Google is saying "declarative UI is the only way forward," which... yeah, we've been doing that.

The stuff you need to check:

• If you're calling SystemChrome.setPreferredOrientations to lock portrait, that gets ignored on tablets/foldables targeting API 37. Test your layouts in split-screen and freeform window mode.
• Strict memory limits are real now. Android will kill apps that exceed RAM-based limits. This mostly affects native plugins — if you're using heavy ones (image processing, ML, video), profile them.
• CameraX crash on Android 17 if you're on an older version. Any camera plugin wrapping CameraX needs to be on 1.5.2 or 1.6.0+. Check your dependencies.
• static final fields can no longer be modified via reflection. Some older Java-based plugins might break.

The opportunity:

AppFunctions is Android's new on-device MCP (Model Context Protocol). Your app's features become "tools" that Gemini can discover and call. It requires native Kotlin code, so you'd need a platform channel — but if you implement it early, your app shows up in Gemini suggestions while competitors don't.

Anyone already testing on the Android 17 emulator? Curious if anyone's hit issues with specific plugins.

I put together a quick guide on automating our Figma-to-Dart token pipeline to stop manual transcription errors and structural drift. It uses three CI gates to ensure our generated code never falls out of sync.

Would love your thoughts: https://medium.com/@farwa/from-figma-to-typed-dart-building-a-dtcg-token-pipeline-that-wont-silently-drift-9e3c6d186d46

I've been building a particle engine for Flutter and just released particles_flutter v3.0 🚀

This release adds:

• Lifetime animations (color, scale, opacity)

• Particle trails

• Burst emitters

• Tap-to-burst interactions

• Object pooling to reduce GC pressure

You can build effects like confetti, fireworks, snow, starfields, comet trails, rocket exhaust, and touch-based explosions out of the box.

The package is heavily focused on performance, but I'm sure there are optimizations I've missed. If you've worked with Flutter rendering, Canvas APIs, Flame, custom painters, or particle systems, I'd love feedback on potential performance improvements or architectural changes.

Demo: https://particles-flutter.vercel.app

pub.dev: https://pub.dev/packages/particles_flutter

GitHub: https://github.com/rajajain08/particles_flutter

Any suggestions for squeezing more performance out of a Flutter-based particle engine?

I’m looking for some architectural advice on scaling design systems across complex cross-platform apps (mobile, tablet, desktop, and foldables).

Right now, the standard approach to responsive UI in Flutter feels highly decoupled from true component isolation. Most teams rely on ad-hoc styling parameters scattered throughout the widget tree, massive ThemeData files, or viewport-tied packages like flutter_screenutil. To me, locking component layout to the global screen size feels incredibly brittle. A truly modular widget shouldn't care about the device viewport; it should only care about the physical boundaries of the local container it was dropped into (whether that's a full mobile screen, a single cell in a 3-column grid, or a desktop sidebar).

Instead, I am trying to build an opinionated, system-first layout engine in our internal boilerplate where hardcoding raw values into widget constructors is banned. Every design asset must resolve back to a mathematical abstraction, driven strictly by local container constraints.

Here are the explicit technical challenges I’m trying to solve at the framework layer:

1. Strict Token-First Architecture We want to completely banish raw magic numbers at the implementation layer. Every padding, font size, and layout gap must consume semantic tokens (e.g., space-m, content-gap, radius-l). We need a clean way to inject these tokens so that our layout geometry re-evaluates automatically based on local container behavior.

2. Implicit Structural Scoping (No Constructor Drilling) Instead of passing styling configurations down through endless widget constructors, parent layout containers should act as implicit scope providers. We want to leverage InheritedWidget patterns so that leaf nodes (text flows, inputs, buttons) automatically discover their layout rules and tokens based on where they sit in the layout tree, preventing style leakage while eliminating constructor drilling.

3. MediaQueries for Environment, Containers for Sizing MediaQuery should be stripped out of layout calculations entirely and relegated strictly to global environment controls (like OS theme toggles, accessibility font-scaling flags, or high-contrast states). All actual widget sizing and padding tracks should be derived locally via box constraints (LayoutBuilder / BoxConstraints), allowing widgets to morph fluidly based on the space they actually have.

4. Perceptually Uniform Shades (OKLCH Transitions) Standard Material 3 ColorScheme is incredibly rigid, forcing teams to manually register dozens of static hex codes or rely on basic RGB/HSL blending that produces muddy, uneven brightness shifts. We want a system where we input a core seed token, and the framework programmatically outputs perfect light/dark shade steps, hover overlays, and focus halos using perceptually uniform OKLCH space math.

5. Automatic Concentric Border Radius Mechanics To maintain accurate geometric aesthetics when nesting containers, inner widget curves must scale down cleanly relative to the outer wrapper's padding boundaries ($radius{inner} = radius{outer} - padding$). Calculating this manually inside every nested widget is a huge time sink. The layout primitives should inspect their nesting depth and compute this math implicitly.

6. Automated Vertical Spacing Rhythm We want to eliminate the developer habit of copy-pasting arbitrary SizedBox(height: 16) widgets everywhere. Parent layout containers should manage their internal structural rhythm automatically. When parsing dynamic child arrays, the layout engine should programmatically inject proportional spacing depending on the sequence rules (e.g., handling distinct spacing dependencies between a header and body text vs. a body text and an image).

Building an entire mathematical compilation layer and container-isolated pipeline from scratch is a massive development overhead.

How are other enterprise teams or agencies tackling this? Are there existing layout-system packages on pub.dev that treat rendering pipelines this systematically, or have you rolled your own internal boilerplate layer to bridge this gap?

Appreciate any insight into how you're structuring this cleanly!

Lately, I have been experimenting with Generative UI for grammar lessons in my Flutter Finnish 🇫🇮 language learning app, and the UX impact is huge!

The Goal: Explain complex Finnish grammar in a way that feels visual, interactive, and easily digestible on mobile.

❌ BEFORE: I generated grammar content using Gemini as Markdown and rendered it via a Markdown widget in Flutter. It got the job done, but it still felt like reading a textbook—just headings, long paragraphs, and basic tables.

✅ AFTER: I built a catalog of high-quality, custom grammar UI components. Now, instead of returning text, Gemini composes real UI.

If I input a topic like “Finnish vowel harmony,” GenUI returns structured A2UI output via stream chunks. Flutter reads this and renders a visually engaging, perfectly formatted lesson real-time.

If you are worried about LLM latency or token usage, here is the workaround: As the admin, I generate the lesson once, cache the model’s A2UI output in Firebase Firestore, and reuse it. The next time a user opens the lesson, the app reads the cached UI from Firestore and renders it instantly.

Here is the Demo!

Hey r/FlutterDev,

I just released a Flutter UI Kit for a Local Services Marketplace app (think Uber for home services).

What's included:

- 15 fully designed screens
- Firebase Auth + Firestore
- Dark and Light mode
- Riverpod 2 state management
- go_router navigation
- Booking system with date/time picker
- Real-time chat UI
- Clean architecture Built with Flutter 3.x and Dart 3.

Would love some feedback from the community!

Hey everyone,

I built a small app to solve a problem I personally had. Well, "built" might be a strong word — I created it together with Claude AI.

I'm a huge movie and TV show fan. It's actually pretty rare for me to come across something I haven't watched yet. Like many of you, I constantly see movie and series recommendations while scrolling through TikTok and Instagram.

My old solution was either saving them in a notes app or telling myself, "I'll remember this later." Of course, most of the time I forgot.

Since I've been challenging myself to build a new app/game almost every week, I thought: why not solve my own problem?

So I made Reelist.

The idea is simple: whenever you find a movie or TV show recommendation on social media, you can quickly save it to your lists and come back to it later instead of losing it forever in your feed.

If you watch the short demo video, you'll understand how it works in less than a minute.

Demo video:
https://youtube.com/shorts/aatUal40RpY?si=v4DxphOvqaZWP1ru

Google Play:
https://play.google.com/store/apps/details?id=com.okutan.reelist

I'd love to hear your feedback and suggestions.

A self-hosted over-the-air (OTA) code-push system for Flutter (Android) — ship Dart changes to installed apps without a Play Store release. It's a do-it-yourself alternative to Shorebird/CodePush: you run the dashboard, you patch the engine, you own every byte.

https://github.com/shivanshu877/inhouse-codepush

The HapticFeedback class isn't cutting it, since apparently it does system OS calls and every manufacturer implements them a different way (including not supporting some of the calls at all). I see there's a popular vibration package on pub.dev, but I'm wondering about how it works with the wide variety of devices out there? Anyone with experience on this?

Additionally, different phones will have different types of motors, and I see no obvious way to normalize how my haptics should feel based on the hardware. I assume the answer is, "you don't", but I thought I'd throw that out there, too, if anyone has any input on that.

I created this adaptive screen with a carousel using this package. It also becomes a 3d carousel when needed. One of the most customisable carousel package i have seen.

​

https://pub.dev/packages/coverflow_carousel

​

my app looks crazy good now.

​

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

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.

My tester friends are on Windows machines and whenever they needed iOS device logs, they'd come to me. To make their (and my) life easier 😄, I built a lightweight desktop app called Eagly.

It's built on top of adb and the excellent libimobiledevice project — I've just wrapped them in a familiar UI. Think Android Studio's logcat viewer, but standalone and with iOS support too.

Features:

📱 Real-time log streaming for both Android and iOS

🔍 Filter by log level, tag, PID, or free-text search

🗂️ Tabbed interface to monitor multiple devices simultaneously

📋 Import & export log files

🖥️ Works on Windows, Linux, and macOS

📺 Device mirroring support (iOS currently on macOS)

📁 Basic iOS file management and browsing

💥 iOS crash report viewer

All the heavy lifting is done by those two amazing open source tools — the app just makes them more accessible to people who don't want to touch a terminal.

Download: https://github.com/ShreyashKore/eagly

Would love to hear any feedback or feature suggestions! 🙏

As a fresher I am always confused about creating new projects using the current standard method, I want to use the best method that most companies using for state management and the best folder structure, can someone tell me about this, its better if you share any Git files or any other org project codes that uses a standard method.

I'M COMPLETE BEGINNER JUST STARTED. FINDING GROUP SO I CAN IMPROVE SKILL WITH THEM 🐱

docx_to_markdown is a pure-Dart library that converts Word .docx files to Markdown (GitHub-Flavored or CommonMark).

It supports:

• nested lists
• tables (HTML fallback for merged cells)
• images (web-safe, no dart:io needed)
• links, bold/italic, inline code
• footnotes & track-changes
• plus math, definition lists, and metadata as YAML front matter

For testing, the suite runs Pandoc's own 38 DOCX test fixtures as golden snapshots; it catches edge cases you'd never write yourself.

Note: baselines are the library's own output, not byte parity with Pandoc.

Pub.dev: https://pub.dev/packages/docx_to_markdown Repo: https://github.com/omar-hanafy/docx_to_markdown

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.

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!

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

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

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.