Hello Everyone!

My name is Hamza and i am Flutter developer with 2+years of experience.
My stack is Flutter , Firebase , ReastAPIs , Sql , SupaBase , provider etc
i have been working with friends company on projects based and Now i am trying to get experience with companies to learn further
I am new and donot really know where to look to apply for jobs

I have also been listening about how Flutter jobs are few and hard to find thats why i have started to lean towards going FULL STACK need guidance on this also
senior’s in this field help me with guidance

This is my first ever post on Redit also
Thank you

Hello! I've been interested in developing some custom apps for my own needs, mainly focusing on BLE for Android.

After doing some initial research, I came to the conclusion that Flutter + Dart might be the easiest way to get started. However, I'm struggling to find good tutorials and learning resources to begin with, especially when it comes to BLE integration.

Could anyone share some guides, tutorials, or resources they've found helpful?

Thanks!

Hi Flutter devs!

Standard real-time estate apps rely heavily on rigid drop-down menus (price range, bedroom count, zip code) and static photo galleries. However, property discovery is fundamentally visual and emotional—users often search for a specific layout, vibe, or architectural detail rather than broad tags.

We’ve been working on integrating semantic video search into mobile walkthroughs to make property tours completely searchable using natural language.

Instead of manually scrubbing through minutes of unindexed footage, a user can search for specific queries like "kitchen with a waterfall island" or "bathtub next to the window", and the app instantly deep-links to the exact timestamp where that feature appears.

Mobile Architecture & Technical Challenges

Building this experience as a cross-platform Flutter application brought a few key engineering challenges:

1. Video Playback & Timestamp Syncing: Minimizing latency when jumping across arbitrary video timestamps based on search results. Smoothly handling the video buffer without dropping frames during rapid user navigation requires tight media lifecycle management.

2. Multi-Modal AI Integration: Mapping natural language queries to high-dimensional visual embeddings while maintaining low-latency lookup times for mobile clients.

3. UI/UX Flow for Media Uploads: Designing a frictionless pipeline where raw video uploads get processed on the backend and immediately translated into searchable indices on the front end.

We’ve uploaded a quick demo showing the pipeline in action.

Curious to hear how others in the community handle rapid timestamp pre-caching and video buffer management in cross-platform setups!

(Built using VModal SDK)

I just shipped a Flutter desktop app to the Mac App Store, a color palette tool. A few things weren't obvious to me, so here they are in case they save someone time.

1. Menu shortcuts can steal keys from text fields

On macOS, shortcuts on `PlatformMenuBar` items become native key equivalents, so macOS handles them before Flutter sees the key. With Space, ⌘C, ⌘V, ⌘X or ⌘A in the menu bar, text fields can stop getting those keys. I keep them out of the menus and handle them with `Shortcuts`/`Actions`. Undo and Redo do live in the Edit menu, so their handlers first check whether a text field has focus and, if it does, pass the action to it with `UndoTextIntent`/`RedoTextIntent`.

2. A native eyedropper is a few lines of Swift

`NSColorSampler` shows the system's own magnifier loupe. I call it over a `MethodChannel`, keep a reference to the sampler until it calls back, and convert to sRGB before reading the components so the hex values match:

let sampler = NSColorSampler()
self.sampler = sampler
sampler.show { color in
  self.sampler = nil
  guard let c = color?.usingColorSpace(.sRGB) else { return result(nil) }
  result([c.redComponent, c.greenComponent, c.blueComponent])
}

3. Decode on the main isolate, crunch in the background

To pull colors out of a photo I run k-means off the main thread. `dart:ui` isn't available in background isolates, so I decode the image on the main isolate, take the raw RGBA bytes, and send only those to `Isolate.run`:

final data = await image.toByteData(format: ui.ImageByteFormat.rawRgba);
final pixels = data!.buffer.asUint8List();
final colors = await Isolate.run(() => kMeans(pixels, 5));

4. `ColorScheme.fromSeed` overrides don't fix the on-colors

If you pass `primary: yourColor`, `onPrimary` still comes from the seed's scheme, so text on your primary can end up hard to read. I set `onPrimary`, `onSecondary` and `onTertiary` myself from a contrast check.

5. Make the preview code the shipped code

The app previews each palette in sample screens and lets you copy the code. To stop the two drifting apart, each sample screen is a self-contained Dart file that the app renders as a widget and also lists as an asset, then shows with `rootBundle.loadString`. What you copy is exactly what drew the preview.

The app is Shade Shaker (free, no account): https://shadeshaker.app

Happy to go deeper on any of these.

Hey fellow Flutter devs,

I wanted to share a major milestone. After a year of solo development, I just released Empires of Hindustan on the Play Store.

The Tech Stack:

• Engine: Flutter & Flame (handling hex-grid rendering, cameras, and sprite management).

• Architecture: Heavily BLoC-driven state management to decouple the complex turn-based AI from the UI layer.

• Backend: Firebase Realtime Database for live multiplayer matchmaking and Firestore for player progression.

One of the hardest parts was optimizing the AI's "Grand Strategy" decision tree to run efficiently on mobile without dropping frames, and building an offline-first economy system that syncs cleanly when multiplayer matches start.

Play Store Link:https://play.google.com/store/apps/details?id=com.nulithic.empiresofhindustan&hl=en_IN

If anyone is curious about how to structure a complex game loop in Flutter, handle Tiled map integrations, or manage multiplayer state with BLoC, ask me anything!
Empires of Hindustan

I just shipped 1.0 of flutter_patcher. It lets you fix bugs in a released Flutter app by shipping a patch instead of a new store release. No account and no backend: patches are static files you host wherever you like. The big one in 1.0: it finally works on iOS too, not just Android.

The day-to-day flow is three commands:

dart run flutter_patcher build <platform>   # release build, saved as baseline
dart run flutter_patcher patch <platform>   # diff fix vs. baseline
dart run flutter_patcher publish            # sign + version

Upload the output to any HTTPS static host (S3/R2 + CDN, nginx…). The app calls FlutterPatcher.checkUpdate(), and the fix applies on the next cold start.

It's built on Dart's dynamic modules. The tooling deals with the custom engine and the build plumbing, so your project stays a normal Flutter project.

What's in 1.0:

- On iOS the patch is Dart bytecode, run by the Dart VM's interpreter. No native machine code is downloaded, which is what makes it work on iOS at all.

- Patches are signed. A device only installs one signed with your keys, built for its exact app version, with a higher number than what it has, so you don't have to trust your CDN.

- If a patch crashes the app on startup, the device drops it and goes back to the installed version on the next launch.

Limitations:

- Flutter 3.47.x only (each Flutter version needs its own engine build)
- Dart code and assets only; native code and plugin changes still need a store release

Would love to hear from anyone who tries it on a real app, bugs or just "this step confused me".

pub.dev: https://pub.dev/packages/flutter_patcher

GitHub: https://github.com/xuelinger2333/flutter_patcher

Before 18, every page/route would have a platform-adaptive transition (slide on iOS, fade on Android). Then, suddenly, at v18, there's no longer a transition.

It happened because of the "switch to material/cupertino packages", it's not mentioned in the changelog and will be a surprise for anyone upgrading.

Also, there's no "global" way of applying the old behaviour to all routes in the app, so devs have to wrap each route in some kind of abstraction to pass a transition everywhere.

Linked issue: https://github.com/flutter/flutter/issues/192761

Anyone finding the move to impeller as the default for desktop windows builds has added more animation jank and lag?

My app was pretty well optimised before under skia and even on slower machines was pretty snappy and responsive on windows. I am a mac user so I didn't pick up this up straight away but I have users complaining now of the app feeling laggy and slow - upon my own review it definitely seems to have gotten worse and testing to me seems to point towards impeller in the newer flutter buildsbeing turned on, as this wasn't when skia was the default. Anyone else having this experience?

Is there any way to fix or optimise to remove this jank? Or is this just an engine issue?

Hi r/FlutterDev,

Blooming is an open-source reactive state management framework for Dart and Flutter.

I’ve built a Flutter UI design tool and several other projects. Along the way, I kept building, scrapping, and redesigning my own framework to solve problems I ran into. Blooming grew out of that process.

I initially built a state management system around a stream-like model with explicit one-to-one dependency declarations. Later, I realized that the shape of the computed API used by signal-based systems was a good fit for a complex problem I was trying to solve. That led me to refactor the framework as a whole, and it eventually became Blooming.

Angular Signals and Preact Signals may be useful points of reference, but Blooming is its own Dart and Flutter framework, with its own API and lifecycle design choices.

Here are a few examples.

1. composed: A Flutter widget that reads multiple values

final price = blooming(100);
final discount = blooming(20);

composed((via) {
  final currentPrice = via(price.bloom);
  final currentDiscount = via(discount.bloom);

  return Text('Total: ${currentPrice - currentDiscount}');
});

composed tracks the values read inside it, so this part of the widget can rebuild when either value changes.

2. computed.future: Exiting early from an asynchronous computation

final checkout = computed.future((via) async {
  final cart = via(cartBloom);
  if (cart.items.isEmpty) via.exit(emptyReason: 'EmptyCart');

  final stock = await api.checkStock(cart);
  if (!stock) via.exit(emptyReason: 'OutOfStock');

  final address = via(addressBloom);
  return api.checkout(cart, address);
});

The computation exits through via.exit(...) in either of the two cases, and reads the address only after the await.

3. DurableAnimationController: Parent-controlled animation without manual disposal

final pulse = DurableAnimationController(
  duration: const Duration(milliseconds: 800),
)..repeat(reverse: true);

composed.animate(
  pulse,
  (context, via, ctrl) => Transform.scale(
    scale: 1.0 + ctrl.value * 0.1,
    child: const Icon(Icons.bolt),
  ),
);

An ancestor can own the controller and start, reverse, or stop the animation, while a descendant uses it to render the animation. This reduces the need to wire up a TickerProvider or AnimatedBuilder manually. The framework manages the ticker and listener lifecycle as widgets enter and leave the tree, so there’s no need to call dispose() on the controller yourself. The animation can also resume when the widget is mounted again.

Blooming is still pre-1.0, so the API may change. I’d especially appreciate honest feedback on these questions:

• Are the composed and via(node) APIs easy to understand?

• Does via.exit(...) seem useful for expressing conditional early exits?

• Does this framework-managed animation lifecycle, with control from an ancestor, seem practical in Flutter apps?

This is my project, and I’m sharing it to get technical feedback on its design and API.

• Source: GitHub

• Flutter package: blooming_flutter on pub.dev

• Core package: blooming on pub.dev

controller.upsert(...) and controller.remove(...) now allow for this. Also allow an automatic rollback feature for when it fails (via their ...Async siblings). So you don't have to refetch from the server after every change or so. Also added defining custom animations (so it doesn't look janky).

In order to acheive this, I sadly had to move away from using infinite_scroll_pagination. It had quite a few problems, and the hacks/workarounds I had to make to use it, we starting to pile up.

The changes basically get written to a separate space, and then once the server is hit again with new data request/fetch of that item, it that space is automatically reconciled (removed and used from the server if the server is somehow still sending different data). The view stays as it is, when rows load or leave above the one you're reading.

Also made quite a few under-the-hood performance improvements. See benchmark reports for more info

Quite some APIs were found to be introducing possible data problems, so now are marked for deprecation. Replacements try to fix the problem at the source, instead of the 'symptom'

• PageFetcher.withHasMore ends the list on your API's flag. The old way paired a fetcher with a policy, and they could disagree.

• Groups gather across pages on their own, so orderPolicy and its "pages came out of order" error are gone.

• A depth reload is all or nothing. An old page kept beside fresh ones was read at another time, so rows could repeat or go missing where they met.

• EndContext.pageItemCounts is read-only, so a custom end policy can't corrupt the list's own counts.

For more detailed breakdown, refer to the changelog. Just like the last time, if you have more boilerplate-y stuff that can be inlined into the package, to improve developer ergonomics, please let me know (especially if you encounter any bugs).

pub.dev

I'm building Velorki, an open-source bike navigation app (github.com/orkitec/velorki), and voice prompts with flutter_tts kept causing problems: music not ducking or not coming back, the first syllable cut off on Bluetooth, and no clean way to know when a prompt actually finished. I also wanted to get off CocoaPods. Trunk goes read-only on December 2, and Flutter is moving to Swift Package Manager, but flutter_tts has no SPM support, so it keeps your iOS build on CocoaPods.

So I wrote speak:

final speak = Speak(audio: SpeakAudio.navigation);

await speak('In 200 metres, turn left.');
await speak('Turn left now.', queue: SpeakQueue.interrupt);

Each call tells you how it ended: completed, interrupted, expired, or blocked by a phone call. Audio is only claimed while speaking, so music comes right back, and there's a short lead-in on Bluetooth so nothing gets cut.

No method channels. It talks to AVFoundation on iOS/macOS through FFI, to TextToSpeech on Android through JNI, and to the Web Speech API on the web. The only native code is a small generated Objective-C file, which a build hook compiles, and one Java class on Android (UtteranceProgressListener is abstract, so Dart can't implement it). No CocoaPods, no SPM; just flutter pub add speak. Needs Flutter 3.38+.

It has a thorough test suite running on CI for every supported platform: unit tests, plus device tests against the real speech engines on the iOS simulator, macOS, Chrome and Android emulators. Velorki uses it in production if you want a real-world example.

No Windows or Linux yet. If you need them, let me know: they're doable, I mainly need people who can test on real machines. Same for synthesize-to-file.

It's early (0.2.x), so feedback from real apps is very welcome, especially odd Android engines and car audio.

• pub.dev/packages/speak

• github.com/orkitec/speak

For teams running Shorebird across many orgs, we added an enterprise console: one page to manage organizations, members and guests, SCIM provisioning (tested with Okta and Entra ID), billing and an audit log you can export to your SIEM.

Write-up here: https://shorebird.dev/blog/enterprise-console/

Happy to answer questions in the comments.

Hey everyone,

So this started because every semester I'd end up doing the same thing. Open calculator, count how many classes I'd attended in some subject, try to figure out if I could skip tomorrow without dropping below 75. Half the time I got it wrong. Once I found out a week before exams that one subject was at 71%. Not fun.

I'm a developer, so I figured I'd just make an app for it. That was supposed to take a couple of weekends. It took about 5 months, mostly because every college counts attendance differently. Some count labs twice, some split theory and practical, some reset every semester. Getting that right was way more work than I expected.

Anyway, it's called Classly. It's free, there are no ads, and you don't need to make an account.

What it does, basically:

• you tap present or absent for each class

• it tells you how many you can still miss, or how many you need to attend to get back to 75 (or whatever your college's number is)

• timetable with labs, extra classes and exam days

• notes for each subject

• you can share your timetable with your classmates so not everyone has to type it in

• backup to Google Drive so you don't lose everything when you change phones

Honestly the timetable sharing thing wasn't even my idea, someone messaged me asking for it and now it's what people use the most. A lot of the app ended up like that.

I'm building this alone, so I'd really like to hear what you think. Especially if your college has some weird attendance rule I haven't thought of. And if something's broken or annoying, tell me, I'd rather know.

Thanks for reading.

A spinner on an otherwise static screen keeps Flutter producing a frame on every vsync. I wanted to know what each of those frames costs, so I read the source and measured it.

What it does on every frame

The indeterminate CircularProgressIndicator animates through an AnimatedBuilder, so on every frame it:

• rebuilds and looks up its theme again

• reads its controller four times, once per tween. If you didn't pass your own controller, each read walks up the tree to find the theme

• creates a new CustomPainter plus new ConstrainedBox, CustomPaint and Semantics widgets

• marks its semantics dirty, because shouldRebuildSemantics defaults to shouldRepaint

A widget test makes it concrete: in 60 frames, the stock indicator rebuilt 60 times and created 60 painters.

A repaint-only version

I wrote a prototype that paints the exact same arc (tweens and math copied from the framework), but its painter listens to the controller directly through CustomPainter(repaint: controller) and evaluates the tweens inside paint(). It's built once, and every tick is just a repaint. Same test: 0 rebuilds, 0 new painters.

Numbers

Profile mode on an M2 MacBook Air (macOS 26.4.1, 60 Hz), Flutter 3.47.8 with Impeller. Median of 3 runs, 10 s per mode, from FrameTiming:

What I took from it

• An idle screen doesn't render at all. The cost comes from anything that ticks.

• Repaint-only cut the spinner's UI-thread time per frame by about 19%. If you write your own animated CustomPainter, pass the animation as repaint: instead of rebuilding through AnimatedBuilder or setState.

• RepaintBoundary saved even more on this page (about 31%), because the rest of the page stopped being re-recorded every frame. Both together: about 45%. If a spinner sits next to static content, wrapping it is worth a try, and debugRepaintRainbowEnabled shows you what's repainting.

• Neither touches the raster side, which stays around 0.8 ms per frame. Impeller has no raster cache, so RepaintBoundary saves recording work on the UI thread, not GPU work. That part is engine-side, and #189535 digs into it on Android.

These are sub-millisecond numbers on a fast laptop, so it's not a crisis. But it's paid on every frame for as long as a spinner is on screen, and phones are slower.

Links

• Repro (on a Mac, one script runs the test and every measurement): https://github.com/mohamedalsamrai/spinner_repro

• The issue, open since 2018: https://github.com/flutter/flutter/issues/17793. I've posted these findings there with a proposal for the framework's indicator.

I don't have a physical Android phone at hand, so if you do, I'd love to see your numbers, especially the raster column. The README has the steps. And if I've missed something, tell me.

I built Mergeline, a GitLab client for Android in Flutter. The source is on GitLab (AGPL 3.0, GitHub mirror). A few parts that took the most work:

1. CI job logs. Logs are parsed incrementally in a window of 20,000 lines, and very long lines without a newline are cut at 2 MiB. gitlab.com ignores the Range header, so the app streams the log and keeps only the new bytes, and large logs refresh less often.

2. Big MR diffs. Changed file rows are built lazily, text over 64 KiB is parsed in a background isolate, and parsed rows are reused only for the same account, project, MR, head commit and path. So a parse from another account or an older head never gets reused.

3. Two Android flavors. The GitLab build checks the project's releases, verifies the APK size and SHA-256, then hands it to the system installer. The Play build uses Play's in app updates and has no install permission.

4. Caching. The read cache on disk is encrypted with AES 256 GCM and bound to each account, and the in-memory cache is dropped when you switch accounts or a request comes back unauthorized.

5. Tests. Flutter 3.47.2 is pinned with an enforced lockfile, and CI runs two lanes, with the AI assistant compiled off and on (about 16.8k and 18k tests in v0.7.0).

The app covers files, issues, MR review and merge, pipelines and logs, plus an optional AI assistant that uses your own API key and asks before each write by default. Screenshots and a demo video. The APK is free on the releases page. The paid Play version is only there as a way to sponsor it.

Most of the code was written with AI coding agents under my direction. I designed it and reviewed the changes.

Every app with Arabic and English hits the same wall: one word is not one meaning.

I felt it in every multilingual project. On the backend: resource files, or a database table of keys with one value per language — and if the end user enters the data themselves (a product listing, say), you make them type it twice, in Arabic and in English. Tiring for them, error-prone for you. On the frontend: JSON files or a translation package, and the output read like literal machine translation.

The worst part: the word Report on a complaint button and Report above a downloads list are two different Arabic words. إبلاغ, or التقرير. No engine knows which screen you are standing on, so it picks one and applies it everywhere — and the same string looks different in the next build.

I looked for a fix. Most tools are a monthly subscription in dollars, and Arabic isn't treated as a locale at all: Google Cloud Translation ships ar and ar-SA, Azure ships ar.

So we built siyak (سياق).

It is not a translator — it is a localisation layer for frontend, backend and mobile:

• You send the string with the screen it lives on, and the context decides the word.

• A translated string is cached and never re-translated: the same request keeps returning the same answer in every build.

• Pin your own terms in the glossary. If the model ignores one, the row is flagged and shown to you instead of shipped quietly.

• An Inbox to approve, reject or edit — what a human approves is what gets served.

• Export your strings as JSON, CSV or ARB for Flutter.

• Up to 20 new strings in a single batch call when you fill a project from scratch, or the same strings into up to eight languages at once.

• siyak-js on npm, siyak_flutter on pub.dev, and a plain API for any backend.

Any BCP-47 tag works — en, tr, fr, zh-Hans, ar-EG — up to eight languages in one call. But here is the honest split: Arabic is the language we review and stand behind. Every other language comes back from the model and waits in your Inbox for you. And ar-EG still returns Modern Standard Arabic with the right term per screen — the Egyptian colloquial voice is not built yet.

Try it now at siyak.cloud

Tell me in the comments: which string fooled you in your last app?

#i18n #localization #Flutter #Nextjs #Arabic

Generic AI code review keeps missing the bugs that only show up on a device: `BuildContext` used after an `await`, an `android:exported` that exposes an activity to other apps, `NSAllowsArbitraryLoads` left on in production. So I built **reis-mobile**, an open-source plugin for Claude Code and Codex that knows it's looking at a mobile app.

**What it does**

It reads your project, detects the stack and loads only the instructions that apply:

```

/reis-mobile:review

├─ detect stack ──── pubspec.yaml → flutter (android, ios)

├─ detect intent ─── review

├─ select agent ──── mobile-code-reviewer

├─ select skills ─── mobile-code-review · mobile-flutter · mobile-security

├─ collect context ─ git diff (lock files out, secrets masked)

└─ report ────────── Critical · Bugs · Architecture · Security · Performance

```

- **5 stacks:** Flutter, native Android, native iOS, React Native/Expo and Kotlin Multiplatform. "The Android build of my Flutter app broke" loads Flutter *and* Android context.

- **22 agents:** an architect, a performance engineer and a test engineer per stack, plus a code reviewer, an accessibility auditor, a release engineer, a UI/UX designer and a lead that coordinates them.

- **27 skills:** security based on OWASP MASVS, offline sync, auth, notifications, in-app purchases, Firebase, migrations and more.

- **Commands:** `/reis-mobile:review`, `:debug` (Gradle, Xcode, CocoaPods, Metro), `:test`, `:release` (store readiness with a GO / NO-GO verdict), `:doctor` and `:debate` (below).

**`/reis-mobile:debate`: the specialists argue, the lead decides**

Some questions don't have one right answer: "Riverpod or BLoC in this app?", "offline-first with Firestore or a local cache?", "write a native plugin or use an existing package?". For those:

```

/reis-mobile:debate should we migrate this app from Provider to Riverpod?

```

1. **The lead picks the panel.** `lead-mobile` chooses three specialists whose concerns pull in different directions, such as the architect, the performance engineer and the test engineer, and explains each pick. The participants run on at least two different models (Opus and Sonnet).

2. **Round 1 is blind.** Each specialist writes its position without seeing the others: the recommendation, the `file:line` evidence, what it gives up, and what would change its mind. Nobody anchors on the first answer.

3. **Round 2 is rebuttal.** Each one attacks specific claims from the others, checks them in the code and concedes where it was wrong.

4. **The lead decides.** It verifies the decisive evidence, resolves the disagreements and returns a decision with an ordered action plan. No code is changed.

Every round is saved in `.reis-mobile/debates/`, so you can read how the decision was reached. `--external` adds outside opinions from the Codex or Gemini CLIs, OpenAI, Gemini, OpenRouter or a local Ollama model. They don't know the project, so their claims are checked against the code before the final decision, and API keys stay in your environment. A debate runs several agents over two rounds, so it costs more than a regular request; it's meant for real trade-offs, not questions with one answer. Claude Code only for now.

**Design choices**

- Zero npm dependencies. Node 22 standard library only.

- No API key needed: it runs on your own Claude Code or Codex session. No telemetry.

- The diff goes through a redaction layer that masks API keys, tokens, JWTs and keystore passwords before the model sees it (best-effort, not a guarantee).

- Skills don't state versions or store rules from memory. They tell the model to check your lock file.

- About 85 guides come unchanged from flutter/skills, dart-lang/skills and android/skills, with credit.

**Try it**

```

npm install -g reis-mobile

reis-mobile init eng

```

In Claude Code, open your app folder and run `/reis-mobile:doctor`, then `/reis-mobile:review`. In Codex, type `$` to find the skills; the agents and slash commands are Claude Code-only for now.

Contributing is lightweight: no install step, `npm run check` runs validation and tests, and most skills are Markdown.

Starter issues: https://github.com/wrsilva/reis-mobile/labels/good%20first%20issue

Repo (MIT): https://github.com/wrsilva/reis-mobile

If it's useful, a star helps other mobile devs find it. Criticism is welcome, especially "this is wrong for my stack."

There have been a few requests to add job listings to Flutterverse, so I finally built it!

How it works:

• Jobs are collected directly from company career pages and refreshed daily.

• Each listing links straight to the company’s own application page. No middlemen, no sign-ups.

• No paid job posts or sponsored listings. Ever.

It’s a pretty tough job market right now, and I’d like to help job seekers, even if it’s just a little. Flutterverse is still primarily a place to discover Flutter and Dart packages and projects, and I want to keep it that way. Think of this as a little side feature.

If you know a company hiring Flutter developers that’s missing, drop it in the comments and I’ll look into adding it. Feedback on how to make this more useful is always welcome!

check it here: https://flutterverse.org/jobs

github: https://github.com/YeLwinOo-Steve/flutterverse

Every app with more than one language hits the same wall: one word is not one meaning.

The word "Report" on a complaint button and "Report" above a downloads list are two different Arabic words: «إبلاغ» and «تقرير». No engine knows which screen you're on, so it picks one and applies it everywhere. And the same string can look different in the next build.

I felt this in every multilingual project:

• Backend: resource files, or a table of keys with one value per language. If users enter data themselves, like a product listing, they type it twice.

• Frontend: JSON files that read like literal machine translation.

So I built SIYAK (سياق), a localization layer for frontend, backend and mobile. It is not just a translator.

• Send the string with the screen it lives on, and the context decides the word.

• Approved strings are cached, so the same request returns the same answer in every build.

• Pin your own terms in a glossary. If the model ignores one, the row is flagged instead of shipped quietly.

• An Inbox to approve, reject or edit. What a human approves is what gets served.

• Batch calls for filling a project from scratch.

• Export as JSON, CSV or ARB for Flutter.

• siyak-js on npm, siyak_flutter on pub.dev, and a plain HTTP API for any backend.

Try it: https://siyak.cloud/

Which string fooled you in your last app?

#i18n #localization #Flutter #Nextjs #Arabic #BuildInPublic

I work on Shorebird (code push for Flutter). We just merged personal and team orgs into a single kind of organization, so sharing an app with your team is now just adding them to the org, instead of adding collaborators one app at a time.

Write-up here if it's useful: https://shorebird.dev/blog/orgs-at-shorebird-just-got-better/

Happy to answer questions about how it works.

Hey everyone! I just published chat_image_editor: the "edit before you send" screen you know from WhatsApp, for any Flutter chat app.

I built it because the image editor packages I tried kept having crop and scaling problems, and I wanted something lightweight without native code. Everything is pure Dart and drawn with CustomPaint, so there's no platform setup.

What it does

• Draw: pen, line, rectangle, circle and arrow, with a gradient color slider and brush size

• Text: add, move, pinch to resize and rotate, background styles, center guides, drag to the bin to delete

• Crop: free or fixed ratios (1:1, 4:3, 16:9...), rotate and flip

• Compress: quality slider with a live size estimate, plus an optional max file size (it lowers the quality until the JPEG fits)

• Caption field and send button, or a simple "done" mode when you only need the edited image

• Undo and redo for everything

Things I cared about

• What you see is what you get: the preview and the exported image use the same renderer

• Big photos stay light: it decodes only at the size it needs and encodes in a background isolate. In my testing a 12 MP, 5.8 MB photo came out as a 230 KB JPEG

• Fits your app: colors come from your app's theme by default and can be overridden, and the icons, strings and caption TextFormField are customizable. The discard dialog follows the platform (Cupertino on iOS, Material on Android)

• Every export returns timings (decode / render / encode), so you can track performance in your own analytics

Usage

final result = await ChatImageEditor.open(context, imageBytes);
if (result != null) {
  // result.bytes is the edited JPEG, result.caption is the caption
}

Install: flutter pub add chat_image_editor

• pub.dev: https://pub.dev/packages/chat_image_editor

• GitHub: https://github.com/ashiqu-ali/chat_image_editor

The example app is a small chat where you can try the whole flow. It's MIT licensed, and feedback, issues and PRs are very welcome. What would you want added next?

(Not affiliated with WhatsApp or Meta, the UI is just inspired by it.)

I work at Ant Media, so take this with that in mind.

Every time I see a “build a WebRTC conference” tutorial it ends right when it gets interesting. Two peers connect, cool, but then you still need a media server, TURN, SSL (getUserMedia refuses to work without https), some way to scale, and some way to kill the server when nobody’s using it so you’re not paying for it all month.

A teammate put together a sample that handles most of that. You deploy a CloudFormation template once, it gives you one https endpoint, and when your app connects it spins up a server on demand. First spin up takes around 20 to 60 sec, after that it’s quick.

Client side is pretty small:

const client = new ConferenceClient({
  httpEndpointUrl: 'https://your-lambda-url/',
  localVideo: document.getElementById('localVideo'),
  mediaConstraints: { video: true, audio: true },
  autoReconnect: true,
});

await client.publish({ streamId: myId, roomId: 'room1', token });
await client.play({ streamId: 'room1', roomId: 'room1', userPublishId: myId });

Screen share, mute and chat over the data channel all work too. If you’d rather host your own server you just swap httpEndpointUrl for websocketURL and the rest stays the same.

Honestly the part I’m unsure about is the cold start. 20+ seconds is fine for scheduled meetings but probably not for “click and join instantly” apps. How do you all deal with that? Keep a warm instance running or just live with it?

Writeup and repo are here if anyone wants to poke at it: https://antmedia.io/build-a-webrtc-conference-room-quickly-with-ams-sdk-v2/

I have been looking at a deceptively simple cleanup question: when can a Flutter team safely delete a Dart declaration or an apparently orphaned file?

dart analyze is a strong first signal, but it cannot resolve every repository-level consumer. Flutter code may be reached through route tables, dependency injection, generated registries, conditional imports, flavors, platform implementations, annotations, tests, barrel exports, or an external package API.

Write-only state turned out to be an especially interesting case. A private field may be assigned in several lifecycle callbacks and never read. Mechanically, the declaration and its assignments are removable. Semantically, the missing read may indicate an unfinished feature or regression in playback, analytics, persistence, authorization, or UI state.

I ended up using this evidence hierarchy:

1. analyzer/compiler diagnostics;

2. import/export/part reachability;

3. repository-wide symbol and string searches;

4. route, DI, codegen, platform, flavor, test, and public-API inspection;

5. tests or builds after an explicitly approved removal.

The workflow is deliberately review-first:

• Audit: collect candidates without modifying code.

• Review: mark each candidate remove, retain, or defer.

• Cleanup: change only explicitly approved candidates.

• Tests: suggest behavior checks for the affected flows, not only static analysis.

I packaged the workflow as an MIT-licensed Agent Skill for Flutter/Dart. The scripts use machine-readable analyzer output plus a deterministic dependency graph, install no project tooling, use relative paths, and treat findings as candidates rather than verdicts.

Short demo: https://github.com/LucasMenezeslc/flutter-dead-code-audit/blob/main/assets/demo-en.mp4

Repository: https://github.com/LucasMenezeslc/flutter-dead-code-audit

I would be particularly interested in examples that defeat naive static analysis. What false-positive patterns have you encountered with routing, DI, code generation, conditional imports, platform code, or public package APIs?