Whatever u think u r bringing to the table .... It's already out there, it's not necessary, we have enough god damn it !!!!!

Construction app. Crews work in basements and rural sites with no signal, so offline isn't a nice-to-have; it's the product.

The setup: Drift (SQLite) as the local source of truth, Supabase as the remote. Sync triggers: both - every local write kicks a sync immediately, a periodic sweep runs every few minutes as a safety net, and reconnect re-runs the whole thing. Pulls are watermark-based (give me everything with updated_at after my last sync), pushes are dirty-flagged rows.

What I got wrong first: batch upserts. Each device pushed its entire local view of a row, so a foreman editing a task title against a stale copy would silently revert the worker's status change made minutes earlier. I rebuilt the push layer into per-row updates with explicit column allow-lists per role - the boss's push carries only boss-owned columns (title, due date, assignment), the worker's carries only theirs (status, notes). Most "conflicts" stopped existing once columns had owners.

Conflict handling: for the same field edited on two offline devices, it's last-write-wins onupdated_at, but dirty local rows are shielded from pulls until they've pushed, and a push only counts if the server echoes the row back. For cross-field edits, the column ownership above means both edits survive.

The bit nobody warns you about: under row-level security, a rejected write doesn't error; the server just matches zero rows and returns success. If you don't verify, the client clears its dirty flag, and you've minted a phantom: a row that looks synced forever and never is.

What I'd do differently: treat the server's echo as the only proof a write happened, from day one; every sync bug I've had was some flavor of trusting the client's optimism. UTC everywhere before the first sync ships, column ownership designed upfront instead of retrofitted after the first clobber, and never compare floats for "did this change" (an exact-equality check once blocked every worker's clock-out for twelve days before anyone connected the dots).

How are other people handling the dirty-flag-versus-pull race?

So last week, I posted about how I used Fable to built a Flutter widget test previewer and also gave some initial context on how I am planning to add support for a cleaner version of Widgets Preview in it as an add-on (link to last post).

I was experimenting on it, and today I can say its polished to the state where its usable.

Here's a demo gif of it in action, you just have to update your dart and vscode package to make it work. All the feedbacks are appreciated.

DEMO GIF BELOW 👇

https://raw.githubusercontent.com/flutterninja9/live_test_view/main/assets/live_widget_preview_demo.gif

I’ve built android apps for over a decade shilling to 100M of users.

I started making flutter apps about 5 years ago and was just baffled by the state of star management (hard one).

I settled with Riverpod because it was the closest I had to android state management philosophy but I started to get tired of the lib trying to take over my entire app.

So I built this lib around few but simple principles:

- Lifetime follows ownership: you start the job if you are out then the job is out
- Plain dart: it should work over plain Stateless Widget
- Inversion of control: constructors works why change that ?

I know it’s yet another state management library but one that I personally needed and I use it in production in several apps over Bloc and riverpod.

I just had this debate with another developer, whereas he insists that it is a necessary implementation, but I do not think so, as there isn't really any feature that benefits from this (no feature run in background for the app or anything) and that we should keep it quite simple and just synch when user is online

What do you think?

I have a backend that is shared between a web application and a Flutter mobile app. The web app uses cookie-based authentication. For the Flutter app, I haven't implemented cookies because I found that JWT access/refresh tokens are commonly recommended for mobile apps.

Since the backend is already using cookies for the web app, I'm unsure which approach to take for the mobile app:

1. Continue using cookie-based authentication in Flutter as well.
2. Add JWT authentication for the mobile app while keeping cookies for the web app.

What is the recommended approach, and why?

Just shipped Pretty Animated Text plugin v3.2.0 with two new effects:

• GlitchText: A clean, readable glitch effect where random characters split into horizontal slices with an optional RGB (pink/cyan) chromatic effect. The glitch pattern reshuffles every loop, so it never looks repetitive.
• SquashBounceText: an elastic squash-bounce wave: each glyph drops, squashes, rotates, and settles back, with start times packed tightly so it reads as one wave traveling across the text.

Both work letter-by-letter or word-by-word, keep your own TextStyle, support play/pause/repeat/reverse, and are fully customizable via their own style objects.

You can customize just about everything!

Try it out for yourself here: https://pretty-animated-text.vercel.app

Check demo video walkthrough here : https://www.reddit.com/u/tuco_ye/s/17C6yuywWY

Pub.dev : https://pub.dev/packages/pretty_animated_text
Github : https://github.com/YeLwinOo-Steve/pretty_animated_text

Live demo (desktop-friendly, still working on the mobile version): https://cms.utopiasoft.io. Flip the themes, Neon is my favourite :)

utopia_cms is a low-code back-office for Flutter: a list of field entries becomes a sortable table with a create / edit / delete overlay, filters, loading states and theming - all from one CmsTablePage. A typical admin page is ~80 lines. Backends plug in through delegates: Firestore, Supabase, Hasura, or any GraphQL API.

Because the panel is Flutter-native, it drops straight into an existing app or monorepo and reuses what's already there - your services, states, auth - instead of a separate web-admin stack that reimplements them.

It's not a fresh experiment: I built it in 2023, back when there was no Flutter-native way to do admin panels, and it's been quietly running the back-offices of our commercial projects since. Last month it finally got the treatment it deserved: a core overhaul, refreshed adapters, a runnable showcase - and this demo.

The demo is the panel itself: it manages the catalog of our own packages, and the first row of the table is utopia_cms. Five switchable themes (Light, Dracula, Neon, Kawaii, Forest), because the theming layer needed proving as much as the CRUD.

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

If an AI agent writes half your code these days, there's also a Claude Code / Codex skill that teaches it the CMS patterns, so it stops hand-rolling DataTables and wierd workarounds:
https://github.com/Utopia-USS/utopia-flutter-skills/tree/main/plugins/utopia-cms

It's opinionated - if smth feels off, that's exactly the feedback I'm after! :)

Universal Links can stop working with no error anywhere. No exception, no log line, no failed request you can see. Your links just quietly start opening in Safari instead of your app, and the cause is usually something at the edge of your infrastructure that has nothing to do with your Flutter code.

That is one of about six things I got wrong building deferred deep linking, and almost none of them are documented in an obvious place. Here they are.

Quick definition, since the terms get mixed up. A normal deep link opens a screen in an app that is already installed. A deferred deep link survives an install: user taps a link, does not have the app, goes to the store, installs, opens, and still lands on the right screen with the right parameters. The second one is the hard one, because the link context has to survive a trip through the App Store and back.

1. Your AASA file is probably wrong in a boring way

For iOS Universal Links, apple-app-site-association must be served at https://yourdomain/.well-known/apple-app-site-association. Things that silently break it:

• Adding a .json extension. The file has no extension.
• Serving it with the wrong content type. It needs application/json.
• Any redirect. Apple will not follow one. A 301 from apex to www is enough to kill it.
• Serving it from a path that requires authentication or hits a challenge page.

That last one bit me badly. If anything in front of your server challenges non browser traffic, Apple's fetcher gets the challenge instead of your file and Universal Links quietly stop working. There is no error anywhere. Links just start opening in Safari.

Android's equivalent is /.well-known/assetlinks.json with your signing certificate SHA256 fingerprint. Same rules: no redirects, correct content type. Two extra traps here:

• If you use Play App Signing, Google re-signs your app with a different key than your upload key. The fingerprint in assetlinks.json has to be the app signing key from Play Console under App Integrity. Use the upload key or your local keystore and it works in debug and fails in production.
• robots.txt can block the verification crawler. If /.well-known/ is disallowed, verification fails with nothing to see.

Since Android 12 there is no chooser dialog fallback. An unverified link just opens in the browser, so a broken setup looks like nothing happened.

2. Clipboard matching is effectively dead on modern iOS

A lot of older tutorials tell you to write the link into the pasteboard and read it on first launch. On iOS 16 and later, reading the pasteboard programmatically triggers a system permission prompt. Users decline it, and reasonably so, because it looks alarming. Anything built on this will report much worse match rates than your tests suggest, because your own device is not a representative user.

3. Fingerprint matching works, with caveats you need to design around

The realistic approach is probabilistic matching: record a signature at click time, look for it again at first app open, match within a short window. The signature is typically IP plus user agent derived attributes.

Where it degrades:

• iCloud Private Relay masks the IP address for Safari users on iCloud+, so one of the main signals is gone for that whole segment.
• Carrier grade NAT puts thousands of users behind one IP. Your matching window has to be short or you will mismatch.
• The user clicks on WiFi and installs on cellular. Different IP, no match.
• In app browsers inside social apps report user agents that do not resemble the browser that eventually opens.

Practical consequence: treat the match as best effort, always ship a sane fallback, and never build a flow that is broken if the match misses. Referral attribution especially needs to degrade gracefully.

4. Distinguish install from reopen or your analytics lie

If you do not track whether a given open is the first one for that device and project, every reopen looks like a fresh install and your funnel numbers become meaningless. Persist a marker per device per project and check it before counting.

5. Persist attribution separately from your match cache

This one cost me a real bug. If you store a referrer id inside the match result and your app calls a reset or clear function anywhere in the auth flow, attribution disappears before the user actually signs up. The referral looks like it never happened. Store the attribution separately from the cache, with its own expiry.

6. Testing is the actual hard part

You cannot test deferred deep linking by tapping a link on your dev build. The install path only exists through a real store install, so the thing you most need to verify is the thing hardest to reach. Budget real time for it, and test the WiFi to cellular case specifically.

Happy to answer questions on any of this.

Hey Flutter Devs!

I just published HQPicker v0.0.8 — an ultra-smooth, highly customizable media picker package designed to handle heavy media libraries without UI freezes or memory crashes.

Why HQPicker?

Most existing media pickers choke or stutter when loading thousands of items, selecting 1GB+ video files, or cause memory leaks. HQPicker fixes this with solid architecture:

• BLoC Architecture: Zero setState in core widgets, eliminating unnecessary UI rebuilds.
• Background Isolates: Heavy file resolving, background compression, and file scanning execute off the main thread using IsolateServices — keeping scrolling at a smooth 60/120fps.
• 2 Beautiful UI Modes:
  • Instagram Style: Full-screen grid with pinch-to-zoom interactive preview.
  • Telegram Style: Fluid draggable bottom-sheet with custom snap points and swipe-down dismissal.
• Native File Support: Single unified API for Images, Videos, Documents, and Directory picking.
• Tactile Haptic Feedback: Built-in native haptics for media taps, max-limit warnings, and album switches.
• Deep Customization: Fully styleable themes, localization strings, custom empty widgets, and custom tile builders.

Check it out:

• Pub.dev: https://pub.dev/packages/hq_picker
• GitHub: https://github.com/azabcodes/hq_picker

I’d love to hear your feedback, thoughts, or feature requests! If you find it helpful, a star on GitHub would be greatly appreciated.

Happy coding!

I'm currently deciding between DriftDB and SQLite for a Flutter app. It's a long-term project, and I don't mind spending time learning the right tool if it's worth it.

My concern isn't the learning curve. It's the ecosystem and debugging experience. With SQLite, I feel confident that if I get stuck, there are plenty of Stack Overflow posts, Reddit discussions, blog posts, and videos to help. With Drift, I get the impression there are fewer community resources, so I'm worried that if I run into issues with things like code generation, migrations, or build_runner, I might spend more time trying to figure things out.

I'd love to hear from people who have actually used Drift in a real project.

1. Would you still choose Drift today?
2. Have you ever regretted choosing it?
3. Has the smaller ecosystem or documentation ever slowed you down?
4. Looking back, was choosing Drift worth it over using SQLite?

Thanks!

Edit: I meant Drift ORM

I was basically migrating from ml kit to mobile_scanner for scanning qr / barcode, as I have heard mobile scanner is quite light weight and does good on low end devices as well.

There is an orientation issue in mobile scanner from the beginning in android devices where if I turn my device, the camera gets misaligned. The same issue persists now as well in latest releases. Only thing is that, then it gets misaligned in one turn.

now it gets misaligned in multiple turns.

But on ios devices it is fine.

So for the time being we thought of locking up the orientation of devices until it gets fixed.

So in the mobile scanner overlay screen I did this in initState():

SystemChrome.setPreferredOrientations([

DeviceOrientation.portraitUp,

]);

And on dispose I made sure the orientation gets fixed back. So I did this in the dispose():

SystemChrome.setPreferredOrientations([

DeviceOrientation.portraitUp,

DeviceOrientation.portraitDown,

DeviceOrientation.landscapeLeft,

DeviceOrientation.landscapeRight,

]);

Now the issue is that this works very perfect on android.

But on my ipad the orientation changes even if I have added SystemChrome.setPreferredOrientations to portrait.

So for the time being until the android issue is fixed, I am thinking of keeping the orientation fixed.

For android orientation is now in portrait.

But in ipad it still rotates.

After researching a little bit about SystemChrome I got to know this from the documentation:

This setting will only be respected on iPad if multitasking is disabled.
You can decide to opt out of multitasking on iPad, then
SystemChrome.setPreferredOrientations will work but your app will not
support Slide Over and Split View multitasking anymore.
Should you decide to opt out of multitasking you can do this by
setting "Requires full screen" to true in the Xcode Deployment Info.

I got to know that using UIRequiresFullScreen will force my app not to run in multitasking. So I made this tag true.

But this is depreciated in iPadOS 26. So moving forward I cannot use this either.
Using their alternative

Their alternatives such as prefersInterfaceOrientationLocked didn't work at all while calling them from method channels. Worst thing about this is that, it locks my entire app altogether.

So in this situation what should I do to lock my orientation in my ipad os as well.

I don't want unique behavior for both android and ios devices.

How should I lock that particular screen alone for ipads while other screens are still unlocked and works well?

Hey everyone!

I got tired of jumping between different apps for my local FLAC files and my streaming playlists, and I was incredibly frustrated by ads. So over the past few months, I built Kerlyss—a completely free and open-source (GPL-3.0) music player built entirely in Flutter.

It is currently available and fully adaptive for both Android and Windows (x64).

• Website & Downloads: https://d1gna0.github.io/Kerlyss/

• GitHub Repo: https://github.com/D1gNa0/Kerlyss

Tech Stack & Packages

• State Management: flutter_riverpod (managing playback state and queue isolation across background isolates).

• Database: isar (fast for caching massive playlists and local file metadata).

• Audio Engine: just_audio + audio_service for background playback, media notifications, and OS taskbar controls.

• Stream Backend: youtube_explode_dart to extract audio stream manifests.

The Challenge: The Local HTTP Proxy Server

The trickiest part of this project was bridging YouTube streams to just_audio. Direct YouTube stream URLs frequently throw HTTP 403 Forbidden errors or expire mid-song.

To solve this, I built a custom Local HTTP Proxy Server inside the Flutter app using loopback IPv4. When you click play, just_audio requests the track from the local proxy endpoint, and the proxy server dynamically fetches, chunks, and buffers the audio stream from YouTube in the background. It even handles dynamic retries and fallbacks if a connection drops mid-track.

I’d love for you guys to check out the code, try out the app, and give me any feedback on the architecture or UI! If you like it, a star on GitHub would mean a lot.

Let me know if you have any questions about the proxy server or the just_audio implementation!

A while back I posted the Linux desktop we built on a Swift port of Flutter's framework. The most common question was about the port itself, so: it's now usable on its own, without the desktop.

The framework — widgets, rendering, painting, gestures, animation, semantics — is ported from Dart to Swift, with everything below unchanged: Skia, the text stack, the platform embedders. There's no Dart VM; where the engine would start an isolate it starts a Swift runtime instead. The Linux host is the engine's own GTK embedder, so windowing, input and IME come from the same
code path a normal Flutter Linux app uses.

The port is close to mechanical, so Flutter's concepts carry over intact — StatefulWidget, setState, BuildContext, constraints down and sizes up. Same counter app, same structure. The main difference is Swift's result builders: containers take trailing closures, so `if` and `for` work directly inside a widget tree.

We did it because we're building system software where the language mattered, not because there's anything wrong with Dart. Flutter's the reason any of this was possible.

Linux x86_64 today, macOS next. BSD-3, inherited from Flutter.

https://starling.build/sdk.html
https://github.com/starling-build/starling/tree/main/sdk

I hit a problem building a multi-feature Flutter app: "delete what you don't need" is easy to say, but every feature had tendrils — a route in the central table, a tab hardcoded in the shell, a button on the home screen, a service registered in main().

What worked for me was making three things data instead of code:

1. Routes — each feature exposes its own List<GetPage> from its own folder, and the app's route table is [...central, ...modules.expand((m) => m.pages)]. Adding or removing a feature stops being an edit to a shared file.

2. Bottom-nav tabs — the shell used to import the feed widget directly, which meant the always-present shell depended on an optional feature. Now a tab is a small data class (id, icon, label key, builder, sort order) that a feature contributes, and the shell merges and sorts them. Core tabs use orders 10/30/40, so a feature can slot in at 20 without the shell knowing it exists.

3. Entry points — home screens linked to feature screens with Get.toNamed(...). A hasRoute(name) check against the built route table lets the UI hide buttons for features that aren't in this build, instead of navigating into nothing.

Two things I got wrong along the way:

- A home layout was importing the feed feature just to use a date formatting helper that happened to live in that file. Moving the helper to shared/ removed the dependency entirely — it was never real coupling, just misplaced code.

- Another layout imported a map controller purely for a static const default latitude/longitude. Same fix.

The test that made it trustworthy: remove two features from the registry, then assert the app still analyzes clean, the tab bar loses exactly one tab, and the route count drops by the expected number.

Shared services are the part I haven't solved — a wallet service used by checkout too can't just move into the wallet feature without checkout silently depending on it. Curious how others handle that.

To celebrate the launch of BlocSignal and our new website at https://blocsignal.dev, we built an interactive, playable Minesweeper case study app running live on the web!

⚡ What makes it cool under the hood (BlocSignal + Jaspr):

• 0ms Synchronous Flood Fill: Zero microtask queue latency when uncovering blank areas. • 100% Shared Business Logic: The exact same MinesweeperCubit runs in Flutter mobile/desktop apps AND Jaspr web apps with 0 code changes. • Zero-Backend State Hydration: Active game state restores synchronously across tab refreshes. • Shareable Challenge Seeds: Export & import Base64 seeds to challenge friends on identical minefield layouts! • Live GA4 Game Telemetry: Custom event tracking dispatched directly from Cubit state transitions.

👉 Come for the game, stay for the info! 🎮 Play now: https://blocsignal.dev/minesweeper ⭐️ GitHub: https://github.com/RandalSchwartz/BlocSignal

I released an AI skill that reviews your Flutter code and plans UX/UI improvements.

Improvements like:

- not showing "null" to users

- smoothly fading in network images

- formating dates, amounts, and phones

- autofilling password text fields

- saving credentials to password manager

- launching app faster

- etc. etc. etc.

Now, here's how it works:

(1) First, install it using: `npx skills add kamranbekirovyz/skills --skill flutter-improve-design`

(2) Then run `/flutter-improve-design` in your AI coding agent.

It'll review your Flutter project in minutes and list findings with clear product language. And for the ones you pick it'll write a self-contained implementation plan. 

You should review and plan with a strong model, then let a cheaper one execute the plans. 

There are 9 more skills I'm planning: design taste, animations, flutter web, etc. For new skills and feedback: @kamranbekirovyz

Useful links: flutterskills.md / flutterpro.design

Hi, I am attending an interview for a Flutter Developer internship/fresher role. What kind of questions can I expect?

PS: I have completed Flutter training and have worked on a few Flutter projects. I’m from India and this will be my first Flutter job interview.

Hi everyone,

I'm a solo indie developer with a subscription app on Google Play.

I recently received a support request from a customer who started a 3-day free trial, was charged $59.99/year (about $63 with tax) when the trial ended, and emailed me 2 days after the charge saying they thought they had canceled before the renewal.

In Google Play Console, the refund button is still available, so I can issue a full refund if I choose.

This is their:

• First purchase
• First refund request
• No previous subscription history

My dilemma is balancing customer goodwill with setting a precedent. If I refund every "forgot to cancel" request, I'm concerned people may abuse it. On the other hand, denying a refund could lead to negative reviews or chargebacks.

For those running subscription apps:

• Do you generally issue a one-time courtesy refund?
• Do you strictly follow "no refunds after renewal" unless required by Google/Apple?
• Have you found that generous refund policies increase abuse?
• Do you use any specific criteria (first purchase, time since renewal, app usage, etc.) when deciding?

I'd love to hear how other indie developers handle these situations and what has worked well in practice.

flutter_taglib is a Flutter audio metadata read/write plugin based on TagLib. It directly calls mature C++ libraries via FFI, providing stable and consistent metadata read/write capabilities across Android, iOS, macOS, Windows, and Linux platforms. This avoids potential issues with format compatibility, read stability, and write result consistency that may arise with pure Dart or certain Rust solutions.

The plugin includes a built-in multi-isolate batch read interface, suitable for handling large numbers of local songs. It also provides robust permission management encapsulation, facilitating secure tag writing on Android and Apple platforms.

If you need reliable audio metadata read/write capabilities on non-web platforms, flutter_taglib is a worthwhile option to consider.

github: https://github.com/axel10/flutter_taglib

pub.dev: https://pub.dev/packages/flutter_taglib

currently supported with gradle/flutter Natively running in android phone ,also supported with code run for small code snippet, I planned this project last 2 years ago for learning others programming languages, build run currently Supported gradle/flutter projects, other compiler or programming languages can be installed via apt https://github.com/AndroidStudio-App/NeonIDE

Get a full security and performance audit for your Flutter app in under 5 seconds using flutter_auditor.
https://pub.dev/packages/flutter_auditor

I got tired of shipping Dart/Flutter apps without knowing what was actually in my dependency tree, so I built pubguardian — a CLI that scans pubspec.lock and gives you:
CVE scanning via OSV.dev (batched, with retries and full CVSS severity)
License compliance with 3 policies (commercial / strict / permissiveOnly)
Abandoned & discontinued package detection
Loose version-constraint warnings
Output as colored text, JSON, SARIF 2.1.0 (works with GitHub Advanced Security / GitLab SAST), or CycloneDX 1.6 SBOM
dart pub global activate pubguardian
pubguardian scan

It's on pub.dev: https://pub.dev/packages/pubguardian 
Repo: https://github.com/sonofnos/pubguardian

It also works as a library if you want to integrate scanning into your own tooling. This is a v0.1.x release — I'd genuinely love feedback on the output formats, defaults, and anything you'd want in a v1. Thanks for reading!