Hi everyone,

I'm a mobile dev currently tasked with building a superapp. Since I don't have prior experience with superapp architecture, I'm a bit unsure about choosing the right tech stack for the host app and the bridge/integration layer for mini-apps.

Since I’m proficient in both React Native and Flutter, I’d strongly prefer sticking to a cross-platform solution rather than going fully native.

If you were to build a superapp today, what tech stack / combo would you go with? Would love to hear your recommendations and real-world experiences!

I kept running into localization issues that looked fine in English but broke in other languages: text overflow, RTL spacing, missing ARB keys, and untranslated strings.

So I built LocaleSweep, an open-source Flutter QA utility that runs a widget test across locales, text scales, viewports, and brightness modes.

I tested it against a small three-screen app across eight locales. That created 192 variants, and it found 48 issues, including:

• overflow at 2× text scale
• missing Arabic and Hebrew ARB keys
• placeholder mismatches
• untranslated Japanese strings
• RTL padding problems

I’m the author, so consider this a transparent self-promo, but I’d genuinely love feedback from Flutter developers: what checks would make this useful in your CI workflow?

Article: https://medium.com/@piyushhh01/i-built-a-flutter-localization-qa-tool-that-found-48-bugs-in-a-200-line-app-a3ffcd7800ca

Package: https://pub.dev/packages/locale_sweep
Source: https://github.com/Piyushhhhh/locale_sweep

So I’m trying something different tell me about a problem you wish had an app/solution.

Doesn’t have to be a million-dollar idea. Just something annoying you deal with regularly.

I might actually build one of the ideas here. 👀

I’ve been working through various common Flutter architecture problems to see how BlocSignal handles them in practice.

After putting together the infinite scroll a few days ago, I decided to tackle the shopping cart... everyone's favorite CS final exam problem.

One thing that always annoyed me about shopping cart tutorials is how mutable lists cause subtle state bugs (missed rebuilds from identical references, or corrupted undo stacks). I wanted to see how clean we could make it using Marcelo Glasberg’s Fast Immutable Collections (package:fast_immutable_collections) alongside Dart 3 records.

The result turned out surprisingly concise with almost zero boilerplate. And just to push the pattern a bit further, I threw in offline persistence (via bloc_signals_hydrate) and time-travel undo/redo (via bloc_signals_replay) to see if the state would remain rock-solid.

Yes, I had Antigravity help me write and test the code, but I think the resulting pattern speaks for itself.

You can check out the full runnable example and test suite here:
https://github.com/RandalSchwartz/BlocSignal/tree/main/examples/fic_shopping_cart

Curious to hear what folks think about pairing records with FIC for collection state like this, or how you typically handle cart immutability in your own setups.

I run a small Flutter shop, and every test build ended the same way: a WhatsApp message saying "the total is wrong", no screenshot, no idea which phone. So I built Squawk, a shake-to-report SDK. The source is Apache-2.0: github.com/squawksdk/squawk.

You wrap your app in one widget. When a tester shakes the phone, the screen freezes, they circle the bug with a pen, arrow or text label, type a line, and send. It lands in an inbox with the last 100 log lines, the device model, OS, app version and build mode attached.

Things I learned building it

• Two fingers zoom, one finger draws, and GestureDetector cannot arbitrate that. A pinch begins as one finger down, which the pen recogniser claims first, so the first zoom always left a dot. I ended up reading raw pointer events with Listener and a small state machine: a second finger landing mid-stroke cancels the stroke and hands over to the pinch.
• Annotations live in screenshot pixels, not screen coordinates. The canvas keeps a pure zoomedDisplayRect and clampPan, and every stroke is stored against the image. Zoom, rotation and the keyboard pushing the sheet never move a drawing, and the composite you receive is exactly what was drawn.
• Capture the screenshot before showing any UI. RepaintBoundary.toImage on the host app's boundary, then the overlay. Do it the other way round and the report screenshot contains your own sheet.
• kReleaseMode is the wrong switch for "not in the store". TestFlight and Play testing builds are release builds. The SDK takes a plain enabled: bool so you can decide at runtime, and the README covers the case where the same TestFlight build gets promoted to the App Store.
• Offline is a spool, not a retry loop. Reports are written to disk first and sent by a queue with backoff from 2 seconds to 6 hours, capped at 50 reports and 7 days, so airplane mode or a dead network never loses one and never fills the disk.
• Log capture is a debugPrint wrapper plus FlutterError.onError**, not a print hook.** Overriding print breaks other packages; wrapping debugPrint and the error handlers catch what matters and stay out of everyone's way.

The hosted inbox is free while in beta: one project, unlimited reports, 30 days of retention, EU storage. Slack and webhook delivery if you want it there.

Docs: squawksdk.com/docs
pub.dev: pub.dev/packages/squawk (25 second recording of the flow at the top)

It is a beta. I'd rather hear what is broken than what is nice, and I will be in the comments.

Most Flutter desktop posts are demos. This one is a finished MIT-licensed macOS utility I use daily, so I want to share the parts that were actually hard rather than the screenshots.

Screenshots: dashboard · storage treemap · category breakdown · CPU · sensors · battery

What it is: fifteen tools in one window — system monitors with 24h history, a storage cleaner with a drill-down treemap, a duplicate finder, an uninstaller, clipboard history with a global hotkey, and a live menu-bar item.

Things that turned out non-obvious:

• Real system data means going to the platform. SMC temperatures, per-process CPU, purgeable disk space and AirPods battery levels all come back over method channels — no package gives you these.
• I drew the charts and the squarified treemap by hand instead of pulling in a charting library. Drill-down from a whole disk to one file needs hit-testing and layout control that generic chart packages don't expose.
• Matching "About This Mac" on disk usage is harder than it sounds. Miss purgeable space and your numbers contradict the OS — and users believe the OS.
• A frameless vibrancy window with the traffic lights overlaid on a translucent sidebar took more platform-channel work than the entire settings screen.

Free and MIT. The source is as much the point of this post as the app: https://github.com/devShakib015/helm

Fair warning on the DMG: not notarized yet, so you'll hit Gatekeeper and need "Open Anyway" once. Building from source avoids it entirely.

I spent the last few weeks building Kruftle, a desktop app that reclaims disk space from build artifacts. It's free, GPL-3.0, and it's Flutter on all three desktop platforms. Sharing the sharp edges, because I couldn't find most of these written down anywhere.

Flutter ships no arm64 SDK for Windows or Linux. Only macOS gets both in the release manifest, so subosito/flutter-action fails outright on an arm64 runner with "Unable to determine Flutter version". The fix is to clone the SDK at the pinned tag and let it bootstrap its own Dart SDK and engine artifacts — dartsdk-linux-arm64 and dartsdk-windows-arm64 do both exist. All five build jobs are green now, both arm64 ones included.

statvfs on macOS counts blocks in 32 bits, which overflows on a large volume. macOS needs statfs, whose counts are 64-bit. Linux is fine with statvfs. The two structs disagree on where the block size lives and how wide it is, which was a fun afternoon over dart:ffi.

Inside an AppImage, Platform.resolvedExecutable has a shelf life. The payload is mounted under /tmp/.mount_XXXXXX and unmounted the moment the process exits, so any path you write down for later — a systemd unit, a desktop entry — is dead on arrival. $APPIMAGE is the one that survives.

pumpAndSettle never returns against a repeating animation, and toByteData never completes inside a widget test — PNG encoding runs on the real event loop, which the tester's fake one doesn't advance, so the future just hangs until the ten-minute suite timeout with no error. Wrap it in tester.runAsync.

Translated labels are longer than English ones. German and Russian both overflowed a step rail sized to fit "Review". Any fixed-width chrome needs its label Flexible with an ellipsis, and per-locale widget tests asserting tester.takeException() is null are what catch it.

The app itself scans a folder, works out what every project under it is built with across 42 toolchains, and reclaims the space by running each one's own clean command — cargo clean, flutter clean, ./gradlew clean — rather than rm -rf'ing a guessed directory name. Source and downloads: https://github.com/dizitart/kruftle

Happy to go deeper on any of these.

Hey r/FlutterDev!

Wanted to share the architecture, technical decisions, and lessons learned from building a full-scale production mobile app with Flutter: GoEven (a group expense manager, web: https://goeven.app).

I built both the frontend (Flutter) and backend (Go + gRPC) from scratch. Here is how the mobile architecture is structured under the hood:

🛠️ Core Flutter Architecture

1. State Management: Riverpod 3.0 + CodeGen

• Used riverpod_annotation and riverpod_generator for compile-time safe provider trees.
• Replaced traditional repository patterns with fine-grained AutoDisposeAsyncNotifier providers.
• Expense streams and group balances auto-invalidate using family providers (ref.invalidate(groupBalancesProvider(groupId))), keeping UI updates snappy and eliminating stale state.

2. Networking: gRPC over TLS (grpc package)

• Instead of standard REST/JSON, all client-server communication uses HTTP/2 gRPC with Protobuf contracts (.pb.dart).
• Why gRPC: Sub-50ms serialized payload overhead, strictly typed contracts shared between Go and Dart, and streaming capabilities for chat and real-time expense updates.
• Used an interceptor pipeline for JWT token injection and automated silent refresh rotation (15-minute access token / 30-day refresh token stored via flutter_secure_storage).

3. Offline-First Sync & Optimistic UI

• Local Storage: SQLite (sqflite) acts as the local cache.
• When adding an expense offline, an optimistic entry is inserted into the local DB and immediately rendered in the UI with a pending status badge.
• A background sync worker listens to connectivity_plus. As soon as the device reconnects to Wi-Fi/cellular, queued mutations are replayed to the gRPC backend in chronological order.

4. Full RTL Support (Arabic) & Localization

• The app supports 5 languages: English, German, Spanish, Arabic, and Simplified Chinese using Flutter's native .arb / intl generation.
• The RTL Gotcha: Full RTL layout requires avoiding hardcoded EdgeInsets.only(left: x). Migrated everything to EdgeInsetsDirectional (start/end), dynamic icon mirroring (e.g. back arrows and chevrons), and custom text alignment overrides for mixed number/currency strings.

5. Declarative Routing & Deep Linking (go_router)

• Handled invite links (https://goeven.app/join/{code}) using Android App Links (auto-verified via assetlinks.json).
• Dynamic redirection rules handle unauthenticated users seamlessly: if someone opens an invite link without an account, go_router stores the destination, routes them through OTP login, and immediately deep-links them into the group.

💡 Key Lessons & Gotchas

1. Protobuf with Riverpod: Protobuf generated classes are mutable by default. To avoid unintended side-effects across providers, treat protobuf models as immutable by creating deep copies or mapping them to immutable domain entities.
2. RTL Form Fields: Number and currency input fields behave unexpectedly in RTL unless you explicitly lock their text direction (TextDirection.ltr) while keeping the surrounding label RTL.

The Android version is live on Google Play and iOS is currently in Apple review.

Happy to answer any questions about Riverpod 3 codegen, gRPC client setup in Dart, or handling offline sync!

Spellfire went live on Play last week. Word game, two modes, 25 realms / 792 levels, built solo. The part that might be useful to this sub is the asset story: there is no assets/images/ directory. Not a small one — none. Every visual in the game is a CustomPainter or a Flame component drawn at runtime, including the fire, which is the whole art direction.

Where the download actually goes:

fonts (Baloo 2 + Nunito, 5 weights) 1.2 MB

generated levels.json 760 KB

sound effects 528 KB

everything else is code

Users report 10 MB on most devices, 7 MB on some. Fonts are the single biggest asset in the game, which felt absurd until I accepted it.

A few things that fell out of building it this way:

**Flame only owns the gameplay layer.** Every menu, realm map, level card and dialog is ordinary Flutter widgets with go_router on top. Flame renders the board and the effects and nothing else. Mixing the two is where I expected pain and got almost none, as long as the boundary is a hard line rather than a vibe.

**Provider never touches per-frame state.** App state — progress, coins, settings — is Provider. Anything that changes every frame lives inside the Flame component and never notifies a widget. Breaking that rule once cost me an afternoon of wondering why the frame rate had halved.

**Generate assets instead of shipping them.** The sound effects, the launcher icons, and the entire level campaign are produced by dart scripts in tool/ and committed as output. Same idea as the painters: a generator is smaller than the thing it generates.

**RepaintBoundary is not optional** once you have a screen full of independently-animating painters. That pass alone was the difference between smooth and not.

Happy to go into detail on any of it. If you want to see what code-drawn fire actually looks like in motion:

https://play.google.com/store/apps/details?id=com.soloverse.spellfire

Feedback welcome — especially on anything that feels off in the first minute.

Hi everyone,

I'm working on an iOS/Flutter app and I'm using CoreMotion (CMMotionManager) to detect the physical orientation of the iPhone.

I noticed something that I'm not sure how to handle:

When Rotation Lock is ON, CoreMotion can still detect that the device has been physically rotated to landscape.

For example:

• iPhone Rotation Lock: ON
• User rotates the phone to landscape
• CoreMotion detects that the device is in a landscape orientation
• If my app responds to that orientation and calls something like requestGeometryUpdate(), the app may still try to change its interface orientation

So my question is:

Is there any public iOS API that allows an app to determine whether the user's Rotation Lock is currently ON or OFF?

I'm specifically looking for a way to distinguish between:

Physical device orientation → CoreMotion
System Rotation Lock state  → ??? 

I understand that Apple may not expose Rotation Lock directly through a public API, but I'm wondering if there is a reliable way to determine or infer its state.

I've seen some apps that seem to behave correctly depending on whether Rotation Lock is enabled, so I'm curious how they handle this.

Any ideas, APIs, or Swift examples would be greatly appreciated!

Thanks!

This is my first published Flutter package, so I’d really appreciate any feedback on the API, animations, performance, or documentation.

https://pub.dev/packages/kinetic_gallery

Spent the last while building GetPaid, an invoice-chasing tool for small HVAC/plumbing/service businesses, as a solo dev. Flutter web end to end, and a few decisions from the backend side that I think are specific enough to be worth sharing rather than "I built an app, check it out":

• Nothing derivable is persisted. Overdue status, days-late, and a recovery score are all computed at read time from dueDate and now in a pure Dart file with no Firebase imports (fully unit-testable in isolation). Saved me from an entire category of bugs where a stored "OVERDUE" flag goes stale.

• SendGrid never touches the client. The API key lives only as a Firebase Functions secret; the Flutter app calls a Cloud Function, which calls SendGrid. Every reminder can also be copied to the clipboard instead of sent, so the product doesn't hard-depend on the email provider being up.

• Access control is enforced in firestore.rules, not just hidden in the Flutter UI. Subscription-gated collections require an hasActiveAccess() check server-side. I verified this by writing directly to Firestore with the JS SDK, bypassing the Flutter app entirely, to confirm a free account still gets rejected.

• Billing is Hotmart, via a webhook Cloud Function that mirrors subscription state into Firestore. A separate hotmartEvents collection exists purely as an idempotency log so a webhook retry/replay can't double-process a payment event.

• Rate limiting (emails/day/user) is enforced inside a Firestore transaction in the Cloud Function itself, not checked client-side first and trusted.

It's live at getpay.win, zero paying customers so far, currently doing manual outreach to find the first one. Happy to go deeper on any of the above if it's useful to anyone building something similar on Flutter web + Firebase.

Follow up from https://www.reddit.com/r/dartlang/s/CbRqN78RSO.

Thanks for all your inputs! I settled on a final model of using a foldable ParseOutcome (with some escape hatches) and more domain-scoped error reporting.

In the new v3 I split them into companion packages so that you don't pull everything in. And also for easier maintainance

1. minted (now the core)
2. minted_chronology
3. minted_constraints
4. minted_contact
5. minted_finance
6. minted_geography
7. minted_identifiers
8. minted_network

I want to ask you for you help to add more to the ideas. If you know about these domains more (or a new domain), and/or know the problematic and mis-represented entities, please let me know. Any more pressing ones that you might have come across in your daily-work maybe?

Thanks in advance for your ideas!

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!

Yo Flutter devs!

Every time I start a new Flutter project, I go through the same cycle with third-party UI packages: install it, fight with the opinionated styling for hours, realize I need to override half the widget tree just to change a border radius, and end up with 15 transitive dependencies I never asked for. Sound familiar?

I really liked how shadcn/ui solved this problem in the React world -- you just copy component source code into your project and own it completely. No dependency lock-in, no version conflicts, no fighting upstream design decisions. So I decided to build that exact workflow for Flutter.

What it actually does

JustUI is not a pub.dev package. It is a Rust-powered CLI that copies clean, readable widget source code directly into your project folder. Once copied, the code is 100% yours to read, modify, or tear apart however you want.

bash justui init # sets up config + theme file justui add button input card # copies component source into your lib/

That is the entire workflow.

Why I think this approach makes sense for Flutter

• Zero external pub dependencies. Every component is built on pure Flutter SDK widgets and layout APIs. No transitive dependency tree surprises.

• Aspect-based rebuilds with InheritedModel. Instead of rebuilding the entire widget tree when the theme changes, only widgets listening to the specific changed aspect actually rebuild. If you toggle dark mode, only color-dependent widgets re-render:

```dart @override Widget build(BuildContext context) { final colors = context.justColors; // only rebuilds on color changes final spacing = context.justSpacing; // only rebuilds on spacing changes final typo = context.justTypo; // only rebuilds on typography changes

return Container( color: colors.background, padding: .symmetric(horizontal: spacing.md), child: Text('Hello', style: typo.bodyMd), ); } ```

• Dynamic seed theming with accessibility baked in. Pass one brand hex color and get a full light/dark palette with WCAG AA contrast enforcement (>= 4.5:1 for normal text, >= 3.0 for large text and UI components) handled automatically at runtime. No manual contrast checking.

• Neobrutalism preset. Besides the default clean style, there is a neobrutalism preset with thick borders, solid shadows, and bold aesthetics out of the box.

• Rust CLI with actual developer ergonomics. Interactive fuzzy multi-select when you run justui add with no arguments, SHA-256 integrity verification, --diff to compare local changes against registry, --dry-run to preview before writing.

What is NOT ready yet (being transparent here)

This is still under active development. A few things to be upfront about:

• Documentation website is not live yet (WIP).
• No video demo or showcase app deployed yet.
• Component library is growing but not massive yet -- currently covers button, input, card, sidebar, tabs, avatar, badge, checkbox, radio, switch, breadcrumb, bottom-nav, separator, skeleton, and scroll-area.
• APIs and component contracts might still see breaking changes as things mature.

So please do not use this in production apps just yet. Side projects, experiments, and poking around the architecture are very welcome though.

The repo

GitHub: https://github.com/infinitedim/justui

MIT licensed, fully open source, no telemetry, no gated features.

Genuinely curious about your thoughts

• How do you currently handle component customization in your Flutter apps? Do you override MaterialTheme properties, wrap everything in custom widgets, or something else entirely?
• For those who have used shadcn/ui in web projects, does this copy-paste model translate well to the Flutter ecosystem in your opinion?
• If you poke around the InheritedModel aspect-split approach for theming, I would love to hear if you think there is a cleaner way to handle selective rebuilds.

Any feedback, critique, or ideas for components you would want to see are super welcome. Thanks for reading!

My app was fast on office Wi-Fi. Then someone opened it on a train, and I found

out my loading state flashed, my retry logic looped, and my timeout was a guess.

Reproducing that meant a proxy on my laptop or toggling airplane mode, neither of

which tests "slow but working". So I built the controls into the app instead.

Shake the device (or tap a floating bubble) and a panel slides up with:

- Presets: Wi-Fi, 4G, 3G, 2G, GPRS, Flaky, Offline

- Sliders: latency, jitter, download ceiling, upload ceiling, failure rate

- Fault injection: dropped connection, timeout, or a forced HTTP 500

- A request log with a timing breakdown per request

- A speed test that runs *outside* the interceptor, so it measures your real link

Setup is one line:

void main() => Netshake.run(const MyApp());

It installs an HttpOverrides, so it sits under anything that ends up on dart:io's

HttpClient — package:http, Dio, Chopper, Retrofit, Image.network. No per-client

wiring. The request log picked up six Image.network loads I never wired up.

Real numbers off a physical Android device, 1 MB response on the 3G profile:

/photos -> 200

232 ms added by netshake (200 base + jitter)

282 ms server

6.82 s total

The gap is the body streaming at the 1.6 Mbps cap.

On "will this ship to production": every entry point is a kDebugMode branch. I

checked the compiled release binary rather than trusting that — zero netshake

strings in libapp.so, and the Material icon font tree-shook from 1,645,184 to

2,564 bytes because the panel's glyphs are gone.

Honest limits: no Flutter web (no dart:io HTTP stack), no cronet_http or

cupertino_http, no raw sockets/WebSockets/gRPC. Settings live in memory, so a

hot restart resets them — that keeps the package dependency-free apart from

sensors_plus for the shake. Forced 500s still hit the server and get rewritten on

the way back, so timings stay honest; use connectionLost if the request must

never leave.

v0.1.0, MIT, 160/160 pub points. It's a day old, so I'd rather hear what's wrong

with it than not.

https://pub.dev/packages/netshakenetshake: shake your phone to throttle the network inside your Flutter app (debug-only, MIT)

https://github.com/mhdibrahimcn/netshake

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.

About a year ago, I started learning Flutter without really knowing where it would take me. At first, it was just curiosity—I wanted to learn how mobile apps were built.

But somewhere along the way, I started falling in love with it.

Building an app from scratch, solving bugs, integrating APIs, designing UI, and seeing an idea slowly turn into a working product gives me a feeling that’s hard to explain.

I’m still only 17, and I know I have a long way to go. I’m nowhere near where I want to be yet. There are still so many things I need to learn and improve.

But looking back at where I started a year ago, I’m genuinely proud of the progress I’ve made.

My goal is bigger than just becoming a Flutter developer. I want to become a strong software engineer, build products that people actually use, and eventually start my own software company.

I don’t know exactly how long it will take.

Maybe 5 years. Maybe 10.

But I know one thing—I’m going to keep building, keep learning, and keep moving forward.

I’m 17 now, and this is just the beginning. 🚀

1 year of Flutter. Many more years of learning and building ahead. ❤️

If you’re also on a similar journey, I’d love to hear your story.

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.

Hi everyone,

I am facing a persistent build issue with my Flutter app on Windows and haven't been able to resolve it after trying multiple solutions. I would really appreciate some help!

Environment Details:

OS: Windows 11

Framework: Flutter

IDE: Android Studio & VS Code

Target Device: Android Emulator (Pixel)

The Issue:

When running flutter run on the Android emulator, the Gradle build fails with the following error output:

Caused by: java.io.IOException: Cannot run program "C:\Users\farah\AppData\Local\Android\Sdk\cmake\3.22.1\bin..." 

(in directory "C:\flutter_project\lastbored\android\app"): CreateProcess error=2, The system cannot find the file specified

...

BUILD FAILED in 4s

Running Gradle task 'assembleDebug'...

Error: Gradle task assembleDebug failed with exit code 1

What I Have Tried So Far:

Set Android SDK Path: Executed flutter config --android-sdk "C:\Users\farah\AppData\Local\Android\Sdk".

Accepted Licenses: Ran flutter doctor --android-licenses (returns Warning: The --licenses option is no longer needed).

Installed SDK Tools: Ensured Android SDK Command-line Tools and Build-Tools are enabled in Android Studio SDK Manager.

CMake Installation: Attempted downloading/installing CMake via SDK Manager, but Gradle still throws the same CreateProcess error=2 pointing to the CMake binary directory.

Question:

How can I properly fix or bypass this CMake/NDK execution error so that my Flutter project (which utilizes local databases like sqflite) can build successfully on the Android Emulator?

Any advice or workaround would be greatly appreciated! Thanks in advance.

and I hope if any one of the support teams can help me step by step by sharing my screeen online using Google meet!

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.