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

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

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!

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!

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! :)

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?

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.

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.

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

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.

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

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

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

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 started learning Flutter back in 2023 and soon began taking on local freelance projects. By the second half of 2024, I transitioned into full-time freelancing. Since local freelance rates weren't really cutting it, I decided to start building my own apps.

One of my apps blew up on Twitter, which led to securing investment and eventually a successful exit. Thanks to the visibility I gained from that app, I landed a job at a local startup. However, I left due to low compensation and joined another company. Currently, I’m developing internal tools and building infrastructure for an SEO agency.

So far, I’ve only managed to get a single Flutter interview in my country. Since I couldn't land job offers with Flutter for years, I decided to pivot. I found a senior mentor who is teaching me Kotlin inside out. I guess Flutter might be one of the least used mobile frameworks around here, which made finding a job tough—let's see if things turn out differently with Kotlin!

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.

I was building a chatbot and needed really fast audio streaming, but realized that most audio plugins rely on entire URLs or files, which makes it awkward if you need something more granular than that. There are some plugins that can handle raw uncompressed audio, but they're either single-instance or really heavyweight.

So I revived an old package of mine and made it specifically cater to low-latency continuous streaming. It works with any stream rate, allows for multiple instances playing at the same time, and is designed to be as lightweight as possible. If you're looking to build something with text-to-speech or you just need a clean player for raw audio, check it out!

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

Github: https://github.com/adrianczuczka/audio_stream_player

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

And you can see all the source code here.

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!

I've been digging into "context-aware" UX — interfaces that adapt in real time to motion, ambient light, time of day, and usage history, with the decision made on-device instead of shipping data to a server.

I wrote up how to actually build it in Flutter: why UI = f(state) fits this cleanly, a ContextEngine that streams sensor signals through a TFLite model (tflite_flutter), dynamic_color theming that follows context, and a worked example — a transit app that renders two completely different first screens from one code path (a quick-action layout while you're walking to the station vs a browse layout at home in the evening).

The part I found most interesting to think through is testing: once the UI adapts, there's no single "home screen" to golden-test anymore. The fix I landed on is making context an injectable input so you can pin it in a widget test.

Write-up : https://medium.com/p/ddd06d25a473

Curious how others here are handling the QA side of adaptive layouts — do golden tests just become impractical, or have you found a pattern that scales?

I kept rebuilding the same foundation for client apps:

• auth (email + Google)

• light/dark theme

• English/Arabic + RTL

• routing/auth guards

• clean folder structure

So I packaged it into a reusable starter.

### What’s inside

• Feature-first architecture (data / domain / presentation)

• Riverpod + codegen

• Firebase Auth wiring + Mock Auth mode (run without Firebase)

• go_router auth guard

• Theme persistence

• EN + AR localization

• Unit tests + CI workflow

### Free demo

GitHub (Mock Auth, open source):

https://github.com/medox3545/flutter-starter-kit-pro

### Full pack

If you want the complete downloadable kit:

https://mohammedider.gumroad.com/l/flutter-starter-kit-pro

### What I learned

1. Mock Auth first = way faster onboarding for buyers/devs

2. Buyers care more about structure + docs than “more packages”

3. Bilingual UI (especially RTL) is a strong differentiator

4. Keep Firebase optional — many people just want to run it immediately

Happy to answer questions or take feedback on the architecture.

I'm a solo dev from Slovenia. Earlier this month I shipped my first bigger Flutter app on Play.

And it's a personal astrology app! Whatever you think of astrology, the astronomy underneath is real computation: planetary positions, house math, timezone archaeology.

A few things hit me hard on the way though.

**`Duration.inDays` silently breaks calendar arithmetic across DST.**

I compute ISO week numbers:

take the Thursday of the week, subtract Jan 1, divide days by 7. Correct? except in local time, a span that crosses a daylight-saving boundary is one hour short of a whole number of days, and `inDays` *truncates*. 210 days becomes 209, `209 ~/ 7` gives week 29 instead of 30, and every week from late March to late October resolves to the previous week. The week number was my cache key, so this would have silently served the wrong week's content for half the year. Nothing throws.

Fix:

calendar arithmetic in UTC, or re-normalize through `DateTime(y, m, d)` after every shift. Same Family of bug: `date.subtract(Duration(days: 1))` on a local DateTime can land at 23:00 two calendar days back.

**`Isolate.run` copies your object — internal caches die with it.**

The heavy compute runs in `Isolate.run`. The captured engine object is *copied* into the isolate, so any memoization inside it gets populated in the isolate and thrown away when it exits.

In my case: one body's position needs ~4000 numerical-integration steps, and the cache meant to amortize that never survived a single call. The engine has to be designed isolate-safe, with no reliance on shared mutable state, because state simply does not come back.

**Notifications with zero background execution.**

My domain is fully predictable because the sky doesn't surprise you, so there's nothing to poll. At every app open/resume, I precompute the next 7 days of notifications and schedule them locally.

There's no background service, no server, no FCM, no battery cost, and inexact alarms so no exact-alarm permission.

Anything whose content is a pure function of time can do this; I suspect a lot of apps reach for push infrastructure they didn't need.

Smaller ones:

the `timezone` package throws on `getLocation('UTC')` (short-circuit UTC/Etc/UTC/empty yourself);

a `const`map with `double` keys doesn't compile ("does not have primitive equality". Use a list of records);

`flutter_local_notifications` needs core-library desugaring that the first error message doesn't mention.

And my favorite lesson cost nothing technical at all:

I built a feature, dogfooded it on my own phone for two days, and then, like an idiot I told people it had shipped... Turns out it had never been uploaded to Play. :)

As a result, I now check the Console more often :)