I've been posting progress updates on this other venezuelan sub, but this time I'm bringing something more technical

CONTEXT:

VeneFinanzas is a personal finance management app I've been building solo, with Flutter, that calculates how devaluation and inflation affect each user specifically.

It natively handles COP, EUR, USDT, USD and VES, and is primarily designed for Venezuela. Everything runs locally, no account, no server, and backups are encrypted so the user can back them up wherever they want

That's where I had to think through the edge case of users with 2GB of RAM. Even though they're less than 10% of users, I didn't want to cause them problems using the app. Encrypting those backups with Argon2id, with a fixed 64MB memLimit regardless of device, is risky, especially with other apps running in the background

---

I ended up using two profiles:
kMemProfileBajo, 32MB
kMemProfileAlto, 64MB

With 3584MB of physical RAM as the threshold.
The profile byte is stored inside the encrypted file itself, so decryption always uses the memLimit it was encrypted with, regardless of the current device

My initial plan was to use the standard interactive (64MB) + moderate (256MB) profiles, but the 256MB one would end up cannibalizing RAM on the more limited devices.
I landed on 32/64 because a user normally restores their own backup on their own phone, so a backup encrypted at 64MB will almost never end up being decrypted by someone with 2GB.

However, since the memProfile is fixed in the file from the moment of encryption, it still has to remain decryptable if that scenario does happen. That's why I capped it at 64 and no higher, I ran the numbers, and with the ~300MB the app already uses by default, adding the memLimit on top pushes it close to a Low Memory Kill, which is exactly what we're trying to avoid.

Keeping 64MB as the upper bound is the max stable value before entering dangerous territory, and for regular usage, lower-RAM users simply use 32MB without any hassle

Everything runs in an ephemeral isolate via Isolate.run(), spawned just for that job and torn down once it's done. Derivation never blocks the main isolate, and the heap (including the 32/64MB Argon2id uses) gets freed the moment the isolate dies, not whenever the GC gets around to it on the main isolate

Also: sodium_libs_sumo needs a BackgroundIsolateBinaryMessenger, and Isolate.run() doesn't register one by default. You have to grab RootIsolateToken.instance from the main isolate before spawning (it's only valid there), pass it in, and call BackgroundIsolateBinaryMessenger.ensureInitialized(token) as the first line inside the child isolate.

---

If anyone's run into something similar with Argon2id/isolates in Flutter, has feedback on the approach, or just wants to check out VeneFinanzas, I'm around

Hey everyone,

I’m currently building a feature that allows users to search through a large collection of content using keywords or natural-language queries.

For example: Upload video/ image collection from picker -> User searches: “person wearing a red shirt -> Results are displayed in a useful and efficient way.

What tools/services/architecture would you recommend for this?

Especially interested in:

• Open-source solutions
• APIs/SDKs

I’m preparing a social platform for iOS release with social features, messaging, profiles, notifications, moderation and privacy controls.

One feature I’m reviewing is an anonymous letter system:

• One-way letters only — no replies or conversations

• The recipient is randomly selected

• Standard users don’t see who sent the letter

• Premium users can see the sender

• Report and block are available

• Content is moderated

The feature is designed around sending a letter, not starting an anonymous conversation.

For developers who have experience with recent App Reviews: would this potentially fall under the updated Guideline 1.2 regarding anonymous/random chat?

How are you handling app performance once the widget tree starts getting complicated?

I've noticed that a lot of performance problems aren't really about flutter itself, but things like unnecessary rebuilds, oversized lists, poorly managed state and too much work happening on the main isolate.

for larger flutter apps, what's the first thing you profile when performance starts dropping?

Put my first real Flutter game on Play last week. Turn-based rather than real-time: you pick a technique, hit a short timing input, and a rules engine resolves the exchange — so the heavy lifting is state and rules, not a render loop.

Stack: Flutter + GetX for state, sqflite locally, Firebase Auth, a small backend for the leaderboard, easy_localization for 5 languages. Local friend matches run over the LAN with room discovery, which turned out to be the fiddliest part by far.

It's free with ads. https://play.google.com/store/apps/details?id=com.ccassak.tablekumdo

Ask me anything about the structure — happy to go into how I split the combat rules out of the UI, or the LAN sync, if that's useful to anyone.

I'm a developer with 11 years of Android experience and 7 years of Flutter experience.

I've been working with Flutter since its early days. Over the years, my work gradually moved beyond regular application development and more toward lower-level and performance-related areas.

I've worked on things like Flutter internals, memory and rendering performance, Flutter + C/C++ and Flutter + Rust integrations, as well as some internal infrastructure and framework-level work.

At several companies I've worked for, I ended up dealing with similar kinds of problems: redesigning or wrapping lifecycle systems, tracking down memory issues, solving rendering and performance problems, building custom UI behavior such as larger touch areas independent of visual size, and occasionally debugging issues around the Flutter Framework or Engine.

For a long time, I believed the best way to stay competitive was to keep going deeper.

It wasn't enough for me to know how to use Flutter. I wanted to understand why Flutter behaved the way it did.

So I spent a lot of time trying to build technical depth and create a stronger technical moat for myself.

But since AI coding tools became genuinely useful, I've started feeling a level of career anxiety that I didn't have before.

A lot of problems that used to require years of experience can now be approached much faster by a less experienced developer working with AI. AI can help them navigate source code, trace call chains, identify likely causes, and even generate a reasonably good implementation.

For experienced developers, the productivity improvement can be even more dramatic.

In my own work, I feel like my productivity has at least doubled in many situations, and sometimes even more.

And that's exactly what worries me.

If one experienced developer with AI can do the work that previously required two or three developers, will companies still need the same number of mobile developers?

I'm also starting to feel that some of the technical barriers I spent years building are becoming easier to cross.

In the past, there were plenty of developers who could build application features.

Far fewer understood the Framework level.

Even fewer were comfortable with the Engine, memory, rendering, or Native/Rust integration.

AI is now making it much easier for developers to move across at least part of those boundaries.

So I've developed a strong feeling recently:

I'm not worried that I'll suddenly lose my job tomorrow. I'm worried that the next time I leave my job, finding another mobile position at a similar level may be much harder than it used to be.

Especially considering the current software job market in China, I'm starting to question whether continuing to invest heavily in deeper Flutter and Android knowledge still has the same return it once did.

So I'd genuinely like to hear what other developers think.

If you had already spent more than a decade in mobile development, where would you move next in the AI era?

AI applications?

AI infrastructure?

On-device AI?

Robotics / AI hardware?

Embedded systems?

Or would you stay in mobile development and gradually become more of an AI + client/mobile engineer?

At this point, I'm no longer trying to figure out which programming language I should learn next.

The question I'm really trying to answer is:

Over the next 5–10 years, which technical areas are still worth investing deeply in for someone who already has more than a decade of software development experience?

I'd especially like to hear from other long-time Android, iOS, or Flutter developers, or anyone who has already started making a similar transition.

Hello,

How are you handling app performance with video processing on the background ?

Noticed that a lot of performance problems aren't really about flutter itself,
but things like the framework used for video editing (such as easy video editor , editor capcut, ...).

It take too much work happening on the main isolate.

for larger flutter apps, how do you manage the main and side processing ?

hello flutter devs!

migrating to flutter has been surprisingly awesome!

my previous app was built with react native / expo, and honestly, i kind of regret choosing that stack. it took up a lot of space on my laptop, and the compilation and build process was often painfully slow.

now i’m starting a new project with flutter, and so far, i’m really enjoying it. the compile times feel much faster, the development experience is pretty smooth, and i especially like having built-in support for unit testing.

i can write some code, run a test, and quickly see if everything works as expected.

still early in the project, but so far, flutter has been a really nice experience.

curious to hear from other flutter devs. what do you like most about flutter?

Hello, last year i started developing this package flutter_local_ai which let user get access directly to the on device llms api with zero download.

Now since local ai models are getting starter than ever, I see the package being adopted but my main concern it’s whether the local llm its capable of performing the task requested by the user as developer intende to give them the probability to change model (maybe a cloud one) if the task by the local llm its not performable.

My idea was someting like a score i can give based on the task requested i mainly process text using the operative system models.

Any ideas on how to do it or if I should have a different approach ?

I kept rebuilding the same audio plumbing for every app: record from the mic, draw a waveform, let the user trim, export. Every package I tried did one of those, on some of the platforms, usually with a widget I then had to fight.

monowave is the piece under the widget. No UI. It gives you:

• microphone capture (lock-free ring buffer, no dropped frames when Dart is busy)
• waveform peaks at any zoom via a mipmap pyramid (zero-copy reads)
• non-destructive edits with undo/redo, exported to WAV / MP3 / FLAC
• CompactBars: a tiny voice-note preview encoding for chat UIs
• same C core on Android, iOS, macOS, Windows, Linux; web is decode-only right now

Deterministic peaks are verified in CI across platforms, so a waveform drawn on Android matches the one on macOS.

I am looking for feedback on the editing API before 1.0. What do you use for audio today and what does it get wrong?

pub.dev: https://pub.dev/packages/monowave

GitHub: https://github.com/monorithm/monowave

video uploaded in comments;

The purpose is to showcase how we can use AI + Flutter to build something different..

It took me 3 revisions to build working Flutter app;

genAI code model: Gemini 3.8 Flash

Document Picture-in-Picture is a browser API that gives you an actual operating-system window — not an overlay inside your page. It floats above every other application and keeps running when you switch tabs. Chrome and Edge have had it since 116, Firefox shipped it in 151.

I couldn't find anything reaching it from Flutter, so I wrote a package: https://pub.dev/packages/document_pip (MIT, 160/160 on pub.dev)

void main() => runWidget(
  DocumentPipApp(
    main: (context) => const MaterialApp(home: Player()),
    popOut: (context) => const MaterialApp(home: MiniPlayer()),
  ),
);

final window = await DocumentPip.open(width: 380, height: 210);

The browser API is about four lines. Everything difficult was on the Flutter side, and it all traces to one thing: the engine assumes there is exactly one window. Three things break when there are two, and all three fail silently.

1. The pop-out freezes the instant you switch tabs. Chromium keeps painting a picture-in-picture opener at full rate in a background tab, but still reports the page hidden. Flutter's web engine turns that into AppLifecycleState.hidden, SchedulerBinding clears framesEnabled, and scheduleFrame() returns early forever. Measured: 302 browser animation frames in 2.5s against 0 Flutter frames in 3s. scheduleForcedFrame() ignores framesEnabled, so the root re-arms it for exactly as long as the page is hidden and a window is open. Firefox doesn't have the problem — it keeps reporting the opener visible — so the workaround is gated on the failure rather than on the browser.

2. The keyboard is dead in the pop-out, but typing still works. KeyboardBinding is a singleton bound to the opener's window, so a separate browsing context isn't on the propagation path: Shortcuts, Actions, Focus.onKeyEvent, HardwareKeyboard, Escape and Tab traversal all get nothing. Plain typing keeps working because the browser routes characters to the focused element natively, which is exactly what makes this easy to miss. The package replays key and selection events into the opener.

3. A package can't turn multi-view on. Only the JS app object returned by engine.runApp() can add a view — dart:ui_web exposes the views read-only — so it has to be reachable from your bootstrap. That means runWidget instead of runApp, plus a few lines in flutter_bootstrap.js. Both are one-time and the errors name the fix.

Desktop Chromium and Firefox 151+ only. Safari and Firefox for Android have no implementation, and isSupported is a feature detect so you can gate the control on it. It compiles on every platform, so adding it won't break a cross-platform build.

Longer writeup with the measurements: https://devshakib.jumyn.com/blog/flutter-assumes-there-is-only-one-window

Happy to answer anything about the multi-view side — that part is under-documented and I burned a lot of time on it.

Been looking at how different teams approach flutter apps lately and one thing that stood out to me is how differently agencies handle the native side of things.

flutter gets you pretty far, but sooner or later you usually run into platform-specific stuff, and that's where the quality of the implementation really shows.

curious how other devs here decide when something should stay in flutter vs being handled natively.

Hello everyone,
I’m a fresh Computer Engineering graduate and I’m currently trying to figure out what direction to take my career.
During university I touched a lot of different areas — backend, cybersecurity, cloud, AI/ML, etc. My graduation project was also ML/AI-related. However, out of everything I’ve tried, I’ve recently found myself enjoying app development the most.
I started taking a Flutter course on Udemy and it’s honestly the most interested I’ve been in programming in a long time. I actually enjoy building things with it and find myself wanting to keep learning more.
The only thing making me hesitate is that when I’ve asked people more experienced than me for career advice, they’ve generally told me to pursue a more “engineering” path like backend, AI/ML, cloud, etc., rather than mobile development.
So I’m wondering:
Is Flutter/mobile development a good path to build a career around as a fresh graduate in 2026?

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've a Flutter web app which could benefit from the high fidelity CSS-controlled text display of a real web app. So, why not try to use Jaspr instead?

I was under the impression that Jaspr tries to imitate the Flutter API including using Widget as the base class, but it's using Component which requires some changes. Still, no biggy. Promising.

First impression was poor. I'd have preferred to install it via homebrew and not dart install which requires me to modify the PATH and which is yet another installer I have to make sure I don't forget to uninstall.

But the main problem was that it doesn't work out of the box. jaspr serve throws errors. I had to downgrade the build_web_compilers to 4.8.5 to make it build. It also configured an ancient version of Dart which I changed to 3.13. I chose SPA as start template, perhaps it's better if you try to build a static side or server rendered pages.

Now, the counter example worked as expected. The page could use a little designer love, though. The generated source code was easy enough to understand and jaspr serve supports hot-reloading, so I continued.

Next, I tested how easy it is for Codex to create a more complex app. Will it struggle with not-flutter sources? So I asked it to create a chess app, for two human players, including a timer. And GPT Sol delivered. So AI seems to have no problem. Great.

Next, I asked Codex to port my app. That worked in principle, but it had trouble to recreate the fidelity of the UI. Like most others, I used Chadcn/ui as my inspiration and Codex wasn't able to translate the themed Material widgets into Jaspr components. Might be an AI thing, but it didn't understand to take border into account. I had to ask for a lot of tweaks and would have preferred actually use Chadcn/ui or at least Tailwind. Theoretically, this should be possible and I think, there are packages on pub.dev which already attempted to do so. That might be worth more exploring.

Instead of some random UI package that has a high risk of being unmaintained AI slop, an official port of chadcn/ui would be a great feature IMHO.

My code cloc's at ~4000 lines (110 KB) with 1.8 MB in build/jaspr. That… a lot. There's a package folder that looks like it shouldn't be there with 1.3 MB. So I assume, my app has a size of 0.5 MB.

For comparison, I asked Codex to recreate the same app using React. That's a home game for the AI which one-shotted the task. The result cloc's at ~1000 lines (72 KB), so using Dart instead of JS+JSX is a high price you must be willing to pay. The distribution size is 0.3 MB.

I don't really mind that 200 KB dist overhead because of Dart. But I dislike the larger codebase. I figure, all those things add up. In React, I simply use

style={{ width: size, height: size }}

while in Jaspr, this becomes

styles: Styles(
  width: .pixels(size.toDouble()),
  height: .pixels(size.toDouble()),
),

Right now, I'm still undecided whether to proceed with Jaspr (because I like working with Dart) to switch to React (because the AI will deal with languages and syntax anyhow), but call me at least impressed.

Has anybody else switch from Flutter to Jaspr for web apps? What's the experience with larger code bases, say 30Klocs?

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

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!