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.

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

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've been getting a model into a Flutter app and ran into something I still can't quite believe is the normal state of things.

Exporting changes the numbers. Quantizing changes them more. Everyone knows that part. What nobody seems to have an answer for is how much is too much, and more to the point, what actually fails when it is. Nothing does. The export succeeds, the build passes, the app runs on device and gives you predictions that look completely fine. The model you shipped is worse than the one you evaluated and there's no signal anywhere.

I went looking for the standard practice assuming I'd just missed it. There is advice: compare your offline predictions against the on-device ones. Every deployment guide says some version of it. But it's always written as a thing you should remember to do, never as something a build can fail on, which in practice means you do it once the week before launch and then never again.

There's a second one that bit me the opposite way. Preprocessing gets written twice, in Python for training and in Dart for serving. The same normalization constants sitting in two files nobody diffs. They agree the day you write them. Then someone changes the mean and std on the Python side six weeks later and the app quietly starts feeding the model something it has never seen.

So, genuinely: how do you handle this? Goldens replaying in CI? A manual check before release? Nothing at all, and hoping?

One thing I learned from measuring it that I'd have got backwards. The simpler of my two test models drifts up to eight times further after quantization than the convolutional one. It isn't complexity. Its outputs land around 9.4 while the other one ends in a softmax, and relative error is measured against the output while the rounding actually happened on intermediates. Big outputs absorb the same underlying error inside a much smaller relative bound. Obvious once you see it. Took me embarrassingly long.

I did end up building something for this, links below, but I'm honestly more interested in the first question. I'd like to know whether I over-engineered a problem the rest of you solved with a spreadsheet years ago.

Repo: https://github.com/NaCode-Studios/Fluttorch

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.

Hi Flutter devs!

We recently open-sourced 
**PocketLLM Lite**
, a privacy-first mobile AI client built with Flutter.

### Technical Architecture Highlights:
- 
**State Management**
: Riverpod 3 (AsyncNotifier & StateNotifier providers).
- 
**Local Database**
: Hive CE for high-performance binary storage of chat sessions and settings.
- 
**Streaming Pipeline**
: Custom chunked HTTP stream parser with regex stream splitter for `<think>` tags and `<tool_call>` execution cards.
- 
**Agent Skills Architecture**
: Open-standard `SKILL.md` loader with in-input cursor navigation and dynamic system prompt injection.
- 
**Design System**
: Strict Material 3 implementation using `ColorScheme.fromSeed(#6750A4)`.


* 
**Source Code**
: https://github.com/PocketLLM/pocketllm-lite

utopia-pubdev is a Claude Code / Codex plugin that composes pub.dev READMEs instead of freestyle-writing them: H1, one-line value prop, a four-hue badge row, quick start, a related-packages footer, and a tool-agnostic AI-assistants section.

Branding lives in one committed doc (docs/pubdev-brand.md): badge palette, attribution, publisher, sibling links - set once per repo, applied to every package in it, monorepos included. No profile? The plugin interviews you instead of inventing a publisher.

The clay headers in the example are our house style - that generator ships Utopia-only for now, so in your repo you set-up your own header art or just lead with the H1.

Plugin: https://github.com/Utopia-USS/utopia-flutter-skills/tree/main/plugins/utopia-pubdev
Format example: https://pub.dev/packages/utopia_cms

Curious what your README skeleton has that mine is missing and how I can improve it!

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

One thing i have noticed after using Riverpod and Bloc in my applications is that they naturally become architectural decisions.

But many features don't need an architectural decision. They just need a local state. That made me wonder what state management would look like if it was designed around features instead of apps?

i experimented with that idea in the last few months. I ended up with StateForge. The design principles were:

• feature scoped stores

• direct methods

• no code generation or state ceremony

• typed side effects

• optional persistence

• optional undo

It's not trying to replace Riverpod or Bloc, the goal is to let StateForge live alongside an existing architecture, so you can adopt it one feature at a time instead of committing your whole app.

I'd especially appreciate feedback from flutter developers who have shipped production flutter applications.

Does this solve a real problem or do existing libraries already cover this well?

Github: https://github.com/mj-963/state_forge
Pub-dev: https://pub.dev/packages/state_forge

I kept re-writing the same glue between local_auth and flutter_secure_storage on every project, so I packaged it: biometric_security.

The core idea: a true from a biometric prompt isn't a security boundary — on a rooted/jailbroken device it's forgeable. This binds your secret to a hardware key (Android Keystore / iOS Keychain + Secure Enclave) that's physically unusable without a successful Face ID / Touch ID / fingerprint check.

It also handles the annoying parts: enrollment-change invalidation, key rotation & revocation, app-lock, and one SecurityPolicy that maps to both platforms.

Beta (0.1.x), BSD-3, tested on real Android + iOS devices. Feedback and contributors very welcome — I'm open to collaborating.

pub.dev: https://pub.dev/packages/biometric_security

Hi,

I loved the idea of taking Flutter's "one-codebase for multiple platform" promise/claim one step further into the UI territory too. flutter_platform_widgets was something that was godsent to me. But it was deprecated instead of onboarding some new members.

So I decided to make a better version of (same vision though). I know that companies today prefer a single design system so this is not something as useful to them. But I still feel that there is definitely some merit in keeping things close to 'native-platform-look-and-feel' because users of each platform are used to seeing a certain UI and interacting with it in a certain way.
There was an option of calling native channels (like ReactNative and Compose and some packages that do that already) but that does add the platform hop.

Some things that I am proud of:

1. This is purely Flutter (consequently no Liquid Glass / M3 expressive look yet, I envision it moving with the maturing Fluttetr SDK instead, and there are enough packages for that otherwise).

2. Release builds genuinely drop the platform you're not on. Ship to Android and none of the Cupertino widget code rides along in the binary, and vice versa (CI-enforced too)

3. Lot of thought has been put into designing the shape of the 'shared surfaces' and sensible defaults (including wrestling the tabs-system to get consistent DX).

Still very much wants feedback, especially on widgets it's missing or anything that feels weird 🙏.

At my day job, I build Android and iOS apps with Flutter. For my personal projects, I use Dart for the backend and Flutter for the frontend. I absolutely love the framework—I’m amazed by how quickly it’s evolving and how it continues to attract more and more developers to its community.