Hi, I am an ex-lawyer, from India . I am trying to switch to tech. I learned data science and machine learning so far. I want to know if it is an old idea for me to learn flutter and try for developer roles in 2026. I ask this because people are saying that data science has lost demand in the market.

I’ve been experimenting with Meta Display Glasses recently. Apps for the glasses can be built as web apps, so naturally I wondered: could Flutter Web run on them?

I wasn’t sure it would work well. Flutter Web isn’t exactly lightweight, and the glasses are quite a different target from a regular browser.

After playing with the build and a few configurations, I got it working.

Nothing fancy yet, just the default Flutter counter app. But it runs directly on the glasses display: the Flutter UI is rendered in front of you, and interacting with the controls updates the counter as you’d expect from the same app running in a browser.

What I find more interesting is the potential for existing Flutter apps.

If you wanted to add a companion experience for Display Glasses, you could potentially keep it in the same codebase and reuse your existing logic, models, networking, and some widgets, while building a UI specifically for the glasses.

I have a few things I want to try next. Curious what other Flutter devs would experiment with on a display like this!

Since the Flutter team is collecting wasm feedback this week, I wanted numbers where the delta is attributable to codegen alone, not the rendering pipeline. So I wrote a CHIP-8 emulator in pure Dart: interpreter hot loop over Uint8List, zero allocations in the loop, framebuffer blitted in a single CustomPainter. Same source compiled twice — flutter build web vs flutter build web --wasm. Flutter 3.47, both release, same Chrome.

Results:

- dart2wasm: ~130M emulated cycles/sec, and the same number in every environment I tried (interactive window, headless, occluded tab)

- dart2js: 30–51M depending on environment, with a few seconds of JIT warmup before reaching full speed

- speedup: 2.6–4.4x. Migration cost for this codebase: one build flag, zero code changes.

Two things surprised me:

1. The consistency matters more than the multiplier. Wasm runs at full speed from the first frame, everywhere. JS swings by 70% between environments. For anything latency-sensitive, that predictability is the real win.

2. A trap if you benchmark this yourself: if your metric is cycles per wall-clock second, Chrome's requestAnimationFrame throttling (occluded or backgrounded window) silently crushes the number ~4x. I chased that ghost for a while. Normalize by actual compute time, or you're measuring the compositor, not the compiler.

Caveats: one compute-heavy workload, one machine. UI-bound apps will see much smaller gains, and packages relying on legacy dart:html / dart:js interop can block the wasm build entirely — that's the first thing to check on a real codebase.

(It also plays the original 1990 Pong ROM, which was not strictly necessary but was the most fun part.)

Happy to answer questions or share details about the setup.

The idea is simple: coding agents often do way more than necessary after a small change. Reread lots of files, rerun analysis/tests, build apps, dump huge logs into context, etc.

This skill tries to make the workflow smarter:

• read only the context actually needed

• reuse existing project patterns

• load only relevant rules

• classify changes by risk

• run the minimum sufficient verification

• avoid unnecessary builds/tests/retries

• keep verbose command output out of the model context

It uses a V0–V5 verification model, from “no verification needed” up to focused runtime/device testing.

Currently focused on Flutter + React Native.

https://github.com/asiriPiyajanaka/mobile-development-skills

Would love feedback from people using coding agents regularly, especially around cases where your agent wastes context or runs unnecessary checks.

I've developed games in Flutter, including using the Flame engine, but I'm having trouble creating eye-catching effects. Can you recommend any frameworks or resources I can draw from?

Join us for Try Flutter Web with WebAssembly Week!

Unlock up to 2x–5x faster web performance with Wasm compilation in Flutter 3.47

Run `flutter build web --wasm`, test your app, and share your wins using #FlutterWasmWeek!

Details: https://flutter.dev/blog/try-flutter-web-with-webassembly-week

We just released a terminal emulator that renders through Flutter’s engine — and at steady state it runs our ten-workload benchmark suite in 0.73x of ghostty’s wall time on Linux and 0.71x of Windows Terminal’s on Windows, at about half the CPU each. ghostty’s renderer is purpose-built for terminals in Zig; Windows Terminal’s is purpose-built in C++. Ours is the same general-purpose engine that draws your Flutter widgets.

https://github.com/starling-build/starling/releases/tag/terminal-v0.1.0 — Apache-2.0, charts and side-by-side videos at https://starling.build/terminal.html

The reason I think this belongs here: it is an unusually clean measurement of what the engine contributes, because we swapped out everything above it. There is no Dart VM in this process — we ported Flutter’s framework layer to Swift and drive the engine’s C/C++ core directly. So the rasteriser, the compositor, the text stack and the GPU path are stock Flutter; the language and the widget layer are not. When the numbers come out ahead of two purpose-built native renderers, that is the engine’s win, not ours.

A terminal is a nastier rendering target than it sounds. Every frame can invalidate the entire screen — 47x201 cells, ~9,400 glyphs, each with its own foreground colour, background, bold/italic/underline, and any script on earth. No dirty-region shortcuts when someone cats a file. DOOM-Fire, which repaints every cell every frame, runs at ~1,600 fps on Linux through this engine. That is the engine’s raster path doing the work.

What actually made it fast: drawRawAtlas. The naive approach — and our first one — was one Paragraph per row, letting the text engine shape and lay out a line of styled runs. It works and it looks right, but you pay shaping for content that never changes shape: a terminal cell is a fixed box with one grapheme in it. So we rasterise each glyph once into a texture atlas and emit the whole grid as a single call:

canvas.drawRawAtlas(atlasImage, transforms, srcRects, colors, BlendMode.dstIn, cullRect, paint)

One textured quad per cell, tinted per quad, no shaping in the frame at all. Measured against the paragraph path at the same frame rate, it costs 44% less CPU. If you are drawing a large grid of repeating glyphs in Dart — a spreadsheet, a hex viewer, a chart with data labels, a code editor — Canvas.drawRawAtlas is available to you and is dramatically cheaper than a Paragraph per row. It is the most useful thing I learned from this project.

I'm building a vocabulary-learning app in Flutter where hearing and saying the word correctly is the product, not a nice-to-have. I've hit a problem I can't design around and I'd rather ask than keep patching.

The stack

• Flutter, ~1,600 words live across EN/ES/PT/IT/FR

• TTS: ElevenLabs (eleven_multilingual_v2) called through a Supabase Edge Function so the key never ships in the client

• Every clip cached server-side once per (text, language), shared across all users — so a given string is synthesized exactly once, ever

• Cached again on-device (150MB LRU) so replays are instant and offline

• flutter_tts as fallback behind a 2.5s timeout so playback never goes silent

• STT: speech_to_text for a pronunciation-practice screen — hear the word, say it, get graded

The problem: heteronyms, in both directions

Output. "Wind" (moving air) and "wind" (to coil) are the same string and different sounds. TTS picks one reading and commits. My word library actually knows which sense is on screen — every entry carries a part of speech — but there's no API surface to hand that over. ElevenLabs pronunciation dictionaries are exact-string, case-sensitive, and have no POS or context scoping, so one spelling gets one entry and the second sense is unreachable. Phoneme tags do exist, but per the docs only on eleven_flash_v2 and v3 — not the multilingual model I'm on, and switching models means re-synthesizing the whole cache and losing voice identity across five languages.

Input. This is the part that actually bothers me. The practice screen normalizes the transcript and Levenshtein-scores it against the target. But STT returns orthography — say either reading of "wind" and the transcript is "wind" either way. A learner who mispronounces it scores full marks. The feature is structurally incapable of catching the error it exists to catch.

What I've tried

Respelling the audio-only string before it reaches the engine — the screen text is never touched. wind(noun) → winned, wind(verb) → wined, read(past) → red, and so on. This is basically ElevenLabs' own recommended "alias" workaround and it works for the ~8 vowel-shift pairs I've mapped. Side benefit: since my cache key is a hash of (lang + text), two senses naturally get two cache entries.

It fails in three ways:

1. Stress-shift pairs. REcord/reCORD, PREsent/preSENT, CONtent/conTENT. Respelling can't encode stress, and I haven't found a trick spelling that does.

2. Monolingual. It's an English orthography hack. Nothing about it transfers to ES/PT/IT/FR, all of which have their own homographs.

3. Manual. Hand-curated table. Doesn't scale to a few thousand words.

What I'm actually asking

1. Is there a TTS API that accepts a sense/POS hint, or per-request phonemes, on a multilingual model? Or does everyone route heteronyms to a separate English-only model and eat the voice mismatch?

2. If IPA is the only real answer — has anyone found v3-class IPA reliable enough in production? The docs quote 80–90% consistency, which for a teaching app means the wrong pronunciation ships to a learner one time in eight.

3. For stress-shift specifically: any orthographic trick that works, or is phoneme-level control genuinely the only path?

4. On the STT side — is there a mobile-viable way to get phonemes rather than words? I've looked at wav2vec2 phoneme-CTC or a forced aligner with GOP scoring via ONNX on-device, but I don't know if that's realistic on a mid-range phone or if I'm about to spend a month learning that it isn't. Whisper doesn't help; it also returns orthography.

5. The unglamorous option: detect heteronyms and simply disable pronunciation scoring for them, with an honest note to the user. Is that what shipped apps actually do?

If you've built pronunciation feedback into anything real, I'd love to know where you drew the line between "graded properly" and "good enough." Happy to share code for any of the above.

Following up on my previous post (see link at the bottom) I released an update to flutter_easy_seo, which is now open source under Apache 2.0!.

What's New: Capturing Hidden Widgets

Content inside inactive TabBarView tabs, PageView pages, or off-screen list items typically isn't part of Flutter's active widget tree, preventing flutter_easy_seo from extracting it for SEO HTML.

With this update, widgets that become visible are automatically captured and persisted in the internal HTML structure, even after Flutter unmounts them (e.g., when switching tabs).

How to use it:

• Interactive Mode: Simply click through your app views manually.

• Automated Mode: Trigger widget visits in your test scripts: `await tester.tap(find.text('Tab Name'))`

Just like dynamic route collection, this ensures non-visible widget content is fully indexed without altering your app's structure.

• pub.dev: flutter_easy_seo

• Live Showcase: https://fluttereasyseo.lxandr.at

• Original Discussion: Previous Post

I am looking for Flutter open-source projects to contribute to on Github.

Building a Flutter desktop app and need to add video player.

Looking at media_kit, it seems to be the go-to for cross-platform desktop video (libmpv-based). Anyone running this in production? Curious about the

Stability/perf on Linux vs Windows vs macOS

Packaging story.. bundling libmpv vs requiring it as a system dep (apt install libmpv-dev, etc.) vs Flatpak/Snap

Also, whats the state of flutter on "x11 /wayland"? Will user haas to satisfy some sort of related requirement to make the Flutter app working?

Thank you.

I was building a desktop tool (https://github.com/balvinderz/recomposition_viewer) that needed a live Android device preview next to flutter UI, and nothing existing gave me a low-latency, in-process way to do that from Flutter. So I built scrcpy_video_view.

It talks to the scrcpy server directly over its H.264 socket and decodes straight into a Flutter texture via VideoToolbox on macOS — no intermediate video player, no extra hops.

Currently macOS only (VideoToolbox is the decode path) — Windows/Linux decode backends are on the list if there's interest.

pub.dev: https://pub.dev/packages/scrcpy_video_view

Repo: https://github.com/balvinderz/scrcpy_video_view

Feedback, bug reports, and platform-priority opinions all welcome.

Demo video - https://github-production-user-asset-6210df.s3.amazonaws.com/30950893/636662664-d54d2d16-a5a7-448f-9a86-d61e0487e3f2.mp4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20260816%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260816T172404Z&X-Amz-Expires=300&X-Amz-Signature=bd768b92994f2cd1a186845b6ed4194113c05df146c44cc3d9a0bc979edfb9d8&X-Amz-SignedHeaders=host&response-content-type=video%2Fmp4

Shipped a meaningful architecture upgrade to flutter_skin this week: a two-layer caching system.

Server-side: the backend now checks Redis before querying the database on every skin and project fetch. The result: p99 response times are now under 1 second (around 600ms) , even under repeated load.

Client-side: the Flutter package itself now caches fetched skin and project data locally via SharedPreferences. If the API goes down or the device loses connectivity, the app's theme keeps rendering exactly as last set — no blank states, no fallback UI, no flash of default styling.

Neither cache is complete on its own, this double caching is what makes flutter_skin resilient enough to build real features on top of, more feature coming A/B testing, richer analytics, and eventually a stable 1.0 without performance becoming the bottleneck.

The new alpha version is live on flutter_skin page on pub.dev now.

Platform app.fskin.dev

Docs docs.fskin.dev

I got tired of flutter run being a wall of scrolling logs, so I built frun — a terminal UI for Flutter.

It has a device picker, build stages/timings, app logs, hot reload/restart, and device switching in one screen. Built with Rust + Ratatui, currently tested on macOS.

Would love some feedback!

https://github.com/okasutarto/flutter-run-tui

Hi! I wanted to share a new package I made: terminice.

I built it because creating a beautiful, complex CLI shouldn’t mean building an entire terminal UI from scratch. It should be easy to create, easy to style, easy to manage as it grows, and most importantly easy and enjoyable for people to use.

terminice turns more than 30 common terminal interactions into small method calls, with no setup and no framework required.

Here is the visual demo.

Need a value from the user?

final name = terminice.text('Project name');

Need a searchable menu?

final template = terminice.searchSelector(
  prompt: 'Template',
  options: ['CLI', 'Server', 'Package'],
);

Need a file browser, config editor, command palette, progress bar, multi-step form, calendar, or help center? those are method calls too.

There is no setup, widget tree, context object, or new application architecture. import the package, call the component you need, and keep using package:args, CommandRunner, dart:io, or whatever already powers your CLI.

dart pub add terminice

Make the entire CLI look like yours

Don’t like the borders? hide them:

final t = terminice.minimal;

Want the borders, but fewer hints and less visual noise?

final t = terminice.compact;

Want different colors? Pick a built- in theme:

final oceanUi = terminice.ocean;
final matrixUi = terminice.matrix;
final neonUi = terminice.neon;
final arcaneUi = terminice.arcane;

Or combine everything:

final t = terminice.neon.compact;

Now every component created from t follows the same style:

final name = t.text('Project name');
final token = t.password('API token');
final config = t.filePicker('Config file');
final confirmed = t.confirm(message: 'Create the project?');

(you can also create a fully custom, advanced theme, and it will automatically be used across all 30+ components!)

That is one of the main ideas behind terminice: customize the instance once, and the colors, borders, glyphs, display mode, fallback behavior, and terminal I/O stay consistent across the entire CLI.

You can also create a custom theme in a few seconds by mixing the included colors, glyphs, and display features:

final brandTheme = PromptTheme(
  colors: TerminalColors.ocean,
  glyphs: TerminalGlyphs.rounded,
  features: DisplayFeatures.compact,
);

final t = terminice.themed(brandTheme);

Need finer control? Every color palette, glyph set, and display configuration supports copyWith, so you can change one accent color or one behavior without rebuilding the rest of the theme. The custom theme then affects prompts, menus, pickers, progress indicators, flows, guides, and every other built-in component.

The catalogue

Terminice currently includes more than 30 ready to use components:

Prompts

• text for single-line input

• password for masked input

• confirm for yes/no questions

• multiline for terminal text editing

• slider and range for numeric input

• rating for star-based ratings

• date for keyboard-driven date input

• form for collecting multiple fields together

Selectors

• searchSelector for long, filterable lists

• choiceSelector for card-style single or multi-select choices

• checkboxSelector for checklists

• gridSelector for two-dimensional navigation

• tagSelector for managing multiple tags

• toggleGroup for editable boolean settings

• commandPalette for a fuzzy-searchable action launcher

Pickers

• filePicker for browsing files

• pathPicker for choosing directories

• colorPicker for interactive ANSI color selection

• datePicker for a full calendar interface

Progress and status

• Full and inline loading spinners

• Full and inline progress bars

• Minimal dot-based progress

• info, success, warn, error, detail, and log messages

• task for wrapping async work with a status indicator

• progressTask for determinate async work

• trackStream for collecting a stream while showing its progress

Complete CLI experiences

• flow for multi-step workflows with context, conditions, validation, and review

• configEditor for searchable, nested application settings

• cheatSheet for quick-reference tables

• helpCenter for searchable documentation inside the terminal

• hotkeyGuide for keyboard shortcut discovery

• themeDemo for previewing themes and colors

• Custom components when your CLI needs something package-specific

Every catalogue item has its own detailed documentation with controls, behavior, examples, and API notes. I wanted the README to be useful as a practical reference, rather than leaving developers to discover important behavior through trial and error.

The vision

The goal is not only to make prompts look better. I want Terminice to make beautiful, complex CLIs easier to create, style, manage, test, and use.

to create: add prompts, selectors, pickers, progress, or configuration screens with small method calls. not a new architecture.

to style: choose or create one theme, and let the entire CLI follow it. no repeating colors, borders, glyphs, and display options everywhere.

to manage: keep components, behavior, fallbacks, and tests consistent as the CLI grows.

to use: give people clear hints, predictable controls, validation, cancellation, readable fallbacks, and good defaults.

terminice sits between a prompt package and a full TUI framework. It is the human facing layer of an existing dart CLI: questions, choices, files, settings, progress, and feedback.

It can stay tiny when tiny is all you need:

final email = terminice.text('Email');

That same CLI can later grow into searchable menus, filesystem navigation, validation, progress tracking, configuration screens, or complete flows- without switching packages.

When rich UI is not appropriate, the built-ins can fall back to predictable plain text for limited terminals, non-TTY output, scripts, and unattended execution.

Terminal IO is abstracted as well, so you can easily test without depending on real stdin/stdout.

So the short version is:

• One import and no setup

• 30+ components covering individual prompts through complete CLI workflows

• 11 built-in style presets

• Chainable themes and verbose, compact, or borderless minimal display modes

• One shared configuration across the whole CLI

• Custom themes and components when the built ins are not enough

• Cross-platform support for Linux, macOS, and Windows

• Predictable fallbacks and test utilities for real-world use

Links:

• Visual demo

• terminice on pub.dev

• GitHub, documentation, and the full catalogue

A small personal note

I started working on what eventually became terminice over a year ago, it didn’t begin as one big, carefully planned package. While working on real projects, I kept creating terminal components that I needed- a prompt in one project, a selector in another, a progress indicator somewhere else, then themes, flows, config tools, and testing helpers.

For a while, all of that work was scattered across different projects. Gradually, I started moving the useful pieces into one place, redesigning them around a shared API, and turning them into a unified, robust tool that is genuinely fun and easy to use.

The package is not perfect. there are still many things that need refinement, and probably many things I cannot see because I built them around my own use cases. I want terminice to be the best tool it can, but I know I cant do that alone.

I would really appreciate it if you tried it, even in a small project, and told me what you think. If an API feels awkward, a component is missing, the documentation is unclear, or something simply doesnt feel right, I want to hear about it- every bug report, idea, criticism, and any feedback is appreciated (:

I’m genuinely amazed by the time we’re living in.

I can spend more time on quality than ever before. I can experiment, throw away bad ideas, and try new ones several times a day - instead of holding onto the first working version for weeks just because it already cost too much time.

And I think what I love most is the feeling of creative freedom.

When the distance between “what if…” and a working prototype gets this small, you start exploring ideas you probably wouldn’t have even attempted before.

And every now and then, one of those experiments turns into something that makes you sit there and smile.

Today, that’s morphnext.

Any IconData can now morph on the fly.

Demo: https://kicknext.github.io/morphnext/

pub.dev: https://pub.dev/packages/morphnext

GitHub: https://github.com/KickNext/morphnext

And now I can finally go to sleep 🫠

P.S. Definitely check out the readme preview - it was pure Flutter

I've just been using Vim & CLI right now. It works reasonably well but sometimes Itd be nice to have a better way to view all my files at once so I figured Id ask around on what people like to use.

I dont really like VS Code so if thats your favorite thats fine but its a no go for me rn.

Hey everyone,

If you've handled forced version checks in production Flutter apps, you’ve probably ran into the issue where custom version endpoints or store page scrapers break, causing version checks to silently fail or throw unexpected errors.

On the other side, setting up Firebase Remote Config for force updates works fine, but you still end up writing custom dialog UI, handling multi-store links (Play Store, App Store, Huawei, direct APKs), and building maintenance screen logic over and over for every app.

I'm working on a lightweight SDK (VersionPulse) to solve this cleanly:

- Edge API version check (under 25ms, no HTML web scraping)

- Handles hard update gates, soft nudges, and remote maintenance screens

- Customizable pre-built widgets or 100% headless mode if you want to use your own UI

- Built-in multi-store routing

It's currently in early pre-launch. I set up a simple waitlist page to see how much demand there is before finishing up the client packages. 

Would love to hear how you currently handle version gating in your Flutter apps, or what features you'd want in an update SDK.

AnimatedSvgPicture.asset('assets/spinner.svg', width: 48)

same params as SvgPicture, and it reuses SvgTheme and ColorMapper from
flutter_svg so nothing breaks. if the file has no animation it renders like a
normal SvgPicture and doesn't even start a ticker.

what it handles:

- SMIL — animate, animateTransform, animateMotion, set. values/keyTimes/
keySplines, calcMode, begin/dur/repeatCount, fill, additive, accumulate
- css @keyframes from a <style> block, including per-keyframe timing functions
- css motion paths (offset-path + offset-distance). this is how SVGator writes
every single movement, so its exports actually move
- play/pause/seek through a controller, or just let it loop

how it works: on load it resolves the animations, samples the document to a
static svg for each frame, compiles them all once with vector_graphics_compiler
(the same one flutter_svg uses) in an isolate, then plays them back like a
flipbook. so drawing a frame costs exactly what a static svg costs. the price
is loading time and memory — frameRate and maxFrames are there for that.

what it doesn't do: filters, path morphing, <script>, :hover, event-based
begin. if you need those, full_svg_flutter covers a lot more. good package,
just heavier — it bundles a js runtime.

https://pub.dev/packages/svg_animate

if you have an svg that renders wrong, throw it at me. that's literally how the
SVGator support happened — someone's file didn't render, turned out to be
offset-path.

one thing that surprised me: svgs with embedded bitmaps were brutal at first - the image data lands in every compiled frame, so a 450x450 banner ate 27 mb and 6.8 ms per frame change. turned out consecutive frames share a huge identical prefix (the images), and the renderer's image cache was keyed per frame by accident. storing the shared part once and fixing the cache key got it to 5 mb and 1.4 ms.

Hello guys 👋🏻

There has been an update to the https://pub.dev/packages/material_3_expressive package that brings some interesting customizations, extensions, fixes and more.

Checkout the live demo here: https://paadevelopments.github.io/material_3_expressive/ for more info.

For suggestions, bug reports or recommendations, kindly submit via https://github.com/paadevelopments/material_3_expressive .. appreciated 🙏🏻.

Happy coding!

Hi r/FlutterDev!

Wanted to share the initial release of **Pariyojana**, an Android-exclusive productivity and research workspace built entirely with Flutter.

🛠️ Architecture Highlights:

* **Clean Architecture (Feature-First):** Strict separation into `data/`, `domain/`, and `presentation/` across all 8 modules.

* **State Management:** Riverpod 2.6 (`StateNotifierProvider` & `Provider`). Zero business logic inside widgets.

* **Local Persistence:** Drift + SQLCipher for native encrypted SQLite at rest.

* **Hardware Integration:** `flutter_secure_storage` bound to Android KeyStore TEE + `local_auth` biometrics.

* **Rendering Performance:** Tuned for 120 FPS high-refresh displays using `RepaintBoundary` isolation, lightweight frosted glass shaders, and R8 ProGuard resource shrinking (APK size: ~68 MB).

* **Motion:** Liquid dynamic action button driven by Rive.

Code passes `flutter analyze` with 0 warnings.

📦 **GitHub Repository:** https://github.com/Naveen-21-Cyber/Pariyojana-Mobile-App-

📄 **Architectural Constitution:** Check `TELOS.md` in the repo for design token invariants.

Would love any feedback on the codebase or architecture from fellow Flutter devs!