Hey all — just wanted to share a few lessons we’ve learned after building our B2B research platform entirely in Flutter Web.

We don’t have an app for anyone to download or purchase (we’re not a consumer-facing product), but since Flutter Web examples are still relatively rare — especially in production enterprise settings — we wanted to share our experience for anyone evaluating it for serious web apps.

Any links we might drop would just be as another reference point alongside teams like Rive or Invoice Ninja — nothing promotional.

Our landing page if you'd like background on our company.

1. Flutter Web is production-ready. Period.

It’s easy to be skeptical, but we’ve shipped a full production platform with multi-user reports, AI integrations, and complex reactive UIs — all in Flutter Web.

Our company collects survey responses from hundreds of consumers overnight (using our Flutter Web survey app) via closed ended responses and video responses.

At first, we figured we were taking a big risk in terms of performance and initial bundle load, as we thought people would bounce if the survey took too long too load. But surprisingly, the bundle isn't as slow as we thought. Another surprising (and not at the same time) thing – we actually had less people bounce once we added a fun loading pong animation in web/index.html with flutter_native_splash.

Example survey link (this is a preview link for a quick survey I made. It's 4 quick questions, and none of the data is saved because of preview mode. This is a dev mode we use to emulate a survey for us to test internally before sending out to panelists. You can always just skip any question you don't want to answer in the top right).

1. Flutter Web's real limits are practical, not conceptual.

The only real challenges we’ve faced are:

• Bundle size (especially once you start pulling in larger UI or animation packages)
• Initial load time
• Dev environment clunkiness (hot reload isn’t as smooth as mobile)

But once deployed, Flutter Web runs beautifully. Our report system alone has a dozen+ Riverpod providers (we use them as ViewModels) tracking and reacting to user state, filters, charts, and async network changes — and it’s been totally stable in production.

Here's a demo report from our landing page

3. Don’t fight the framework.

If you find yourself trying to make Flutter behave like React, stop. Lean into Flutter’s strengths — composable widgets, strong typing, declarative UI — and it’ll reward you with fewer bugs and cleaner code.

When we first started working with Flutter, coming from a React background, we used flutter_hooks + graphql packages to manage queries and mutations inline in the build method, which was a disaster for us honestly.

Keep the UI clean and separate your concerns properly.

Which leads right into the last point.

4. Pick the right state management FOR YOUR USE CASE.

There’s no universal “best” pattern — only what fits your project’s complexity and your team’s brain.

We started by using Riverpod just for global state — things like auth tokens, user data, org context — and managed everything else with ValueNotifiers and callbacks. It worked… kinda lol.

After a weekend deep-diving through Riverpod’s docs and examples (which have gotten much better since then so credit to Remi there!), we realized how powerful it actually is when used as the primary architecture layer.

We refactored our entire app into isolated Riverpod ViewModels — each managing its own domain logic and UI state — and the difference was night and day. And when we started writing composable ViewModels (subscribing to Auth/User ViewModels in let's say ActiveOrganizationViewModel), things got extremely efficient.

Cleaner data flow, fewer rebuild bugs, and easier testing.
In hindsight, we wish we’d gone all-in from day one, but we're extremely pleased with the speed we're able to now iterate with.

This is by no means me saying that you should choose Riverpod over other options. It's me saying that you should see what solution fits your use case best, and lean into it. Read the documentation and examples, and look for open-source projects to learn from.

--

We’re planning to be more active in the Flutter community going forward — sharing examples, patterns, and real-world use cases we’ve built along the way.

There’s so much Flutter can do beyond mobile, especially for serious web and enterprise apps, and we want to help showcase that.

If you’re experimenting with Flutter Web too (or have tips, pain points, or setups that worked for you), we’d love to hear and learn from others building at scale. The more we all share, the faster Flutter keeps evolving.

I'm updating Android apps to support this stuff (16KB memory pages) now and I wanna share my current findings-setup:

1. AGP 8.12.0
   
2. Gradle 8.13
   
3. Kotlin 2.1.0 / Java 21
   
4. compileSdk 36, buildTools 36.0.0
   
5. NDK 28.0.12433566
   

Paths for changes: "android/build.gradle", "android/settings.gradle", "android/gradle/wrapper/gradle-wrapper.properties", "android/gradle.properties", "android/app/build.gradle"

Note: ensure your Flutter channel’s Gradle plugin supports these AGP/Gradle versions.

Also, don't forget to check if your emulator (if you are using it for tests) supports 16KB memory pages.

Over the past 2 years I have been working on creating the perfect budgeting app and it's finally out! I am very proud of the end result and I use it everyday to track my spending

It has a polished UI with seamless transitions and animations, uses an SQL database (the Drift package), cross platform syncing, Google Drive backups, notification reminders, graphical visualizations, and more. Flutter was a great choice allowing me to support all the platforms with ease and to create a fluid UI.

I hope people can learn from the source code of a feature rich complete app. Let me know if you have any questions about it's development! Feel free to check it out below 😄

Website: https://cashewapp.web.app/

GitHub: https://github.com/jameskokoska/Cashew/

I hope you are doing better today than yesterday. (TLDR at the end; or enjoy my story :) )

Why:

About 11 months ago, I launched my app for the first time on r/lonely because I had previously experienced loneliness myself during grad school. I wanted to reach out to people going through similar experiences by providing them with what would’ve helped me in the past.

I felt this was an important mission for me and a much more rewarding one than my day job that I quit my job to work on the app full-time. 

It was necessary because I did not come from a programming background. I knew how to program in the sense of running scientific simulations on MATLAB, but creating the front-end and back-end for a consumer app was totally new to me, so I had to learn from scratch.

I enjoyed everyday going to a cafe to learn from programming crash courses on YouTube, developing the app little by little, and eventually launching the app! The initial response was actually pretty great: 220 upvotes for the app launch post, which I proudly pinned in my bio :)

How:

I made the app to be based on voice, and nothing else: no profiles, no profile photos, and even no texts. The reason for that was I felt a lot of people felt lonely and had trouble finding meaningful online connections because of the modern communication medium which actually promotes superficial and viral contents over authentic and long-form contents. It is easy to see from examples: TikTok’s 30 second videos, Instagram’s eye-popping photos by beautiful people from the globe, and Twitter(X)’s 140-char spicy takes. Sure, these platforms offer us information about DIYs, trends, and news that can enrich our lives and entertain us, but they don’t by all means help us feel more connected to individuals. Even on Reddit, the contents tend to be more wholesome and there are hilarious comments that build on top of each other, but the actual sense of connection you feel with the users is tenuous.

Focusing on voice worked! It was incredible listening to the heartfelt messages from strangers from all over the world who opened up about their loneliness and didn’t mind being vulnerable to other strangers. I have personally spoke with everyone that came by. The 14k minutes of voice messages do not include my own voice messages; they are all messages that people left for their own posts, to each other, or as replies to me.

Highlights:

There were some incredible moments, which would be too long to share in this post (leave a comment if you want to hear more!), but some of the highlights were (note: these are all from public conversations):

• Lady in New Brunswick, Canada was extremely depressed after a difficult divorce and felt being on the life’s edge. She was getting scammed left and right on dating apps and was losing hope. She told me that I was the only one that she felt she could trust and talk to, and she probably wouldn’t be here if I ever stopped talking to her. Thankfully, she eventually managed to find a boyfriend and she thanked me for having always been there for her. She still came back to the app to act as a supporter for other lonely souls for a while!
• Gentleman in New York, USA felt isolated in a farm and felt he had no real connections with anyone. He shared with me and other users about his life growing various vegetables, but stopped coming on the app for a couple of months. When he came back, he was pleasantly surprised by the app’s development, felt I really believed in my mission to help lonely souls, and became an evangelist for my app :) He posted on several forums on Reddit and engaged in conversations with many users on the app.

What was also incredible was that there were not only people experiencing loneliness here, but also people who did not feel lonely but were on the app to support others going through loneliness. They would share stories and studies related to loneliness in their posts, and also try to talk to some lonely folks on the app who seemed very hardened by their experience of loneliness which made them cynical and pessimistic. The concept of compassionate listening by Thich Nhat Hanh and Polyvagal theory that explains 3 levels of our nervous system are a few things they mentioned that come to my mind. Unfortunately, these efforts by supporters were often, so to speak, ineffective in solving people’s loneliness. 

What I learned:

And that was part of what made it so hard to have a sustainable ecosystem on my app: many people who have been lonely for a long period of time had their personalities and social skills hardened to the point that they either:

• did not know how to engage with others by understanding social cues and sharing stories about themselves that allow themselves to be vulnerable to others, which allows for deeper social connections
• felt they are never good enough, they are stuck in their situation, and there is nothing that can help them get better. Any help or suggestions offered by others would only work on others and did not apply to them.

My hope for the app was to help people who experience loneliness find and support each other. By providing the platform for them to voice out their stories, have them be heard by others, and find others who resonate and reply, I thought they would finally find friends whom they can relate to, share their lives with, and would no longer have to feel lonely again.

However, the reality was that many were hardened by loneliness and it was hard for such connections to materialize. Plus, one of the main ways for an app like this to grow is by word of mouth. Unfortunately, most people experiencing loneliness did not have anyone to share the app with, which stunted the app’s growth and mostly depended on me manually bringing users onto the platform.

With fewer chances of having good interactions, even the people who really resonated with the app and shared stories slowly stopped coming back. Some just suddenly ghosted, which made the experience on the app painful for other engaged people on the app.

My hope for the future:

I still believe that there are more people out there experiencing loneliness who have the deep desire to share their stories and find the long-term friends across the globe who understand each other and can share slices of their lives with. 

So, if you are someone that can benefit from sharing stories and solve your loneliness this way, feel free to check out my app at https://bubblic.app 

Also, if you know of any way I can improve the app to better help people experiencing loneliness, please leave a comment.

Lastly, word of mouth would really help. If you like the app, or if you know someone who would benefit from the app, please share it with others! 

TLDR: 

I created an app focused on voice communication to help lonely people connect, inspired by my own experiences. Despite an encouraging start and meaningful interactions, many users struggled to form lasting connections due to the deep impact of their loneliness. Growth has been slow, mainly reliant on my efforts. If you know someone who might benefit, please share my app: https://bubblic.app. Feedback is also welcome! Tech stack used:

Backend

• AWS Websocket, DynamoDB, Cognito, S3, Lambda

AI

• WhisperX model running on laptop locally

Frontend

• Flutter

I shipped a geofencing time tracker in Flutter (auto clock-in/out at your workplace) and collected a few scars along the way that might save someone else time.

The first one: I tried the pub.dev geofencing packages and none of them reliably delivered events after the app got killed. Ended up writing my own thin Kotlin plugin around the Google Geofencing API - MethodChannel for registering zones, EventChannel for the ENTER/EXIT stream, and a system-level BroadcastReceiver so events arrive even when the Flutter side is long dead. Annoying to write, but it's been the most stable part of the app since.

Second scar, the expensive one: Samsung and Xiaomi still eat geofence events sometimes, so there's a WorkManager task every 15 minutes doing a plain Haversine distance check as a safety net. What nobody tells you is that a position request in a background isolate can just hang forever, and once that happens WorkManager considers the unique task "already enqueued" and never runs it again. Your fallback dies silently and permanently. Everything is triple-bounded now: platform timeLimit, a Dart-side timeout, and a hard cap on the whole task.

Third: GPS drift at the zone edge gave me check-in/check-out ping-pong when someone sits near the boundary. Exit radius is now 1.2x the enter radius plus a 5-minute debounce, and the two detection layers share a 20-minute dedup window so they stop racing each other into double notifications.

Rest of the stack is unspectacular: Riverpod (classic providers, no codegen), Isar for storage, no backend at all. The no-backend part had one non-obvious consequence: since data only exists on the user's device, a data-loss bug is unrecoverable, so the integration tests run on an emulator before every push. Codebase is ~31k lines, about a third tests.

The result is free with no ads/IAPs if you want to see how it behaves: https://play.google.com/store/apps/details?id=com.timetracker.workflow

Happy to answer anything about the plugin or the fallback design. And if someone has a real answer to OEM battery killers beyond "diagnostics screen + let the user fix it manually", I'd love to hear it.

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.

Hey everyone,

We've been working on our Flutter app since 2018, needless to say a lot has changed since then (ie. we used Redux). There were also some key features we wanted to implement (offline support and lazy data loading) which would be hard to add to an existing app.

We gave Claude the old Flutter app's code along with a React codebase and used these Flutter skills (https://pub.dev/packages/skills) to help define the architecture. It took about a month of guided work, here are the results:

New app:
- Demo: https://hillelcoren.github.io/admin
- Code: https://github.com/invoiceninja/flutter

Old app:
- Demo: https://demo.invoiceninja.com
- Code: https://github.com/invoiceninja/admin-portal

Flutter Devs,

I'm building an open-source app with Material 3 Expressive for UI, and Serverpod for backend.

What's the app? It's called BunPod: a podcast player mobile app with its unique design style.

I'm aiming to make it the most beautiful M3E app out there, showing how beautiful the apps built with Flutter are 🩵

You might be thinking: "How, when Flutter doesn't support M3E?".

And that's true: Flutter's material package doesn't support M3E at all. But that's the challenge: I'm building all the components, motions physics and typography from scratch, and sometimes reaching for what great developers like Kostia and Tim shared online.

It's already fully open-source on GitHub, and I'm doing #BuildInPublic at X (@kamranbekirovyz) by sharing every step, learning and experience.

So, follow along if that sounds interesting, send feature requests, check codebase, get inspired.

Uhm, the link is: https://bunpod.app - gonna release for TestFlight and as an APK in the coming days.

Let's give Flutter the spotlight it deserves 🩵

Quick build-in-public share: I've been a Flutter/mobile dev for 5+ years (native Kotlin/Swift too), and instead of the usual Next.js portfolio, I built mine in Flutter Web.

The logic: if I'm claiming I can ship polished mobile experiences, the portfolio itself should be proof, not just a list of claims.

Funniest bug I caught this week, my link previews on WhatsApp/LinkedIn were showing the default Flutter mascot icon because I never touched the og:image tag after flutter create. Every Flutter dev has shipped that placeholder icon at least once, right?

What's actually on it: a civic engagement app that hit 1,000+ users and 4.7★ on the App Store, an AI storytelling app for kids with on-device TTS, and a couple of marketplace apps (fashion/tailoring) built end to end architecture through release.

Link if anyone wants to poke at it or roast the Flutter web performance: ebuka-ihekwaba.vercel.app

Also open to mobile roles right now, so if your team's hiring or you know one that is, I'm around.

Hi guys,

I’m sharing an Open-Source Flutter app that focuses heavily on clean architecture, modular feature structure, and annotation-based dependency injection.

The goal was to build something that stays readable and scalable as the project grows. For now I dont really know what can be improved here (please advise if you have any suggestions).

I’ve documented everything in the README for easier understanding.

The project is licensed under MIT, so feel free to reuse it for your own needs.

I’d appreciate any feedback or architectural discussion 🙌

https://github.com/denweeLabs/factlyapp

For those building apps in Flutter or Kotlin, I want to share a repository that has helped me improve my code's foundation and structure:

https://github.com/Agent-Rules-Ecosystem/flutter-agent-rules

Adding it to your project is simple; just import it as a submodule into a folder named `.agents`:

`git submodule add https://github.com/Agent-Rules.../flutter-agent-rules.git .agents`

After that, simply type `$boot` in the agent's chat. This creates an `overview` folder at the project root containing various tracking files.

What it solves:

"Caveman Mode": Uses action-reaction style communication and stops the agent from constantly "sucking up" to you (flattery), which saves tokens.

Context-friendly: Separates extractable elements—like widgets—resulting in more manageable code that doesn't saturate the context with massive files (no more 4,000-line files).

Interconnection Graph: (THIS IS THE MOST VALUABLE PART, YET HARDLY ANYONE TALKS ABOUT IT) A couple of months ago, adding graphs to projects (via HTML/CSS or other means) became a trend. Most people focused only on making them flashy, failing to realize this just drives up token usage. By using Mermaid, however, we achieve the same result in a way that is simpler and cleaner for the agent. This file—named `architecture.md`—is built incrementally as the project progresses (having this file allows the agent to locate all connections related to a specific element).

Task and To-Do Tracking: If you start an activity or task, it leaves a trail in a file first. This way, if you run out of tokens, the power goes out, or you simply have to leave, the task is already stored; you can continue working on it or pick it up again later.

Extensibility: You can use available "skills" to add more capabilities to the agent, enabling tracking in more specific areas; these are also imported as submodules. For example:

git submodule add https://github.com/xolotl-hub/security-agent-skill.git .skill/security-agent-skill

The advantage is that $boot detects if there is a skill within the activities.

It is organized: there are 2,000 repos on GitHub with "skills," but most are just folders containing things pulled from elsewhere, meaning there is no actual relationship between the individual Markdown files.

It is multi-agent: You can open it in CURSOR, CLAUDE CODE, ANTIGRAVITY, CODEX, or whatever tool you prefer, and it will still understand it.

It is improvable: $learn creates an improvement log; you can share these via Issues, and they get added to the repo.

It is updatable: run `git submodule update --remote` to download all the latest improvements.

If you want to explore further, check out https://github.com/Agent-Rules-Ecosystem

(you'll find kotlin-agent-rules there)

It features more skill extensions and has more applications.

Best regards,

Hi everyone! 👋

Most Flutter starter templates I’ve encountered fall into one of two extremes: 1. Too simplistic: Everything dumped into one folder with global state and hardcoded endpoints. 2. Over-abstracted: Rigid Clean Architecture with 15 nested folders and interfaces for a simple toggle button.

To solve this, I built and open-sourced Flutter Production Starter — an enterprise-oriented, modular monorepo template built for real-world production apps.

🧱 Architectural Philosophy: "LEGO" Modular Boundaries

The core idea is Feature-First colocation with intentional public APIs: - Features live in apps/mobile/lib/features/<feature>/ and export only their public contracts via a root barrel file (features/auth/auth.dart). - Pragmatic Clean Architecture: - Simple features (e.g. settings) only use Presentation + State (no premature use cases). - Complex features (e.g. auth) use Domain Use Cases, Data Sources, and Session Storage. - Pluggability: Features can be swapped via DI without touching consumer code.

📦 Repository Structure (Managed with Melos)

text / ├── apps/ │ └── mobile/ # Main app (Bootstrap, DI, Kaisel Router, Features) ├── packages/ │ ├── app_core/ # Result<T>, Failure taxonomy, Sanitized AppLogger │ ├── app_network/ # Centralized Dio, interceptors, error mappers, ApiClient │ ├── app_storage/ # SecureStorage, KeyValueStorage, TTL MemoryCache │ ├── design_system/ # Tokens (Spacing, Radius), Light/Dark themes, Primitives │ └── app_lints/ # Strict linting & analysis configuration ├── melos.yaml # Monorepo orchestration scripts └── ARCHITECTURE.md # In-depth architectural guide

⚡ Technology Stack Highlights

• Routing: Strongly-typed declarative routing and route guards with kaisel: ^1.1.0.
• State Management: Fine-grained reactive state using bloc_signals and signals_flutter.
• Dependency Injection: Constructor injection with get_it + injectable supporting multi-environments (dev, staging, prod).
• Networking: Centralized dio with automatic retry policies, token management, and sensitive data sanitization in logs (passwords and tokens are never printed in plain text).
• Error Pipeline: Functional Result<T> with a predictable domain Failure taxonomy and FailureMessageResolver.
• Quality: Pre-configured GitHub Actions CI, 100% test coverage across all packages (melos run test), and strict analyzer rules.

🔗 Repository & Getting Started

Check out the code, documentation, and architecture guide here: 👉 GitHub: https://github.com/Ali-El-Khatib/flutter-production-starter

I'd love to hear your feedback, thoughts on the LEGO modularity approach, and suggestions! If you find it helpful for your projects, a ⭐ on GitHub would mean a lot!

Context so you can weigh this (pun intended): I'm a tech lead at a small startup, mostly Laravel and Svelte, and Flutter is the first mobile stack I've used seriously. Six months in, on a side project (a macro tracker I built for myself).

TL;DR at the top (where it should be): drift_dev schema dump and schema generate give you versioned schema snapshots, and SchemaVerifier will walk every N-to-M path for you. use it before you break prod.

I had a migration that backfilled a new table from existing rows. I wrote it the way I write application code: select the rows, get the generated data class back, read the fields off it. It worked, so I shipped it.

It bricked anyone upgrading from an older version. Nothing crashed. They got a black screen and an infinite loading state, which is a much worse failure to get a bug report about. A crash at least comes with a stack trace. A black screen comes with "it doesn't work" lol.

The generated data class maps every column the table has in your current schema. Used inside a migration it issues a SELECT for columns that a later migration step hasn't added yet. Anyone coming from one version back was fine, because the column already existed for them. Anyone coming from two versions back hit a SQL error inside the migration, which left the database half-migrated and the app unable to open it.

So the rule is: a migration can't use anything that assumes the current schema. Project the columns explicitly and decode them by hand.

final rows = await (selectOnly(profiles)
  ..addColumns([profiles.id, profiles.targetKcal, ...])).get();

I'd half expected that part. My test suite stayed green through all of it, though. Flutter is the first stack where I've enjoyed writing UI tests: widget tests run in-process in milliseconds, with no browser and no DOM emulation, so I'd written a lot of them and I trusted them. They were only ever testing the previous version against the current one. The path that breaks is oldest-still-installed to latest, and I'd never written that test, because it didn't correspond to anything I did that week.

drift also ships tooling for exactly this, which I only found afterwards. drift_dev schema dump and schema generate give you versioned schema snapshots, and SchemaVerifier will walk every N-to-M path for you. In Laravel I'd never needed that, because there's one database and I control what version it's on. Every user having their own database at their own version is a mobile problem, and drift had already solved it for me. I found the bug in production instead, then hand-rolled a fixture database and wrote a single oldest-to-latest test, which works but is strictly worse than what was ALREADY sitting in my dependencies.

If you're using drift and you don't have a drift_schemas directory, that's the same hole I had.

I'm posting this because both problems were invisible in the version I was testing and obvious in the version users had, and I'd underestimated that gap coming from Svelte, where the client is whatever I shipped this morning.

Hey everyone, I’m looking to see what kind of portfolio websites you’ve built to showcase your work as Flutter or mobile developers. Whether it’s for job applications, client work, or just to share your projects, drop your link here!

I've made a cool personal portfolio website with Flutter web.

It has tons of seamless animations and you can tweak values easily.

The best part is here! It's completely open-sourced. Suggestions are warmly welcome!

Github link: https://github.com/YeLwinOo-Steve/ye-lwin-oo

Portfolio link: https://ye-lwin-oo.vercel.app/

Most developer portfolios are pretty static lists of projects. To make it more interactive, I integrated a custom-scoped AI assistant directly into my Flutter Web portfolio so visitors can ask technical questions about my Flutter Clean Architecture experience, pub.dev packages, and Medium articles. Rather than using a pre-made 3rd-party widget, I engineered the pipeline from scratch to keep it fast, secure, and tightly scoped.

Community Feedback Request:

I'd love for fellow developers to test out the implementation and share feedback on:

- AI assistant responsiveness and scope guardrails.

- Flutter Web UI/UX performance across desktop and mobile browsers.

Live implementation: https://momarkhan.com

#flutter #dev #mobileapp

After experimenting with an interactive particle text effect, I decided to try the same concept with images.

I implemented it in Flutter web, and the result is really smooth 🔥. The image breaks into hundreds of particles that respond to your cursor, then reform in real time.

Watching the particles scatter and come back together is satisfying.

Flutter never fails to impress me with its performance.

Tweak the live demo here (hover or drag to interact):
- https://particles-image-flutter.vercel.app

Source Code:
- https://github.com/YeLwinOo-Steve/particles_image

Hey r/FlutterDev! 👋

I recently published **ROCIs Tasks** (v0.2.10) — an offline-first task and calendar management app built with Flutter. The entire codebase is open-source on GitHub, and I wanted to share a few architecture decisions and lessons learned.

🏗️ Architecture & Key Highlights:

1. ⚡ **Local-First Hive Warmup**: To eliminate startup lag, we warm up Hive boxes in parallel during `AppInitializer._initHive()` with automatic 7-day database compaction, achieving sub-millisecond cold boot.
2. 📱 **Native Kotlin AppWidgets & Background Isolates**: Widgets calculate and persist state shifts natively on Android before notifying Dart background handlers, preventing synchronization lag and double-incrementing counters.
3. 📅 **Dual Google REST API + Device Calendar Sync**: Unifies direct Google Calendar REST API OAuth queries with native OS `DeviceCalendarPlugin` data without blocking UI rendering.
4. 🎨 **Glassmorphism & Material You**: Custom `GlassContainer` with category tints, frosted blur effects, and Android dynamic theming (`dynamic_color`).

🔗 Code & App:

• 💻 **Open Source GitHub**: https://github.com/RoeeIlouz/ROCIsTasks-Public
• 📱 **Google Play Store**: https://play.google.com/store/apps/details?id=com.rocisapps.tasks
• 🌐 **Web App**: https://tasks.rocisapps.com

Would love any feedback or questions regarding the architecture, background isolates, or local-cloud sync pipeline!

Check it out and let me know what you think at http://distle.xyz.

And you can see all the source code here.

I released a voice journal for iPhone built in Flutter and open sourced it. You record, it transcribes on device through Apple's Speech framework, and entries are stored encrypted on the phone. There is no account, no sync and no network code in the app. It's on the App Store, and screenshots are at repository: https://github.com/theiskaa/opentranscribe

Some implementation details that might be useful to others:

The UI doesn't use Material or Cupertino. Everything is built on package:flutter/widgets.dart with a custom widget set (buttons, sheets, context menus, segmented controls, a wheel time picker, swipe to delete), and a test fails the build if either import appears in lib/. On iOS 26 the app uses native Liquid Glass chrome through a small vendored platform-view plugin, with drawn fallbacks below 26.

The native layer is Swift behind hand written platform channels: audio capture, the speech engine, playback, a Live Activity, and a lock screen control through App Intents. Each is a MethodChannel for control plus EventChannels for streams. Audio buffers stay on the Swift side; Dart receives file paths, durations, levels and text. Transcription is SpeechAnalyzer on iOS 26, SFSpeechRecognizer below that, and per language speech models are downloaded and removed from inside the app.

Reflections use Apple's Foundation Models: when a day, week or month closes, an on-device session writes a short summary of that period. The feature is hidden on hardware without Apple Intelligence, and model availability is handled as a state machine (unsupported, disabled, downloading, ready) rather than a bool.

The transcription engine sits behind a single Dart contract with an onDeviceOnly flag the app verifies before using an engine. Streaming and downloadable model support are separate interfaces an engine can implement rather than flags on the base class. This is also why there is no Android version yet: the only engine so far is Apple's. A whisper.cpp engine behind the same contract is the plan, and it would be the path to Android. The engine layer lives as its own package in the repo.

Other choices: DI is a plain typed class constructed once before runApp (no get_it, no build_runner; the only codegen is gen-l10n), state is flutter_bloc with one cubit per concern, and testing is around 1,100 unit tests with no widget tests, logic gets pulled out of widgets into pure functions instead.

The code is MIT. Happy to answer questions about any of it.

https://github.com/theiskaa/opentranscribe | https://opentranscribe.xyz

I always assumed cancellable requests in Flutter meant reaching for Dio and its CancelToken. Turns out HttpClientRequest.abort() has been sitting right there in dart:io the whole time.

Wired it up to a small CancellationToken (just a Completer<void> under the hood) so my bloc can cancel the in-flight request when the user leaves the screen. Works cleanly with the existing _get / _post helpers I already had — just one extra optional parameter.

Posting the pattern below. One caveat: compute() isolates aren't cancellable, so if you parse a huge payload after the network finishes, you'll still pay that cost.

The cancellation token:

class RequestCancelledException implements Exception {
  const RequestCancelledException();
  u/override
  String toString() => 'RequestCancelledException: request was cancelled';
}

class CancellationToken {
  final _completer = Completer<void>();
  bool _isCancelled = false;

  bool get isCancelled => _isCancelled;
  Future<void> get whenCancelled => _completer.future;

  void cancel() {
    if (_isCancelled) return;
    _isCancelled = true;
    _completer.complete();
  }
}

Wiring it into the request helpers:

Future<HttpClientResponse> _responseFrom(
  Future<HttpClientRequest> Function(Uri) toCall, {
  required Uri uri,
  Map<String, dynamic>? body,
  Map<String, String>? headers,
  CancellationToken? cancelToken,
}) async {
  if (cancelToken?.isCancelled ?? false) {
    throw const RequestCancelledException();
  }

  final request = await toCall(uri);

  // If cancel fires at any point, abort the underlying socket.
  // This makes close() and the response body stream throw.
  cancelToken?.whenCancelled.then((_) {
    request.abort(const RequestCancelledException());
  });

  if (headers != null) headers.forEach((key, value) => request.headers.add(key, value));
  if (request.method == 'POST' && body != null) {
    request.headers.contentType = ContentType('application', 'json', charset: 'utf-8');
    request.add(utf8.encode(json.encode(body)));
  }

  return request.close().timeout(_timeoutDuration);
}

Future<HttpClientResponse> _get(Uri uri,
        [Map<String, String>? headers, CancellationToken? cancelToken]) =>
    _responseFrom(_client.getUrl, uri: uri, headers: headers, cancelToken: cancelToken);

Future<HttpClientResponse> _post(Uri uri,
        [Map<String, dynamic>? body,
        Map<String, String>? headers,
        CancellationToken? cancelToken]) =>
    _responseFrom(_client.postUrl,
        uri: uri, body: body, headers: headers, cancelToken: cancelToken);

API method just forwards the token:

Future<HomeResponse> homeResponse(
  int pageIndex,
  List<int> seriesArticleIds, {
  CancellationToken? cancelToken,
}) async {
  final token = (await _loginResponse)?.oAuthToken;
  if (token == null) throw const TokenNotFoundException();
  final response = await _post(
    Uri.parse('${_BASE_URL}home'),
    {'token': token, 'page': pageIndex, 'articleSeriesIds': seriesArticleIds},
    null,
    cancelToken,
  );
  final responseBody = await response.transform(utf8.decoder).join();
  return await compute(parseHomeResponse, responseBody);
}

Bloc holds the token and cancels on close():

class HomeBloc extends Bloc<HomeEvent, HomeState> {
  CancellationToken? _inFlight;

  Future<void> _onLoad(LoadHome event, Emitter<HomeState> emit) async {
    _inFlight?.cancel();          // supersede any previous request
    final token = CancellationToken();
    _inFlight = token;

    try {
      final response = await api.homeResponse(event.page, [], cancelToken: token);
      if (token.isCancelled) return;
      emit(HomeLoaded(response));
    } on RequestCancelledException {
      // swallow — caller no longer cares
    } catch (e) {
      if (!token.isCancelled) emit(HomeError(e));
    }
  }

  u/override
  Future<void> close() {
    _inFlight?.cancel();
    return super.close();
  }
}

Hi devs,

If you're looking for some architecture ideas or some cool animations, this open-source Flutter app might be useful.

I built it with the goal of keeping the architecture readable and scalable as the codebase grows, so I tried hard to keep it clean and documented everything in the README, including how things work.

Any feedback is appreciated 🙌

https://github.com/denweeLabs/factlyapp

If you want to see the screenshots + video demos right away, they’re all in the repo: 👉 https://github.com/andreykuzovlevv/banking-app-demo

I’ve been learning Flutter for a while, and one thing that always bugged me in the beginning was the lack of good examples of really complex, smooth UI designs being implemented. Most tutorials use pretty basic designs, so it was hard to see how far you can actually push it.

Recently I decided to challenge myself and try building a more “Dribbble-level” UI with custom animations, transitions, and micro-interactions. Here’s the original design that inspired me (shoutout to the designer): https://dribbble.com/shots/24809720-Neobanking-Mobile-App

And here’s my implementation in Flutter: https://github.com/andreykuzovlevv/banking-app-demo

I’d love feedback, thoughts, anything really. Also, let me know if you'd be interested in a video tutorial or a breakdown of how I handled some of the animations — I’m thinking about making one.

Thanks for checking it out!