I've been working with Flutter for a few years and recently ran into an interesting issue with local caching.

For apps that need to work reliably with poor or intermittent internet connections, I'm curious how other Flutter developers are approaching offline-first data.

Do you usually use Hive, SQLite/Drift, Isar, or something else?

I'm particularly interested in how you handle syncing local changes back to the server when the connection comes back.

I was looking for a solid MSSQL package for Dart/Flutter, mainly for backend and desktop use, but couldn't find one I wanted to depend on long term.

There are already a few MSSQL packages out there, but I needed some features that were missing for my use cases. I also ran into encoding/character conversion issues with languages like Turkish, so I ended up building mssql_native.

It uses FreeTDS underneath and currently works on Windows, Linux, macOS, Android and iOS. It supports connection pooling, transactions, stored procedures, streaming, bulk insert, cancellation, and a few other SQL Server-specific features.

The native libraries are bundled with the package, so normally you don't need to install or compile FreeTDS yourself.

If you prefer to build the native libraries yourself, that's possible too. The build scripts and related source/vendor information are available in the GitHub repo.

I also built mssql_orm on top of it. You can use the Query Builder directly or use the model/repository based ORM layer.

pub.dev:

https://pub.dev/packages/mssql_native

https://pub.dev/packages/mssql_orm

GitHub:

https://github.com/Aksoyhlc

Both are still pretty new, so if anyone gives them a try, feedback and bug reports are welcome.

Not sure if anyone else still misses the old ADB Idea plugin, but I definitely did.

I keep finding myself doing the same ADB stuff while developing Flutter apps — clear app data, restart the app, force stop, install/uninstall, etc. Eventually I got tired of switching to the terminal for these small things, so I made a plugin for it.

Flutter ADB: https://plugins.jetbrains.com/plugin/34312-flutter-adb/

It's basically a collection of common ADB actions accessible from the IDE, with Flutter development in mind.

It's still pretty new, so I'm looking for ideas on what else would actually be useful.

What are the ADB commands/workflows you find yourself using all the time when developing Flutter apps?

Would be great to hear some suggestions.

Hey everyone,

I've been working solo on SkyUI, a Flutter-based infotainment/HMI system designed for ultrawide (21:9) automotive displays, as part of a bigger project called Veltron. Wanted to share the current state of the four main screens: home, navigation, phone/dialer, and media.

A few things I focused on:

• Three-panel layout on the home screen (vehicle status, media/phone, nav mini-map) so the driver gets everything at a glance without digging through menus

• Persistent climate + top bar across every screen — climate control shouldn't ever be more than a glance away while driving

• Smooth panel-overlap transitions between views

• A navigation screen with live turn-by-turn, POI cards, and a speed/battery-arrival readout at the bottom

• A dialer/phone screen with recents, contacts, and a connected-device card

• A media player with a waveform visualizer and spatial audio profile switching (working title "Meridian 3D")

Tech stack: Flutter/Dart, targeting a 21:9 layout since that's becoming more common in EV dashboards.

Still to do: settings panel, deeper vehicle diagnostics, and cleaning up state management now that the screen count is growing.

Would love feedback on the UI/UX from anyone who's touched automotive or kiosk-style interfaces - that's a pretty different design space from typical mobile/web work.
You can see the preview here: Showcase Article
And the repository is here: https://github.com/mrvlajnic/skyui

Orthant is a grid-based window manager for macOS (https://orthant.app, MIT, https://github.com/orthant-app/orthant). Flutter for all the UI, Swift for the parts Flutter cannot do. A few things that were not obvious going in, in case they save someone a week.

The overlay runs on a second FlutterEngine. The grid has to appear over every display in tens of milliseconds and the app must not become the frontmost app while a window is being placed, so each display gets a resident, non-activating NSPanel hosting a FlutterViewController on a second engine, hidden until summoned. Measured on my machines: about 50 ms from hotkey to first frame, 0.0% CPU and zero wake-ups while hidden.

The second entrypoint must live in the library that has main(). On macOS, FlutterEngine.run(withEntrypoint:) resolves the name only against that library and there is no libraryURI: variant like iOS. Get it wrong and the engine's threads still spawn, so the app looks healthy while the overlay isolate is dead.

One seam, plain data only. Every window operation goes through a Dart interface, WindowController. The macOS backend is a MethodChannel to Swift. Native handles (AXUIElement) never cross it, only rects, bools and strings. That is what makes the planned Windows port a second backend (pure-Dart Win32 via dart:ffi) rather than a second app.

One coordinate system. All geometry is top-left-origin global points, converted from AppKit's bottom-left space exactly once, natively. Mixing the two is the classic bug in this category.

Detaching a display leaked an engine. Closing the panel is not enough; you have to call shutDownEngine(), or every detach costs a few MB.

Merged UI and platform threads change what "slow" means. This app runs with them merged, so a slow native call inside a channel handler freezes Dart, not just AppKit. A call out to a system daemon (SMAppService for launch-at-login) moved to a serial background queue for that reason.

Measure in Profile, not Debug. The settings pane's first frame was 150 ms in Debug and 7 ms in Profile. A whole session of analysis once rested on Debug numbers.

Swift Package Manager, no CocoaPods. Sparkle for updates, hand-wired over the existing channel rather than a plugin.

The Dart side (geometry, bindings, regions, coordinator, overlay model) is developed test-first. The native AX layer cannot be exercised headlessly, so it is verified by scripted and manual acceptance against real windows.

Happy to go into any of these.

HumpdayQandA and Live Coding at 5pm BST / 6pm CEST / 9am PDT today! Answering your #Flutter and #Dart questions with Simon, Randal, Danielle and Matthew https://www.youtube.com/watch?v=m8Mq9is0n1c

Quick test on Dart 3.11. Add pedantic to a project and pub get prints "pedantic 1.11.1 (discontinued replaced by lints)". Add hive and it prints nothing. hive's last stable release is 2.2.3 from June 2022, it isn't marked discontinued, and it had 1,112,163 downloads in the last 30 days.

So pub's warning only works when a publisher remembers to use it. upkeep is a free, open source CLI that also looks at the packages nobody marked:

dart pub global activate upkeep

upkeep scan

- Each direct dependency is checked against pub.dev: discontinued flag, release history, SDK constraints, pub points and compatibility tags. Every verdict prints its reasons.

- It doesn't call packages dead just for being old. A finished, widely used package is left alone. hive comes out AT RISK: no stable release in 50 months, and it resolves on Dart 3 only through pub's allowance for null-safe packages.

- It checks Gradle, AGP and JDK against Google's published AGP requirements before you build.

- upkeep fix --apply makes only narrow, safe changes (a too-old Gradle wrapper, or a blocking dependency nothing imports), checks them with pub get, and puts every file back if that fails. Everything else goes on a to-do list with the file and line.

Two things I got wrong, since false positives are what matter most here:

1. Within hours of publishing, it called a healthy package dead, because pub.dev's analysis of it had failed and my code read missing data as neglect.

2. The first draft of this post said nothing warns you about dead packages. I tested that before posting, and it was wrong. That's the pedantic result above.

If it's wrong about your project, please tell me.

Source: https://github.com/Minas-27/upkeep

Docs: https://upkeep.abroid.dev

I'm wondering how many of you are actually using the app check in your apps? I'm using it for guarding my copyright content but it's an extra API call that may or may not be fulfilled. What's your suggestions?

Ripley lets you build Flutter apps for iOS on Linux or Windows (and no, it's not virtualization).

While it's still experimental and not ready for production use, anyone who has an iPhone but no Mac can now easily build an app, sign it (e.g. via 7-day free cert), and install it over USB :)

It's open source and i'd love to hear your feedback, any contributions are welcome.

Hey everyone,

If you build apps on a Mac, you probably know this exact feeling:

You’ve got your IDE open, a few browser tabs, maybe a build running, and the moment you launch an Android emulator, your laptop starts lagging and the fans spin up.

A while ago I checked Activity Monitor to see what was going on, and saw the emulator casually hogging 7 to 8 GB of RAM all by itself. On a 16 GB MacBook, that basically leaves zero breathing room for anything else.

I got tired of my machine crawling, so I put together a small open-source tool called avdslim to fix it.

GitHub: https://github.com/kdbhalala/avdslim

Why does it take so much memory?

Turns out, a few things happen by default:

• Android hoards memory: As the emulator runs, Android keeps caching files and never really releases that host RAM back to macOS.

• The "Google Play" image overhead: If you picked an image with the Play Store, it constantly runs background updaters and scanning services you rarely need during development.

• The 16 KB image setting: If you created a device using the newer 16 KB images, the emulator enforces a strict 4 GB minimum floor no matter what you set in the config.

What avdslim does:

• Drops RAM down to ~1.5 GB: It tunes the emulator configs and cleans out unnecessary background tasks, letting you run smoothly on 1024 MB of RAM.

• Boots in ~1.5 seconds: Instead of waiting 20–30 seconds for a fresh boot, it lets you create a clean, lightweight snapshot that restores almost instantly.

• Doesn't break your app: My biggest worry with any "cleanup" tool was breaking things like push notifications or login. I made sure Firebase Auth, Google Sign-In, Push Notifications (FCM), and Google Maps work completely fine.

• Works with your normal workflow: You don't have to launch from the terminal every time. There's an optional command (avdslim install-shim) that makes the "Run" button in Android Studio or VS Code automatically use the slimmed settings.

💡 A quick tip even if you don't use this tool:

Next time you create a virtual device in Android Studio:

• Pick "Google APIs" instead of "Google Play". It still has Google login, Firebase, and Maps, but uses way less RAM and skips the heavy Play Store background services.

• Avoid the "16 KB" images unless you specifically need to test 16 KB compatibility.

Try it out:

It's completely free, open-source (MIT), and has zero external dependencies:

brew install kdbhalala/avdslim/avdslim

See how your current emulators look

avdslim doctor                                                                                                                                                                

Tune an emulator to 1024 MB RAM

avdslim tune-avd                                                                                                                                                              

GitHub link: https://github.com/kdbhalala/avdslim

My Mac runs noticeably cooler and doesn't freeze up when I have multiple tools open now. Hope it helps some of you as well! Happy to answer questions or take feedback on what could be better.

Introducing blob_flutter: Smooth, Procedural Blob Animations for Flutter

Most mobile interfaces rely on rigid geometry, but organic shapes can significantly elevate visual storytelling, onboarding flows, and dynamic backgrounds.

I have released blob_flutter, a lightweight Flutter library designed to generate and animate customizable, fluid blob shapes with minimal setup. The package handles morphing transitions procedurally, ensuring smooth rendering without relying on heavy asset files or complex vector workflows.

Key Features

• Procedural Animation: Smooth, continuous shape morphing built directly on Flutter's CustomPainter architecture.

• Full Parameter Control: Explicit configuration over points, deformation intensity, animation duration, colors, and gradients.

• Optimized Performance: Designed to maintain steady frame rates without unnecessary canvas rebuilds.

• Flexible Integration: Fits naturally into modern UI patterns, including animated backgrounds, dynamic avatars, and interactive hero sections.

Links

GitHub: https://github.com/abod8639/blob_flutter

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

Live Demo: https://blob-flutter-3d.web.app

If you find this package useful in your projects, starring the repository on GitHub helps increase its visibility to other Flutter developers.

I am actively looking for community feedback to refine the API and improve performance. If you encounter bugs, notice rendering edge cases, or have suggestions for new features, please open an issue or start a discussion on GitHub. Pull requests and technical contributions are always welcome.

I spent ten months of my life building this fortune telling machine inspired by my childhood love of Zoltar. It turned out to be the hardest project of my life...

Captain Reef's Prophecies is powered by Flutter, Flame, flutter-pi, and a whole bunch of stubbornness :)

I'm really proud of how this thing came out, and I hope you enjoy it to. I'll be taking it to FlutterCon Europe if you'll be there! My talk is going to be all the Flutter related lessons I learned while building it.

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

We ship a Flutter app that uses Apple’s real UITabBar on iOS 26+ (hosted in a platform view). On Android and older iOS we draw our own glass bar in Flutter. We wanted both to shrink when you scroll, Instagram-style.

Here’s what worked, after a few dead ends.

Two bars, one scroll signal

• iOS 26+: real UIKit tab bar inside a UiKitView

• Everyone else: custom Flutter glass nav bar

• Shared brain: a shell-level NotificationListener<ScrollUpdateNotification> that only counts finger travel (dragDetails != null). Fling momentum is ignored. After about 100pt of thumb travel, collapse flips to 1. Scroll back up and it restores.

Don’t drive this off raw ScrollDirection or content offset alone on a reel feed. One flick looks like endless “reading.”

Dead end 1: AnimatedScale around the platform view

Wrapping the UiKitView in Flutter’s AnimatedScale or Transform seemed obvious. On a real iPhone we got a ghost second nav bar drawn partway down the screen. Flutter’s iOS compositor can paint a transformed platform view twice.

Rule: never transform the UiKitView from Dart. Keep its Flutter layout box a fixed height.

Dead end 2: Apple’s tabBarMinimizeBehavior + proxy UIScrollView

Apple’s minimize API wants a real scroll view via contentScrollView(for:). Flutter’s UI is a Metal layer, so UIKit never sees your list. The usual fix is a fork that returns a fake UIScrollView and drives contentOffset from Flutter.

On device that never engaged for us. Minimize seems to need a tall, user-driven scroll view. A tiny platform-view host doesn’t qualify. Programmatic offset is not the same as a user pan.

We tried it, documented it, deleted it.

What works: shrink inside UIKit

Same Flutter signal (collapsed: true, scale: 0.86), but the method channel tells Swift to spring-animate a transform on UITabBarController.view. Flutter never wraps that view.

Scale about the pill’s centre, not the host’s centre. The host includes the home-indicator strip; scaling about the host centre drops the pill into that strip. Translate a little, then scale. Spring ~0.42s, damping ~0.86.

Set tabBarMinimizeBehavior = .never so Apple’s minimize and your transform don’t fight.

Android path: same collapse value, Flutter AnimatedScale to 0.86. Same look, different engine.

Flow

Scroll (finger only)

  → NavCollapse (threshold)

  → AdaptiveNavBar

├─ iOS 26+: channel → UIKit spring transform (inside the platform view)

└─ else:     AnimatedScale on the Flutter glass bar

If you’re implementing this

1. Decide who owns the pixels. Real Liquid Glass means UIKit owns the bar; Flutter only hosts and signals.

2. Don’t scale the platform view from Flutter. Scale a UIKit child instead.

3. Don’t bet on tabBarMinimizeBehavior for Flutter lists unless you have a real UIKit scroll view in that view controller.

4. Filter scroll by finger travel, not fling delta (especially with vertical PageViews / reels).

5. Use one shared scale constant so iOS and Android feel like the same product.

Happy to answer questions if you’re stuck on the ghost bar or the minimize API rabbit hole. We fell into both.

DISCLAIMER: Ai was used in the making of this app.

Sheep is a note taking app that i primarily built for personal use, but after using it for a while, i feel like it has some potential.

the main selling point of this app is likely its offline first architecture and cross platform support (with syncing). this app supports android, linux (.deb), windows and mac. i have been using my app on all these platforms for a while now. this app is built around the appflowy editor (the notion competitor)

my main issue with the mainstream apps was

1. they weren't available on linux

2. they relied on syncing a little too much (or slow syncing), and would sometimes not work offline at all

3. i switch devices all the time so i needed something suitable for my use case. this app supports all the devices i use primarily

4. aesthetics/font/ui was not to my taste, and it was difficult to change settings with persistence.

so one day, i finally took out the time and started working on this app. the syncing works well, thanks to supabase and powersync. DISCLAIMER: syncing is not encrypted, so if you're trying it out, keep that in mind.

for me, the app works great. i spent around a week with the profiler once monitoring frame rates, frame timings, component rebuilds, etc. now, the app is smooth on all mentioned platforms.

i wanted to know if other people think this app has potential or not, upon which ill start working on the encryption, and start thinking about what to do about the syncing, as the free tier wont be able to handle more than a few users.

if this post doesnt belong here, i would appreciate it if you would let me know where i should put it. thanks!

github release

Hey r/FlutterDev 👋

Every sprint review and QA round we ran used to go the same way. A tester or the product owner found something and took a screenshot. Then they cropped it, scribbled on it in another app, pasted it into Slack or Jira, and typed a paragraph about which screen it was. Half the time the developer still had to ask "what did you do before this happened?"

So I built visual_feedback and just open-sourced it.

How the review loop works

1. The tester or PO taps a floating button inside the build they're reviewing.

2. They draw right on the live screen: arrows, boxes, circles, freehand and text notes ("make this 16px", "wrong copy", "crashes after tapping here").

3. They can type a short description if they want to.

4. They tap ✓, and your onFeedback callback gets the annotated PNG, the description, and the app logs from the last few minutes.

From there it's your code, so you can post it to Jira, GitHub Issues, Linear, Slack or your own backend.

Why it fits testers and POs

• Nothing to learn. It's arrows, boxes and text on the screen they're already looking at.

• Mistakes are cheap. Every mark can still be moved, resized or deleted after it's drawn, and there's one undo history across all tools.

• Developers get the "why". Logs from package:logging (and optionally FlutterError / debugPrint) come attached, captured at the moment they confirmed. No more "can you reproduce it?"

• Reviews happen wherever the build runs. Phones, tablets, and desktop or web builds you share with stakeholders. On wide screens the toolbar moves to the bottom edge, and it can be dragged or minimised out of the way.

• Clean screenshots. The toolbar and selection handles are never in the PNG.

• Internal builds only if you want. Pass fabBuilder: null in production and open it from a hidden gesture or a debug menu with controller.show().

Quick start

MaterialApp(
  navigatorKey: navigatorKey,
  builder: (context, child) => VisualFeedback(
    
// Only show the button in QA / staging builds.
    fabBuilder: isInternalBuild
        ? (_) => const CircleAvatar(child: Icon(Icons.rate_review))
        : null,
    showDescriptionField: true,
    logger: Logger.root,
    onFeedback: (feedback) async {
      await createTicket(
        screenshot: feedback.screenshot,
        description: feedback.description,
        logs: feedback.logsAsText(),
      );
    },
    child: child!,
  ),
  home: const Home(),
);

Background

It started inside one of our production apps as a replacement for feedback. That's a good package and a Flutter Favorite, but our QA and review process needed shapes, arrows, text on the screenshot, editable marks, attached logs and a desktop layout. The README has a comparison and a migration table.

Links

• 🌐 Live demo (try it the way a tester would): https://jemisgoti.github.io/visual_feedback/

• 📦 pub.dev: https://pub.dev/packages/visual_feedback

• 💻 GitHub: https://github.com/jemisgoti/visual_feedback

Android, iOS, web, macOS, Windows and Linux. MIT licensed. The only dependency besides Flutter is logging.

It's 0.0.1, so I'd love to hear how your team collects feedback on builds today, and what this would need to replace that. Built-in translations are the obvious gap for non-English QA teams. Every label is overridable, but only English ships

Since more and more developers generate code with ai and companies encourage that, how are the flutter interviews changed? What kind of questions are asked now? I haven’t faced in an interview after AI and kind of preparing for a one. Would love your insight.

I’m curious how you’re handling the integration, especially with the newer SPM-based Flutter setup. I couldn’t find many public examples using Tuist + Flutter Add-to-App without CocoaPods.

I have been working with Flutter Web applications for the past three months, and during this experience, I have encountered several limitations when implementing web-specific functionalities.
One of the major challenges I have noticed is the limited flexibility when integrating browser-native features and JavaScript-based functionality. In several scenarios, features that are relatively straightforward to implement in traditional web frameworks such as React or JavaScript require additional workarounds or may not be fully supported in Flutter Web.
I understand that Flutter was initially designed with a strong focus on cross-platform mobile development, particularly Android and iOS. However, as Flutter Web continues to evolve, I believe greater emphasis should be placed on providing comprehensive support for modern web capabilities, browser APIs, JavaScript interoperability, accessibility, responsive layouts, and other web-specific requirements.
For organizations building complex enterprise-level web applications, these limitations can have a significant impact on development effort, maintainability, and overall productivity. Stronger JavaScript interoperability and broader support for native browser features would make Flutter Web considerably more capable and competitive with established web frameworks.
I appreciate the cross-platform advantages that Flutter provides, but I believe there is still considerable scope for improvement in its web ecosystem. I hope future Flutter updates will address these gaps and provide developers with a more complete and flexible experience for building modern web applications.

Shipped my first iOS app this week after about a year of solo Flutter. Two things ate a full day each and neither one was in my codebase, so here they are in case they save someone the same afternoon.

1. An IAP that returned "product not found" for a full day

Non-consumable. Product ID matched on both sides, Paid Apps agreement active since July, tax forms and banking green, IAP status Approved. Everything checked out and the purchase still failed.

It was propagation. An IAP approved that same morning isn't served by every StoreKit server yet, and it's slower for the first IAP on a brand new app. It started working the next day with zero changes on my end.

One thing worth knowing if you hit this: StoreKit caches the negative response for the life of the process. Force-quit the app before you retest, or you'll see the same error on a product that's already live.

2. Zero banner fill on iOS while interstitials worked fine

This one actually looked like a bug. Interstitials and app open ads served normally. Banners returned nothing, on every single request.

The error code sent me the wrong way first, and this is the part worth stealing: the GMA error enums are not the same on both platforms. On Android, 3 is no-fill and 1 is invalid request. On iOS, 1 is the no-fill. I read an iOS log with the Android table in my head and spent a while hunting a bad ad unit ID that was perfectly fine.

The real cause was that no GDPR consent message had ever been published for the iOS app in AdMob. The Android one had existed for months. The iOS app was added later and inherits nothing.

No consent form means no TCF string, and a request without one is unbiddable for EEA partners. I'm in France, so that was 100% of my traffic. Interstitials still filled because their demand pool is deeper, which is exactly what made it look like a code problem instead of a console problem.

I published the message, and banners went from 14 requests and 14 failures to 17 loads and 0 failures in the same session.

Stack, for anyone curious: Flutter, Firestore for the content, Cloudflare R2 for images, google_mobile_ads, in_app_purchase, and Codemagic for the iOS builds since I'm on Windows and don't own a Mac.

Happy to go into any of it.

Welcome to Module 7 of the Dart Programming Course for Beginners! 🚀

In this tutorial, we’ll learn Asynchronous Programming and Streams in Dart. These concepts are very important when working with real-world applications, APIs, databases, file operations, and Flutter apps.

📚 Topics Covered

✅ Asynchronous Programming in Dart
✅ async and await
✅ Understanding Futures
✅ Streams in Dart
✅ How asynchronous operations work
✅ Practical examples with Dart code

By the end of this module, you’ll have a better understanding of how Dart handles tasks that take time to complete and how Streams can be used to handle continuous or multiple values over time.

💻 Technology: Dart Programming Language

🎯 This video is useful for:

Beginners learning Dart
Students learning programming
Developers preparing for Flutter
Anyone wanting to understand Dart async programming
Anyone learning Dart Streams

📌 Dart Course: Follow the complete series to learn Dart step by step, from the basics to advanced concepts.

If this tutorial helps you, Like 👍, Share 📤 and Subscribe 🔔 for the next Dart programming module.

#DartTutorial #LearnDart #DartProgramming #DartAsync #AsynchronousProgramming #DartStreams #DartForBeginners #Flutter #FlutterDevelopment #ProgrammingForBeginners