r/FlutterDev

Hey r/SideProject 👋

I'm an indie dev and every time I shipped an app I'd lose a weekend resizing screenshots, translating captions by hand, and re-exporting per device size. The Mac apps that automate this either cost $30/month or watermark the export until you upgrade.

So I built the tool I actually wanted: https://launchshots.app

What it does:

• 8 device frames (iPhone 15 Pro, Pixel 9, Galaxy S24, etc.)
• 19 languages with one-click Google Translate
• Templates for common categories (fitness, finance, food, etc.)
• Drag-to-zoom callouts you can move anywhere
• Annotations (arrows, "NEW" badges, labels) — drag, rotate, recolor
• Image stickers for logos/mascots
• Multi-screen with reorder + duplicate
• Export single PNG or full ZIP (every screen × every language)

It's a single HTML file. Everything runs client-side — your screenshots never leave your browser. No login, no watermark, no analytics, no tracking.

Open to all feedback — especially from folks who've actually shipped to the App Store. What did your screenshot workflow look like before? What's missing here?

Universal_ble has reached 2.0 and now supports advertising! You can make your device act as a BLE peripheral and let other devices scan for it and connect. That was a long requested feature and I am happy (and relieved 😅) to finally have it delivered. Some major refactoring was needed, but thankfully we did almost no breaking API changes! Migration from 1.0 should be straightforward.

Along with the above, 2.0 brings support for SPM on Apple platforms and full Flutter 3.44 compatibility!

Hey r/FlutterDev. Solo dev, been shipping Flutter apps for a few years. Posting because I open-sourced something today that I genuinely couldn't have launched without it being already battle-tested for a month against my own apps.

The thing that broke me.

You know that bug where the Android permission dialog button changes wording across OS versions — "Allow" on Android 13, "While using the app" on 14, and in Polish it's "Podczas używania aplikacji" but encoded with NBSP between words, so your tap_text fails byte-equality silently and the test just hangs there pretending everything's fine?

I lost half a Sunday to that one. Different version on iOS 17 vs iOS 26. The fix isn't hard, but the diagnosis is hours of "why is nothing happening" because the screenshot still shows the dialog and the logs still say "Tap dispatched" and the test still passes its 30-second wait. Selector maintenance was eating ~40% of my testing time and I was getting bitter about it.

What I built.

flutter-dev-agents — an MCP server that lets autonomous agents (Claude Desktop, Claude Code, Cursor, any OpenAI-compat local LLM) drive my Flutter apps on real Galaxy S25s, real iPhone 15s, Pixel 8 emulators, iPhone 17 simulators, whatever's plugged in. 110 tools across:

• Android: uiautomator2 + raw adb fallback (Samsung One UI sometimes drops accessibility taps; adb-shell input bypasses that).
• iOS: WebDriverAgent on the device, pymobiledevice3 for lockdown services. The iOS 17+ --rsd routing through tunneld's HTTP API took me a weekend to debug — it's now documented as an ADR so nobody else has to.
• Flutter-specific: Patrol integration, flutter run --machine for hot-reload control, debug-log streaming, widget tree dumps.

The tap_text thing I described above? Fixed properly now — NFC normalization plus folding NBSP/NNBSP/thin-space/zero-width-space, with case-fold fallback in substring mode. tap_text("Podczas używania aplikacji", system=True) just works regardless of which Unicode whitespace variant the Android Settings team decided to ship that week.

What's genuinely different vs other mobile MCPs

I checked the existing landscape before posting — there are mobile MCPs out there. Most are iOS-simulator-only (mobile-next/mobile-mcp, ambar/simctl-mcp), or Android-only (martingeidobler/android-mcp-server), or Figma→Flutter codegen (mhmzdev/Figma-Flutter-MCP, different use case).

What this one does that I didn't find elsewhere:

• Cross-session device locks: I run 3 Claude Code windows at once, one per project, sometimes on the same physical device pool. Filesystem-coordinated locks mean window 2 doesn't grab the S25 while window 1 is mid-tap. Stale-lock cleanup when a holder process dies.
• Tiered tool surface: 110 tools is too many for Claude Desktop's UI ceiling and Cursor's 40-tool cap. MCP_TOOL_TIER=basic exposes a curated 26-tool subset. Small local LLMs (Qwen 3B class) work with the basic tier; larger models get the full catalog.
• Defense-in-depth screenshot pipeline: Anthropic's API rejects images > 2000px on any edge. I hit this three times in production before getting the cap pipeline right. Now: per-use-case cap at 1600px, dispatcher safety-net at 1900px, BASIC-tier compress_png + inspect_image_safety so the agent has a recovery path even when an external MCP (computer-use, raw adb screencap) feeds in a 2400px PNG.

Honest gaps I'm not pretending don't exist

• iOS device control needs Xcode → macOS-only for iOS work. Linux is fine for Android-only.
• I'm a solo maintainer. PRs welcome, co-maintainers especially.
• No hosted SaaS planned. The MCP protocol is local-first; SaaS would break the security model. Documented in the ROADMAP's "Not on the roadmap" section.
• Patrol-dependent for true UI tests on Flutter. If you're not using Patrol, you get device-level control (taps, screenshots, logs, app lifecycle) but not Flutter-aware test orchestration.

Try it (genuinely 5 minutes)

pip install mcp-phone-controll
claude mcp add phone-controll -- python -m mcp_phone_controll

Then in Claude Code:

Using phone-controll, run mcp_ping, pick my Android device, take a screenshot.

You should see three tool calls returning ok: true and a PNG in ~/.mcp_phone_controll/sessions/. If anything's red, the structured next_action field tells you what to do — that's the whole MCP contract.

Links

GitHub: https://github.com/michal-giza/flutter-dev-agents
PyPI: https://pypi.org/project/mcp-phone-controll/
15-min onboarding: https://github.com/michal-giza/flutter-dev-agents/blob/main/docs/GETTING-STARTED.md
The 4 operational gotchas that cost me an hour each the first time: https://github.com/michal-giza/flutter-dev-agents/blob/main/docs/operational-gotchas.md
Roadmap: https://github.com/michal-giza/flutter-dev-agents/blob/main/ROADMAP.md

I've been working on a KeePass package for about two years but haven't been as diligent about publishing updates to pub.dev as I have been with pushing commits to github. I've dedicated some time this past month to polishing the set of packages for publishing and would like to share a few new tools for interacting with KeePass and especially KeePassXC KDBX vaults:

• https://pub.dev/packages/keepass_flutter
• https://pub.dev/packages/keepass
• https://pub.dev/packages/keepass_web

Most people will want to use keepass_flutter, which builds its library 'automatically' with cargokit (provided Rust etc are installed), whereas the keepass and keepass_web packages require you to build or otherwise provide the library yourself at this point.

I made this package for three main reasons:

1. I maintain multiple KDBX vaults and wanted a tool capable of merging databases that only keeps the latest entries, safely archiving the old entries 'just in case'.

2. I wanted more platforms: KeePassXC doesn't support web or iPad, so I made these specifically in order to cover all platforms, including browser extensions.

3. I wanted YubiKey Challenge-Response capability and this wasn't clearly available via existing packages.

Future TODOs include:

• Migrate from cargokit to native_assets_rust once Dart Native Assets launch in an unexperimental form
• Publish prebuilt binaries for package:keepass and package:keepass_web as an option for users that want to skip building
• Make sure the prebuilt binaries mentioned above are all reproducible

A scene that I bet half of you recognize:

It's Friday afternoon. You add a new key to app_en.arb. Then app_ar.arb. Then app_ku.arb, app_fr.arb, app_es.arb. You're four tabs deep, you've already lost track of which file you're in the build that says "login_button" because you missed one.

The format isn't the problem. ARB is fine. The problem is that you're editing N parallel files when you should be editing one grid.

Apple solved this for iOS in 2023 with String Catalogs — one file, one editor, every locale as a column. It's so much better that going back to parallel .arb files feels primitive.

So I built it for Flutter. It's called Stringboard, it's a VS Code extension, it's free, MIT, no telemetry, no cloud, no account.

v0.1 is intentionally minimal. What's on the v0.2 candidate list:

• EasyLocalization JSON support
• Search/filter bar across keys
• "Add language" button to scaffold a new locale
• Add button for new key record
• Right-click "Edit in Stringboard" on .arb files in the explorer
• CSV import/export for handing strings to human translators

Genuine question for this sub: if you had to pick ONE of those for v0.2, which would actually save you time? I'd rather build the one thing you'd use weekly than ship five features nobody asked for.

Links:

• Marketplace: https://marketplace.visualstudio.com/items?itemName=MohammedRzgar.stringboard
• Source (MIT): https://github.com/Mhamad-Rzgar/Stringboard

Happy to answer anything about the implementation