Hey everyone,

Whenever I needed advanced WebView capabilities in Flutter—such as headless execution, modal in-app browsers, typed bidirectional JS-to-Dart RPC bridges, or fine-grained load progress handling—the standard choice was almost always flutter_inappwebview.

While powerful, it often adds significant binary weight (~5–8 MB) and relies on a large custom native platform layer that can be tricky to debug across OS updates. On the other hand, Google’s official webview_flutter is lightweight and uses native Pigeon bindings, but requires tons of boilerplate for common patterns (like reactive rebuilds, JS promise handling, or desktop support).

To bridge this gap, I created webview_ultra.

What it does differently:

Lightweight Core (~200 KB): Built directly on top of the official webview_flutter Pigeon engine for Android, iOS, and macOS, paired with Microsoft Edge WebView2 on Windows. Zero extra native bloat.

Zero-Screen-Rebuild Reactive State: Instead of calling setState on every URL or progress update, WebviewUltraController exposes granular ValueNotifier instances. Subtrees update independently using widgets like WebviewTitleBuilder, WebviewProgressBuilder, and WebviewHistoryBuilder.

Typed Bidirectional JS Bridge: Send and receive typed JSON-RPC messages and Promises between Dart and JavaScript with cross-compatibility for window.webview_ultra.callHandler(...).

Turnkey Features Included:

Drop-in 1-line widget with built-in progress indicators and pull-to-refresh

HeadlessWebviewUltra for off-screen tasks (token parsing, preheating, scraping)

InAppBrowserUltra modal wrapper

Regex-based content and ad-filtering

Quick Example:

Dart

// Reactive progress + 1-line setup without rebuilding the parent widget

Scaffold(

appBar: AppBar(

title: WebviewTitleBuilder(

controller: controller,

builder: (context, title, _) => Text(title.isEmpty ? 'Loading...' : title),

),

bottom: PreferredSize(

preferredSize: const Size.fromHeight(2.0),

child: WebviewProgressBuilder(

controller: controller,

builder: (context, progress, _) => progress < 1.0

? LinearProgressIndicator(value: progress)

: const SizedBox.shrink(),

),

),

),

body: WebviewUltra(

controller: controller,

initialUrl: 'https://flutter.dev',

pullToRefresh: true,

),

);

Links:

pub.dev: pub.dev/packages/webview_ultra

GitHub: github.com/Narukarudra10/webview_ultra

I’d love to hear your thoughts, feedback, or any edge cases you've run into with WebView state management in Flutter!

Been building a lifting tracker (JustLiftin') for a while and the screen people screenshot the most is the muscle heatmap, the silhouette that lights up whatever you trained that day. First version was SVG polygons like every other app and I hated how the highlights just snapped on and off. So I rebuilt it in Rive with the state machine living inside the asset, one boolean per muscle on a view model, and the widget just flips booleans.

I had the Flutter wrapper sitting on GitHub as a sample app for months, but "copy these two files and this .riv into your project" always felt bad, so I finally made it a proper package: rive_muscle_heatmap

Integration is basically this:

```dart await RiveNative.init(); // once at startup

AnatomyHeatmap( activeMuscles: {Muscle.pectoralisMajor, Muscle.biceps}, ) ```

The .riv is bundled with the package so there's zero asset setup, and there's a MuscleGroup enum if you want chip pickers for chest / quads / etc. Muscles animate between states instead of snapping, which was the whole point of the exercise.

What's free: front view, 19 muscles, on/off highlighting, MIT code. The asset itself has a seperate license, tldr: use it in any app including paid ones, just don't resell the file on its own.

What's not free, so nobody finds out after the fact: the back view, the female body shape, intensity levels and tap-to-identify are in the paid versions on my site ($30 / $50 one time). Those also use corrected muscle names and have extra muscles, so they are NOT a plain asset swap from the free one, they ship with their own integration code.

Playground if you want to poke at it in the browser first: https://www.fitnessvisuals.com/playground?utm_source=reddit&utm_medium=social&utm_campaign=flutter-package

pub.dev: https://pub.dev/packages/rive_muscle_heatmap

Source: https://github.com/jorgeg922/rive_muscle_heatmap

Rough edges, honestly: it's 0.1.0, front artboard only, and I've only run the package on iOS and Android myself. If the API feels wrong or there's a muscle you need that isn't there, tell me. Still figuring out what 0.2 should be.

The first time i started flutter coding it was a blessing, so excited to code and it's like i found a purpose in life. I was never good at anything but when started to use flutter i found purpose, a goal rather came to my life, I wanted to make a apps for a living, i wanted to have my own softwares company. I started working toward that goal still far from but closer that 6 years ago. I published a lot of app through out the years on play store and also made website using flutter and i love doing it till this day am still addicted to it. I don't know why but i feel like am getting closer to making a successful app on playstore and i know it's going to be true and i wanted to let everyone know that i worth something you know and i want to sucessed and achieve those goals.

I have been working on this thing for ~10 months on and off. I am just about to launch the feature in my own app (hands free recipe walkthroughs for cooking) but it's deliberately structured to be lifted out as a generic framework.

If you guys are excited, I will do the work to open source.

You can see an early prototype it in action here

Use Cases:

• Fitness Coaching
• Hands free step-by-step workflows
• 'show me around the app' workflows (voice + routing)

Key Features:

• No bespoke backend, just a couple of Flutter packages and connect it to your completions API of choice
• On device text-to-speech and speech-to-text (no expensive voice model inference)
• Supports bespoke (you code them) deterministic workflows integrated with the agentic loop so you can 'walk' users through a process with agent helping or just have the agent chat and run tools.
• Understands user attention and supports 'switching' between different workflows while remembering where the user was up to in backgrounded flows
• No-Licence 'Wake word' package leveraging sherpa_onnx
• Code gen so you can 'Toolify' existing functions by just adding an annotation
• Toolify state mutation functions so the agent can 'use' the app on behalf of your user
• Toolify routing so you can 'show' your user around the app or show them what the agent has changed
• Handles async interruptions to conversations to support timers and external event pipes
• Custom LLM/API wrapper package** - currently only supports OpenAI compatible endpoints but easily extended
• Context based tool presentation to minimise context size and token use
• Cheap, fast models work fine*

*I tried really hard to use on-device inference frameworks but I'm targeting consumer adoption with cheap consumer phones and the models are not quite there IMO

** I tried really hard to use an existing package but.. reasons

Flow UI is a Flutter package for chat and AI assistant interfaces: thread, composer, streaming markdown, code blocks, attachments, suggestions. It only renders state and reports intent through callbacks, so it works with any backend or model.

New in v0.3:

- Toast

- Confirmation card (approve / reject) as a message part

- Thread list for a side panel

- Image parts for AI-generated pictures

- Selectable text across the thread

- Built-in file picker, drag & drop and paste for attachments

- Style objects on every widget

Docs: https://flowui.stac.dev

Playground: https://flowui.stac.dev/playground

pub.dev: https://pub.dev/packages/flow_ui

GitHub: https://github.com/StacDev/flow_ui

Feedback and roasts welcome.

I usually set up my flutter projects in a similar way regardless of size.I tweak it a lil depending on project but it’s usually the same somehow
My question is does that not allow me to grow as a flutter developer or is it fine to having standards u just follow
Ps I evolve the same thing but the reason why I bring this up is because I see people doing things differently all the time sometimes very different approaches for different things. I also have no issue working in projects structured differently. But most of the time I ask myself, why couldn’t I think of that?

If you have put auto-sizing text inside an IntrinsicHeight, a Table cell, or a Row with CrossAxisAlignment.baseline, you have probably hit this:

LayoutBuilder does not support returning intrinsic dimensions.

It is not a bug in whichever package you are using. It is structural, and worth understanding because it rules out a whole approach.

auto_size_text and the other auto-sizers wrap a LayoutBuilder (auto_size_text.dart:242). A LayoutBuilder cannot answer an intrinsic-dimension query: it needs incoming constraints before it can build a child at all, and computeMinIntrinsicHeight and friends are asked without any. Flutter throws rather than guess - the assertion is in the framework itself, layout_builder.dart:478.

So anything that needs a dry size will blow up on a LayoutBuilder-based fitter: IntrinsicHeight and IntrinsicWidth, Table with IntrinsicColumnWidth, baseline-aligned Rows. Wrapping it in a SizedBox only moves the problem.

The fix is to do the fitting below the widget layer. If the shrink-to-fit happens inside a RenderBox, the render object can measure candidate sizes with a TextPainter and answer computeDryLayout and computeDistanceToActualBaseline itself, so intrinsic queries just work instead of asserting.

I ended up writing that because I needed it in a table: https://pub.dev/packages/fit_text

Worth knowing either way: auto_size_text is still the default recommendation everywhere and has 1.18M downloads, but its last release was October 2021.

Got tired of writing stuff like `json['data']['user']['profile']['name']` every time an API response didn't match my model shape, so I built json_query.

final user = JsonQuery(response.data).map<User>(
  {
    'id': '.data.user.id',
    'name': '.data.user.profile.name',
    'package': '.data.user.subscription.package.name',
  },
  User.fromJson,
);

- Small jq-inspired path syntax: `.field`, `[n]`, `[]` — that's the whole language, on purpose (no filters/scripting, keeps it fast and predictable)
- Missing paths return null by default; opt into `required: true` if you want a throw instead
- Zero dependencies, works with any client (http, Dio, Chopper) since you're just handing it decoded JSON
- `JsonQuery.compile()` if you're running the same projection over a lot of payloads

For Dio users specifically there's json_query_dio, which puts the same methods directly on Response so there's no extra wrapping.

pub.dev/packages/json_query
pub.dev/packages/json_query_dio

Both are MIT licensed, source is up on GitHub. Feedback/issues welcome.

Genuinely curious how teams handle this.

One screen changes, and suddenly the question is:

Do we test just that flow?
What else could it affect?
Which devices?
Do we just run everything to be safe?

And then when tests fail, half the time you're figuring out whether the app is broken or the test just needs fixing 😅

I'm trying to understand how common this is in mobile teams.

Made a short 2-min survey if you're up for it: https://forms.gle/WVufYxJqtQRwEwDXA

I keep noticing LLMs add too many fallback/static values in Flutter code — things like ?? '', ?? 0, ?? [], hardcoded strings, default IDs, and unnecessary try/catch blocks.
It makes the code look safe, but often hides actual data or API issues.
How do you prevent LLMs from adding these unnecessary fallbacks and keep generated Flutter code clean?

I wanted Apple Foundation Models in a Flutter app without shipping an API key or standing up a server, so I wrote a plugin for it.

It streams tokens as they generate, supports tool calling, and can constrain output to a schema, so you get structured data back instead of hoping the model returns valid JSON.

Runs entirely on device on iOS and macOS - private, offline, no per-token cost. MIT licensed.

https://pub.dev/packages/apple_foundation_models

Happy to answer questions. Getting the streaming and the schema constraint across the platform channel was the fiddly part.

ong-time mobile/product lead here. Looking for outside perspective because I'm now questioning myself after a long argument with my boss.
Context: I work on external client apps as well as our main customer portal app — the one used by the majority of our customer base. Our mobile apps are native, built about 6 years ago:
Android: Java/Kotlin + XML
iOS: Swift + UIKit
Web: React

100K+ users. Zero limitations adding features or maintaining these apps over the years. Apps are feature rich and AI based new features are in plan for revamp.

What's happening: We have a full revamp of the apps and portal coming up, and we're updating our tech stack too. My plan:
Android → Kotlin + Compose
iOS → SwiftUI
Web → Next.js
I already have multiple Android, iOS, and web devs trained on this stack.

The conflict: My boss wants to consolidate to Flutter — one team, one codebase, covering web/Android/iOS. His argument: if I put 6 frontend devs on one Flutter codebase instead of splitting across native platforms, we ship 3x faster.

My pushback:
We have zero Flutter training on the team right now
Native apps perform better and feel more premium
We have built Flutter apps before, but only for external client projects, not our own flagship product
He thinks I'm biased toward native because it's my background. Might be some truth to that, but I don't think that's the whole story.

Anyone actually shipped a migration like this — native to Flutter, or vice versa, at similar scale? Did the "one codebase, ship faster" promise hold up? Would love real-world experience, not theory.

I started building minimo (video) because most video compressors either upload private footage or hide useful controls behind a subscription. I wanted compression to stay on the phone, with a simple UI for normal use and enough control when presets are not enough.

Flutter handles the UI and compression state. The actual encoding goes through light_compressor_v2 to MediaCodec/MediaMuxer on Android and AVFoundation on iOS, so the app does not ship an FFmpeg runtime.

The project is free and open source:

https://github.com/minimo-pro/minimo_video

I would be interested to hear how others handle long-running native jobs and stale callbacks in Flutter apps.

Credits

• Video compression is powered by light_compressor_v2. Respect and thanks to its maintainers and contributors.
• Special thanks to Kamran Bekirov and his website Flutter Pro Design. I learned from and adapted many ideas from his work for myself and for this app.

Hey guys, hope y'all are doing ok! So, recently I've been thinking a lot about what app development has become for me. I've been working as a Flutter engineer for about 5 or 6 years now, and back in the day, I used to feel a lot more joy when I managed to complete a new feature, implement a complex widget, or learn new stuff. It took me some time to start using coding agents, and even now, I use them in a simple way, but I just don't feel that same connection to my own code anymore. It got me thinking about what I should do next. Should I keep trying to find a balance with AI-generated code and just act more like a code manager? How are you guys dealing with this in terms of mobile development (specially with Flutter ofc) ? Let me know!

We tested this AI built mobile prototype for a savings app. I used one of those tools that lets you describe screens and it spits out a working flow, so most of the "coding" was just prompts and tweaking.

Our team thought "round up spare change" was obvious. Half the testers thought we were pulling a random % of their whole balance every night. Flow looks clean, copy was AI suggested, but the mental model is still off.

If you also build apps without writing code, how do you sanity check that the AI generated text and flows actually make sense to normal humans? appreciate any thoughts.

I just discovered an issue in Flutter that may compromise your app: you can literally write Dart code in your translation files and have it execute in production.

flutter gen-l10n validates ARB resource names but not the placeholder type field, which gets dropped straight into generated Dart. A crafted type string injects arbitrary code that compiles clean and runs when the localization is called.

Not a big deal if your .arb changes get reviewed like code, but plenty of teams auto-merge translations from CI or a third-party tool with nobody reading them, and that's where it gets dangerous: a hacked translation account, a malicious translator, or a compromised vendor can inject code into .arb files that runs in your production app.

It's rare, but it can easily turn into a supply chain attack.

for example:

{
  "@@locale": "en",
  "greeting": "Hello {user}",
  "@greeting": {
    "placeholders": {
      "user": {
        "type": "Object user) { print('>>> ARBITRARY DART EXECUTED FROM A TRANSLATION FILE <<<'); return 'pwned'; } String injectedByTranslation(Object"
      }
    }
  }
}

The print will be executed normally.

Full explanation: https://badranh1.medium.com/a-translation-file-can-hack-your-flutter-app-google-says-thats-not-a-vulnerability-ae175473acd3

EDIT: The issue is reported to Google, but it was closed without a fix as they believe it poses no security risk, that is why I am posting it publicly, a nice to know.

I built a tiny offline English/Chinese dictionary dataset for Flutter/Dart.

GitHub: https://github.com/FirepadCN/pocket_dict_5000

It contains ~5,000 common English words with IPA + Chinese definitions, plus inflection mappings:

abandoned → abandon
grows → grow
running → run

The whole thing is just a generated Dart Map, so there is no database or runtime dependency.

I originally made it because I wanted something simple enough to bundle directly into a Flutter app for offline word lookup.

MIT licensed.

Would love feedback from Flutter developers: is this something you'd actually use, or would a different data format / API be more useful?

Hey r/FlutterDev,

I wanted to share a project I’ve been working on called Listener (Link:https://github.com/johnngugi/listener).

It’s a custom bit-perfect audio player and streaming app. The goal was to send uncompressed FLAC PCM data directly to external DACs without the operating system interfering.

Most standard Flutter audio plugins route everything through the OS mixer, which inevitably resamples the audio. To get true bit-perfect playback, I needed to bypass the mixer entirely and talk directly to the native audio APIs (WASAPI on Windows, CoreAudio on macOS).

Here is how I set up the stack:

• The Audio Engine (Zig): Zig does all the heavy lifting. It decodes the FLAC files, manages a custom TCP network protocol for streaming, and pushes the audio buffers directly to the DAC using the native OS APIs.
• The Bridge (Dart FFI): Dart acts strictly as a control plane and never actually touches the audio buffers. Flutter simply sends commands (play, pause, seek, load) down to Zig via FFI. Keeping the buffers entirely within Zig ensures that Dart's garbage collection or UI thread overhead can never cause stutters in the audio stream.
• The Frontend (Flutter): The user interface is currently very barebones and needs a lot of work. The core focus so far has been getting the native audio pipeline rock solid.

I’m sharing this because bridging Flutter with a low-level systems language like Zig for high-performance audio isn't a super common use case, and I thought this control-plane architecture might be interesting to share.

I’d love any feedback on the FFI implementation or how I'm handling the native API integrations. Also, if anyone is passionate about audio UI and wants to critique (or help improve) the frontend, I'm all ears.

I’m a BCA student from India and I’m currently exploring Flutter for mobile app development.

Over the past few years I’ve jumped between different technologies, so this time I want to choose one direction and build real depth instead of constantly switching.

For developers here:

• Is Flutter still a good technology to focus on in 2026?
• How is the job market for Flutter developers, especially for freshers?
• Would you recommend Flutter to someone starting from scratch today?
• What skills should I learn alongside Flutter/Dart to become employable?
• How important is native Android/iOS knowledge for a Flutter developer?
• Would you recommend learning Flutter through an institute/course, or is self-learning + building projects enough?

I’d especially appreciate advice from people who are currently working professionally with Flutter.

Thanks!

1. For someone starting now, what Flutter + Dart roadmap would you recommend?

I’m especially interested in real experiences from Flutter developers, recruiters, or people who have recently completed training in Kerala. Please mention the institute/course name if you had a good or bad experience.

Thanks!

I made a free open-source Flutter Android-only (for now) DJ app. I was tired of all the DJ apps that charge you a monthly fee for something you should be able to own.

Github: https://github.com/manueljpy/SideDeck

And for the r/selfhosted nerds, this app lets you connect to your own Subsonic music server to search and download songs on you device.

Example migration here:

• Migrate Flutter Gallery to Dart primary constructors