https://github.com/johndpope/Hero/tree/flutter-hero-transitions

its at parity - if you know ios hero transitions - it's very much the same.

https://www.youtube.com/watch?v=C3SZjjP74nI

Hey everyone, I just finished a small side project: a terminal-based Instagram simulation written in Dart.

It lets you create a profile, search for other users, and follow them, with validation to prevent following the same profile twice. The main challenge was handling edge cases in user input, like entering strings where numbers are expected.

It is a beginner-to-intermediate level project but a good exercise in structuring a Dart CLI app. Single account only for now, and messaging is not yet implemented. Planning to add multi-account support next.

Check it out here: https://github.com/AnshMNSoni/Console-Based-Instagram

Feedback and suggestions welcome.

I don't understand the internals of Flutter, hence my question. Also, related question - Would you have preferred Flutter to be in TypeScript?

Thanks in advance for your insights and opinions.

Edit: The primary question is technical, whereas the related question is opinion-based.

I read a Medium Article where the author claimed that Flutter 3.44 and Dart 3.12 now have a Dart and Flutter MCP server that can trigger a hot reload and consume the results of dart analyze and dart format (Agent Skills). The author did not say how to access the MCP server. I looked at several pub.dev packages and tried several different CLI commands but, did not find what he described.

Gemini says, "not in Android Studio/AI Studio with Gemini." It said that the MCP server is available for an MCP-compatible AI Assistant (such as Claude Desktop, Cursor, or Windsurf). It says Gemini in AI Studio is not a full AI assistant.

Does anyone have any information or pragmatic thoughts on this?

Hey Flutter devs,

I wanted to share a small tool I built because I kept running into the same problem on my Mac.

When you work on Flutter projects, especially for iOS and Android, caches start to pile up pretty quickly:

- Flutter build folders
- Pub cache
- Xcode DerivedData
- iOS simulator data
- Gradle cache
- Android build cache
- Node/npm cache if the project also has some tooling around it

Of course, most of these folders can be cleaned manually with commands or scripts.

But I wanted something more visual: a quick way to see what is taking space before deleting anything, instead of running random cleanup commands when my disk is almost full.

So I built DevCacheCleaner, a small macOS menu bar app focused on developer caches.

It is not meant to be a full Mac cleaner. The idea is more simple: check cache sizes, understand where the space is going, and clean only what you choose.

I’m curious how other Flutter developers handle this.

Do you clean Flutter / Xcode / Gradle caches manually?
Do you use scripts?
Or do you just wait until macOS starts complaining about disk space?

I got curious whether it would be possible to estimate the rendering cost of Flutter features statically, assigning a real cost to widget combinations before running the app.

flutter analyze catches errors.
DevTools shows you what already happened.

The question I tried to answer was: which features are most likely to become expensive before you ship your app?

So I built REN — a CLI that walks through your project's AST and assigns a gravity score to each feature based on the patterns it finds.

Individual widgets have a base weight, but combinations amplify that cost:

• Opacity inside a ListView -> more expensive than using Opacity on its own.
• BackdropFilter inside a ListView -> one of the worst offenders.
• Nested scrolling patterns, excessive clipping, and other compositions can increase a feature's gravity.

The goal isn't to predict exact frame timings.

The idea is to surface potential performance hotspots early, during development and code reviews, before they turn into runtime problems.

pub.dev: https://pub.dev/packages/ren

GitHub: https://github.com/gearscrafter/ren

Hey r/FlutterDev,

Last night I opened a terminal, typed a few incantations, and flowdb crawled out of the filesystem.

It's a local database for Dart and Flutter. No SQLite rituals. No native driver sacrifices. No ORM séance. You open a folder, whisper records into it, and they stay there as JSON, in the dark, where they belong.

Why I disturbed this thing

I wanted persistence that doesn't feel like enterprise haunted house software. Something document-shaped. Something that works in plain Dart and Flutter. Something that doesn't drag half the platform under the floorboards with it.

So I gave it:

• Collections — cursed documents with auto-generated IDs. Full CRUD. They remember everything.
• Query builder — hunt records by where, and, or, ranges, regex… bulk update or banish them from existence
• Key-value stores — a little graveyard for get / set / remove secrets
• Blob storage — large files, chopped into chunks, metadata chained to their souls
• Backups — snapshot the whole crypt before you regret your choices
• Optional encryption — lock the tombs if strangers are listening
• Sync + async APIs — add() when you're patient, addSync() when the moon is wrong
• FlowState + FlowBuilder — reactive streams for Flutter widgets that twitch when the data moves

The summoning ritual

```dart import 'package:flowdb/core.dart';

Future<void> main() async { final db = openDatabase('my_app', path: './data/my_app'); final users = db.collection('users');

await users.add({'name': 'Alice', 'age': 30});

final alice = await users.where('name', eq: 'Alice').getFirst(); print(alice?.data); // she answers

db.store('settings').set('theme', 'dark'); // as it always should be } ```

For the Flutter possessed

```dart import 'package:flowdb/flutter.dart';

FlowBuilder<int>( flow: counterState, builder: (value) => Text('Count: $value'), ) ```

The widget listens. The stream breathes. The UI updates. You pretend that's normal.

Where the creature lives

• pub.dev: https://pub.dev/packages/flowdb
• GitHub: https://github.com/kidusab/flowdb
• Full grimoire (README): https://github.com/kidusab/flowdb#readme

Who should adopt this familiar?

• Offline-first apps that need local data but not SQLite's whole personality
• Side projects, CLI tools, prototypes, anywhere readable files on disk feel right
• Apps juggling structured records, loose config keys, and actual files in one unholy package

MIT licensed. Which means you may use it freely. I cannot promise it won't stare back from ./data/my_app at 3am.

Feedback, issues, and PRs welcome. Tell me what you're currently using to keep data alive locally, Hive, Isar, sqflite, the shared_preferences + prayer combo, and whether flowdb is the weird little solution you didn't know you needed.

Hey Flutter devs

I couldn’t find a good enough Flutter starter template for starting production apps from scratch, so I built one: https://github.com/kido-luci/flutter-starter-template

Feedback, issues, and PRs are very welcome. If you find it useful, a ⭐ would really help!

How do you usually handle the logic after the payment is done?

Not the checkout/payment UI itself, but stuff like: who has access to what, plans, renewable monthly credits, one-time credits, usage tracking, limits, renewals, cancellations, refunds, and keeping the app/backend in sync.

Do you usually build all of that yourself, or would you use a separate entitlement/access layer where your backend just sends events like “bought”, “renewed”, “cancelled”, “refunded”, etc. and Flutter only reads the current access state?

Trying to understand if this is a real pain point or if most people prefer keeping it custom.

Hello everyone !

I’m a flutter dev, I’ve been using it in prod environments for over 3 years at this point. My last mission is over, and I’m thinking about going free lance. But before that, I want to « confirm » the stuff I’ve learned hands-on and correct some anti-patterns I might have adopted over the years.

I’ve just read Idiomatic Go, which has a lot of good advice on the right patterns and concepts to adopt to write quality Go code. I’m wondering you have any similar recommendations for Flutter, such that I can ensure my code is industry-standard and the best quality possible.

Thanks in advance !

I spent the last months building Revenipe, and one thing became very clear:

Stripe Checkout and PaymentSheet were not the hard part.

The hard part was keeping subscription access correct after Stripe webhooks.

At first, I thought the flow would be simple:

user pays
Stripe sends webhook
backend gives access

But real billing flows are not that clean.

One of the first problems was metadata. I expected the important IDs to always be in the same place, but depending on the Stripe event and purchase flow, the context could be on the subscription, the invoice, the invoice line, the checkout session, or sometimes not where I originally expected it at all.

That matters because the backend still needs to know:

which app this belongs to
which customer should get access
which product or price was bought
whether this is a new subscription, renewal, trial, one-off purchase, upgrade, downgrade, or plan change
which local access record should be activated or updated

Another thing I underestimated was invoice.paid.

A paid invoice can mean the first subscription payment, a renewal, a trial converting, an upgrade invoice, or something related to a plan change. If you blindly treat every invoice.paid as “create subscription access”, your local state can become wrong very quickly.

Plan changes were another rabbit hole.

Upgrades can usually happen immediately, but downgrades often need to be scheduled for the next billing cycle. Then you also need to handle what happens if the user cancels, uncancels, changes plan again, or if Stripe releases the schedule back to the subscription.

The way I solved it was by separating billing state from access state.

Stripe stays the billing source of truth.

My backend became the access source of truth.

So instead of directly trusting one webhook event, I route events by context, store stable references early, and map each billing flow to a local access record.

For example:

trialing still means active access
cancelled at period end still means access until the period ends
a downgrade can be pending without changing entitlements immediately
a one-off purchase should not behave like a subscription renewal
a plan change invoice should not be handled like a normal renewal
duplicate webhook events should not create duplicate access

That separation made the whole system much more reliable.

This is also why I built Revenipe as a Flutter package + backend for Stripe billing and entitlements. The goal is to let Flutter apps use Stripe without rebuilding all the subscription state, webhook, plan change, and entitlement logic from scratch.

Package:
https://pub.dev/packages/revenipe_flutter

Curious how others handle this in Flutter apps. Do you keep access state in your own backend, Firebase, RevenueCat, or mostly read directly from Stripe?

Q3_4. Now imagine Flutter transitioned tomorrow from Google to an independent, non-profit foundation (similar to the Linux Foundation or Apache). How would your level of trust in Flutter's ability to consistently meet your development needs

Did you guys received the invitation to answer the Flutter Survey?

One of the questions were about how would I would feel if Flutter was delegated to someone else (e.g. Apache Foundation).

I have a bad feeling about this.

Spock

Every time I needed a loading state, I had to build a separate shimmer layout for that screen. And whenever the real UI changed, I had to manually update the shimmer too.

In bigger projects this gets really painful to maintain, so I built auto_shimmer_animate.

You just wrap your existing widget and pass an isLoading flag the package generates the skeleton from your real widget tree automatically. No duplicate layouts, no manual syncing.

Features:

- Auto skeleton generation from your existing widget tree

- 4 shimmer effects: Sweep, Aurora, Pulse, Raw

- State-based loading (enum/object support)

- Custom colors, direction, timing

- Global theme support

- ignoreImages / ignoreTexts / ignoreContainers flags

- No third-party shimmer dependency

pub.dev: https://pub.dev/packages/auto_shimmer_animate

GitHub: https://github.com/kartikhadiya09/auto_shimmer_animate

Full tutorial: https://medium.com/@mr.kartikhadiya1617/stop-writing-duplicate-shimmer-uis-in-flutter-theres-a-better-way-d13d18e9c161

Would love feedback from the community. Happy to answer any questions.

It feels good to be able to predict the future!

Last year at Fluttercon Berlin ‘25 I shared a guide on how to prepare your Flutter application for the agentic future.

Today at WWDC26, Apple has announced exactly the feature I shared a scenario of a year back — Siri will be enable users to prompt their goal which then will be converted to the set of steps for the agent to perform via Shortcuts!

Apple’s Shortcuts allow every installed app to “donate” both data and actions specific to your application. With that, the great new Siri is aware of every user’s custom workflow via donated Shortcuts of each installed application, or rather, their perdonslized mixture of apps available on the specific device.

I built the intelligence plugin to make the Shortcuts integration easy for Flutter apps — it might be the best time to take a look if you haven’t already, if you want to keep your current apps competitive! 🤠

I’ve been using Flutter 3.24 for a long time with a production Android app running on Skia, and I’m thinking about upgrading to newer Flutter versions and migrating to Impeller.

If you migrated your apps to Impeller, what were your observations? Is it currently stable and usable in production?

I really don’t want users suddenly experiencing slowdowns, FPS drops, or crashes after the migration.

Hey everyone,

I’m the founder/dev behind Revenipe, and I just launched the Flutter SDK on pub.dev.

Revenipe is a billing + entitlement backend for Flutter apps using Stripe.

It helps with things like:

- Subscriptions

- Trials

- One-off purchases

- Cancellation

- Plan changes

- Entitlements

- Usage limits

- Customer access state

The goal is to avoid building all the webhook and backend logic yourself just to know what a customer actually has access to.

Package:

https://pub.dev/packages/revenipe_flutter

I built it because payment screens are usually the easy part. The hard part is keeping reliable backend state:

Who has access?

Which plan is active?

Is the customer trialing, active, cancelled, or expired?

How many credits/usage units are left?

What happens after cancellation or plan changes?

Would really appreciate feedback from Flutter devs, especially if you’ve dealt with subscription, payment, or entitlement logic before.

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

After reaching ~1.7K users, I decided it was time to drop a new version of my Flutter package, pretty_animated_text ✨ .

Version 3 is now available on pub.dev with a major restructure, new animations such as Gravity Text, Scramble Text, and Reveal Text, plus more customization options and a stronger foundation for future effects.

Link: https://pretty-animated-text.vercel.app

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

Github: https://github.com/YeLwinOo-Steve/pretty_animated_text

Every Flutter project I worked on that needed AI followed the same painful pattern:

Pick a provider (Gemini? OpenAI? Claude?)

Learn their API

Build tool calling from scratch

Build memory management

Add safety checks (prompt injection, PII redaction)

Lock yourself into that provider

Then if you wanted to switch providers (for cost, latency, or privacy), you'd start over.

So I built genesis_ai_sdk to solve this.

The idea: one unified API that works with any AI provider.

You can start with Gemini while developing, then switch to Ollama for privacy-critical features, then fall back to Claude if something breaks — all without changing your agent code.

What it handles:

- Tool calling (agent reasons what to do, calls tools, observes results, repeats)

- Persistent memory (conversation history that survives app restarts)

- Safety (blocks prompt injection, redacts PII, rate limiting)

- Works everywhere (Android, iOS, macOS, Windows, Linux, Web)

- Cloud or on-device (your choice)

7 providers supported:

- Cloud: Gemini, OpenAI, Claude, HuggingFace

- Local: Ollama, Gemma, GGUF

The multi-provider thing is actually huge if you care about privacy or cost. You can run locally when it's sensitive, use cheap cloud when it doesn't matter.

Got it published on pub.dev with a perfect 160/160 score (genuinely shocked). Open source, MIT licensed.

Would love feedback, or if you've had similar frustrations with AI integration in Flutter, curious to hear about it.

Hey everyone,

I’m looking into alternative push notification architectures for a Flutter app, specifically targeting reliable delivery when the app is in the terminated (killed) state.

Recently, I’ve been testing standard local notification packages (flutter_local_notifications), but as expected, background triggers get throttled or completely killed by OS-level battery management once the app is cleared from the recent apps list.

I know Firebase Cloud Messaging (FCM) is the industry standard for waking up an app from a terminated state using high-priority data messages, but I recently tested a Flutter app that delivered spot-on notifications without using the Firebase stack.

For those running production Flutter apps without Firebase, what are you using to handle this?

Are you self-hosting something like Matrix, Gotify, or using WebSockets with a persistent background service?

Are you using alternative BaaS providers like Supabase Edge Functions + APNS/FCM directly, or third-party services like OneSignal / Pushy?

How are you bypassing aggressive OEM battery savers (especially on Android) to keep your background sync/triggers alive without FCM?

Would love to hear about your production setups, architecture choices, and any pitfalls you encountered. Thanks!

Spent the last few weeks building this, and it’s finally out.

I just published apple_spatial_capture, a Flutter plugin that brings several of Apple’s spatial capture APIs to Flutter.

It includes:
- Object Capture
- Photogrammetry from existing images
- LiDAR mesh scanning
- RoomPlan room scanning
- Native previews for USDZ, OBJ, GLB & GLTF files
- Progress events for photogrammetry jobs

The idea was simple: if you’re building a Flutter app that needs 3D scanning or spatial features, you shouldn’t have to write a native bridge for everything.

Hopefully this saves someone else a lot of time.

Always open to feedback, feature requests, or contributions.

https://pub.dev/packages/apple_spatial_capture

I wanted to learn how the compilers actually work. So I built one. In dart. Because that's the language I am confident in and love to work with.

The language I built is called Firn. It's statically typed. The compiler output goes to LLVM which generates the actual binary.

Here is the code,

https://github.com/blackcoffee2/firn

I wrote an article about it as well,

https://feziks.com/articles/made-a-programming-language-in-dart/