India's Flutter developer community 💙 | Meetups, jobs, spotlights & resources | Bangalore-first, global ambition | Founded by @dhuma1981 (GDE Flutter & Dart) |
Joined May 2018
- Tweets4.1K
- Following386
- Followers22.1K
- Likes5K
FlutterFlakes 💙 retweeted
Hey, Flutter developers, I need your help! 🙏 I spent the weekend vibe-coding a full office suite in Flutter & Serverpod, and it actually turned out amazing. 🤩 Meet Wonky Write, Sheets, Slides, and Drive. Full offline-first support with real-time sync. Built for developers.
The Write app is great for Markdown and is already somewhat stable. However, I'm no expert in Sheets and Slides. 😅 So, I built a system where you can report bugs and suggest improvements. The issues can be upvoted, and the top ones are selected for development. Helping build this is super easy, too. Just install Serverpod, fork and clone the repo, and paste the pre-written prompt into your coding agent using a frontier model. The agent will ask you to review the changes, then it creates a PR. Wonky has an agent that reviews PRs and verifies they match the tasks.
This is like a new way of collective vibe-coding. We can build this together into the office suite of our dreams! 🦄
wonky.work/
FlutterFlakes 💙 retweeted
On iOS 27, VoiceOver users can't move to the next element if the next element is not visible in any scrollable @FlutterDev screen.
Accessibility can't wait for the next stable release.
Fix needed on master channel ASAP 🙏
github.com/flutter/flutter/i…
FlutterFlakes 💙 retweeted
Whenever a package like this lands from Google, you already know what time it is. 😍🚀
@flutterbyteconf
FlutterFlakes 💙 retweeted
PlayDsa now supports 6 languages including Python, Javascript, Go, C++, Java, Kotlin and Dart 🎉. I received many request from all these language lovers. Lets go 🚀
FlutterFlakes 💙 retweeted
Introducing e2e
The agentic testing framework for any app
~/ npx e2e init
→ Fully Open Source
→ Mix deterministic and agentic APIs
→ Supports web, mobile, and more
→ Bring your own agent and infrastructure
→ Run locally or in CI
tester.army/e2e
FlutterFlakes 💙 retweeted
OMG, it's finally here! ✨
Material and Cupertino are now standalone packages on pub.dev
this change is all about better design velocity going forward. if you look at the repos in the coming weeks, you'll see what I mean ;)
run dart fix to add the new standalone libraries
& if you're building a custom design library - I want to see it, send pics!
flutter.dev/blog/decoupling-…
FlutterFlakes 💙 retweeted
Flutter 3.44.9 is now available on stable! 🚀 This resolves an issue where the Flutter CLI and tests would hang if an iOS app crashed during debugging.
Check out the CHANGELOG for details here: goo.gle/4fTnGn7
Good mobile architecture shouldn't depend on something being free.
Fetch intentionally.
Cache aggressively.
Update when necessary.
If you're using Remote Config in production, how are you using it today?
Let's compare notes. 👇
#Flutter #Firebase #FlutterDev #Dart @FlutterDev
The pricing change isn't a reason to panic.
It's a good reason to audit.
Before September 1:
✅ Check fetch frequency
✅ Review minimumFetchInterval
✅ Remove unnecessary fetches
✅ Use caching
✅ Consider Realtime Remote Config
✅ Remove stale flags
✅ Monitor usage
And here's the question I really want teams to ask:
If you're using Remote Config for one boolean flag or a kill switch...
Do you really need all the capabilities of Remote Config?
Maybe yes.
Maybe no.
But it's worth evaluating.
I'd also centralize Remote Config in a Flutter app.
Instead of:
Screen → Firebase
Service → Firebase
Screen → Firebase
Prefer:
Firebase
↓
RemoteConfigService
↓
Feature Flags / App Config
↓
Flutter Features
Your UI shouldn't care where configuration comes from.
If you genuinely need near-real-time configuration updates:
👉 Look at Firebase Remote Config Realtime Updates.
That's a much better model than continuously polling the backend. Use real-time when you actually need real-time.
Another common mistake:
Using Remote Config as a polling mechanism.
Need a flag updated every few minutes?
Don't blindly do:
fetch()
wait
fetch()
wait
fetch()
Ask whether you actually need that frequency.
For production, review your "minimumFetchInterval"
Firebase recommends a 12-hour minimum fetch interval for production.
For example:
minimumFetchInterval: const Duration(hours: 12)
Development can be more aggressive.
Production shouldn't be.
Important distinction:
Reading a Remote Config value:
remoteConfig.getBool('feature_enabled');
doesn't mean you're making a network request.
The problem isn't reading configuration.
It's unnecessary fetching.
Cache what you've already fetched.
The first thing that needs to be checked in any #production #FlutterApp:
How often are you actually fetching Remote Config?
fetchAndActivate() on app launch
→ app resume
→ screen open
→ service initialization
If configuration rarely changes, that's a smell.
🚨 #FlutterDevelopers: @Firebase #RemoteConfig is changing its pricing model from September 1, 2026.
You still get 100K fetches/day for free.
So… should you care?
Yes - but probably not because of the price.
The interesting part is your architecture. 👇
Shri @DKShivakumar Chief Minister of Karnataka on the state of #GoogleIOConnect Bengaluru #BuildWithGemini
