DEV Community: Muhammet Ali

Why I Rewrote My Flutter Tray App as a C++ Daemon

Muhammet Ali — Thu, 03 Sep 2026 20:53:21 +0000

I built a screen-capture tool for Linux in Flutter. Tray icon, global hotkey, region select, done — that was the plan. It worked, right up until three separate parts of the Linux desktop stack quietly broke it in ways that never showed up as errors. I ended up splitting the app into a long-running C++ daemon plus an on-demand Flutter UI. Here's what actually forced that.

Bug 1: the tray menu ignores your second click

system_tray and tray_manager (the two Flutter packages everyone points you to for Linux tray icons) both go through libayatana-appindicator. First click on the tray icon: menu opens, works fine. Second click, same session: nothing. Menu doesn't open. Not a crash, not a log line — the click event just doesn't make it to the app.

This turned out to be a dispatch issue specific to the ubuntu-appindicators GNOME Shell extension on GNOME 46 — after the first menu activation, it stops forwarding the next click to the same indicator until something else resets its internal state. It's not a Flutter bug and not really an appindicator bug either; it's an interaction between GNOME 46's extension and any app using the older appindicator activation pattern. Nothing in either package's issue tracker fixes this at the plugin layer, because the plugin layer isn't where the problem is.

Bug 2: your hotkey stops firing, silently

hotkey_manager_linux 0.2.0 calls keybinder_bind under the hood and does not check its return value. When keybinder_bind fails — which it does, for reasons that have nothing to do with your code — the plugin reports success anyway. Your app thinks the hotkey is registered. It isn't. Press it, nothing happens. Restart the app, still nothing. There's no exception to catch, because as far as the plugin is concerned, nothing went wrong.

I only found this by instrumenting the native call myself and comparing the actual keybinder_bind return value against what the Dart side believed. They disagreed.

Bug 3: the editor window freezes with visual garbage

The pattern I was using — spawn an off-screen window, hide it, show it on demand for the annotation editor — interacts badly with Mutter's compositor. Under specific show/hide timing, the window would come back on screen with stale, frozen frame content baked in: old cursor positions, half-rendered UI from before it was hidden. Not every time. Often enough to make the editor unusable in a live demo.

None of these three are the kind of bug you fix with a patch release. They're structural — a consequence of driving a compositor-managed, extension-dependent desktop shell through a cross-platform abstraction that doesn't know GNOME 46 changed, doesn't check the return value it should, and manages window visibility in a way the compositor doesn't expect.

The fix: stop asking Flutter to be the always-on part

The actual redesign is a two-process split:

Binary	Language	Lifetime	Job
`yakala-daemon`	C++17	long-running, autostarted	tray icon, global hotkey, IPC server, native capture, clipboard, notifications
`yakala-ui`	Flutter	on-demand, exits when done	annotation editor, region overlay, settings window

The daemon talks directly to GTK/libayatana-appindicator3/GIO — no Flutter plugin abstraction between it and the desktop shell, so there's no cross-platform layer that can silently swallow a keybinder_bind-style failure. It spawns yakala-ui as a subprocess (fork+execvp via GSubprocess) only when a window is actually needed, with stdin/stdout/stderr inherited so the UI's own debug output flows straight into the daemon's log. Communication happens over a Unix domain socket at $XDG_RUNTIME_DIR/yakala-daemon.sock, line-delimited JSON. The UI sends {"cmd": "ui_result", "ok": true, "output": "/tmp/yakala_edit_xxx.png"} when the user finishes, then calls exit(0) — it never lingers.

The hotkey problem got solved by leaving hotkey_manager out of the picture entirely: yakala-daemon also runs as a CLI client of itself. yakala-daemon --capture-fullscreen opens the same Unix socket, sends {"cmd": "capture_full"} to whatever instance is already running as the daemon, and exits. linux/install-launcher.sh registers that exact command as a GNOME custom keybinding via gsettings — the same mechanism GNOME uses for its own built-in shortcuts, which sidesteps keybinder_bind and its silent-failure mode completely. It's the same pattern git, docker, and most daemon/CLI pairs use, just applied to a desktop tray app instead of a server.

What this actually bought

Capture latency dropped to ~190ms typical (the daemon shells straight out to grim/import/scrot/maim, no Flutter engine sitting on the hot path). The tray menu opens every time, because activation now goes through the same GTK/appindicator code path GNOME's own indicators use, not a wrapper that assumes GNOME 45 behavior. And the frozen-editor artifact went away on its own — a Flutter window that only exists for the seconds it's actually being used has no stale-frame state to accumulate.

Linux is production-ready with this architecture now. macOS is still on the old single-binary model — the daemon there is scaffolded but not wired up to the OS's own tray/hotkey APIs (Carbon RegisterEventHotKey planned, not implemented).

Source and a prebuilt Linux release: github.com/muhammetali/yakala.

I Published 3 MCP Servers in One Day. Here's What Actually Broke.

Muhammet Ali — Thu, 03 Sep 2026 20:08:42 +0000

I had three MCP servers sitting in private repos — one for App Store Connect, one for Google Play Console, one wrapping Recraft's image API. All working, all tested, none of them usable by anyone but me. So I spent an afternoon getting them onto npm and the official MCP Registry.

I expected the hard part to be the code. It wasn't. The code was already done. The hard part was everything downstream of npm publish — and none of it is documented anywhere in one place, so here's the writeup I wish I'd had.

npm's 2FA wall has a hole in it, and it's not the one you think

First npm publish attempt:

npm error code E403
npm error 403 Forbidden - Two-factor authentication or granular access token with bypass 2FA enabled is required to publish packages.

Fine, I have 2FA. Except my account only has a security key registered — no TOTP app, because npm quietly dropped authenticator-app 2FA from the UI at some point and I hadn't noticed. npm publish wants a typed six-digit code (--otp=<code>). A WebAuthn security key doesn't produce one. There's no button for "just tap your key" in the CLI flow. So the account has 2FA, and there is no way to satisfy it from a terminal.

The npm docs don't spell this out. What actually works: a Granular Access Token with "Bypass two-factor authentication (2FA)" checked at creation. It's unchecked by default — I generated one, published, still got EOTP, and only realized on the second token that I'd never ticked the box. Bypass tokens also need write access scoped to the specific package(s) you're publishing; scope one to package A and try to publish package B with it, and you get a plain 403 that looks identical to the 2FA error, which cost me another ten minutes of confused debugging.

One more thing worth knowing if you're doing this after early 2027: npm's own dashboard now carries a banner warning that bypass-2FA tokens for direct publishing are being phased out. The documented replacement is trusted publishing (OIDC from CI), not a personal token. If you're setting this up for the first time today, you might as well build it against CI from the start.

The MCP Registry is not a GitHub pull request

I assumed listing a server meant opening a PR against modelcontextprotocol/servers, the way "awesome-list"-style ecosystems usually work. Wrong. That repo now hosts only the small set of reference servers the steering group maintains — the README says so directly, and the merged-PR history confirms it: nothing but doc fixes and CI tweaks get in from outsiders.

The actual registry is a separate service at registry.modelcontextprotocol.io, with its own CLI (mcp-publisher). The flow, once you know it:

Add an mcpName field to package.json — io.github.<user>/<name>. This is the ownership proof the registry checks against the published npm package. If the currently live npm version doesn't have this field, validation fails, even if your local source does. You have to publish a version that includes it first.
mcp-publisher init generates a server.json — fill in the real env vars, and make sure packages[0].identifier matches your actual npm package name (more on why that matters below).
mcp-publisher login github — device code flow, same UX as gh auth login.
mcp-publisher publish.

The one operational quirk: the login session expires faster than I expected — I hit Invalid or expired Registry JWT token twice in one afternoon, both times after getting pulled into an unrelated npm rabbit hole for 20+ minutes in between. Re-running login fixes it instantly; nothing else needs to be redone.

I didn't own the npm name I'd been building against

This one stung a little. My App Store Connect server's README had an npm install badge pointing at asc-mcp-server — unscoped — for months. Turns out that name belongs to someone else's npm account entirely, unrelated to my project. I only found out because the registry publish step kept 403ing with "you do not have permission," which sent me to check npm owner ls asc-mcp-server. One name, not mine.

In hindsight there was already a tell I'd walked past: the previously published version under that name had a completely different internal file layout than my actual source tree. I'd assumed it was just an old build artifact of my own. It wasn't — someone else's package, coincidentally similar in purpose, sitting on the exact name I was linking to in my own docs.

There's no real recourse short of npm's name-dispute process, which is slow and not guaranteed. The fix that actually ships today: move to a scoped package, @you/name. It's always available under your own username, npm publish just needs --access public since scoped packages default to private. Cost: about ten minutes to update package.json, server.json, and the README badge. If you're about to publish something for the first time, checking npm view <name> before you write a single line of your README costs nothing and saves this entire detour.

The security bug that only showed up because I tried to make the server more discoverable

This is the one I'm most glad happened before launch instead of after.

My App Store Connect server supports two transports: stdio (the default — runs locally, one set of credentials per machine) and an HTTP mode with a full OAuth 2.1 layer, meant for connecting to it remotely. I wanted to list it on Smithery, which currently only accepts servers reachable over a public HTTPS URL — so the HTTP mode was the obvious path.

Then I actually read the OAuth provider code before flipping it on publicly. The comment at the top of the file said exactly what it does, plainly: /authorize auto-approves any client that registers itself, no login screen, no consent step — because the whole thing was designed around "the operator already trusts the network, since it's their own VPS." Dynamic Client Registration means literally anyone who finds the URL can self-register, complete the OAuth flow with zero friction, and get a valid bearer token. From there, they'd have full API access — using my App Store Connect credentials configured on that server, not their own. Delete a version, submit something for review, reply to a real customer's App Store review, as me.

None of that is a bug in the traditional sense. It's a deliberate, reasonable trust model for "I'm the only one who will ever know this URL exists." It just becomes a real vulnerability the second you do the thing I was about to do: put the URL on a public directory with "10,000+ users" written on the landing page.

I skipped the Smithery listing for that server. The lesson generalizes past MCP: any tool you build assuming private-URL-as-security stops being safe the moment "let's make this more discoverable" enters the conversation. Worth a second look at why an auth flow is shaped the way it is before you widen its blast radius, not just whether it currently works.

Where things ended up

All three are live now:

gpc-mcp-server — Google Play Console
@muhammetali/asc-mcp-server — App Store Connect (scoped, for the reason above)
recraft-mcp-server — Recraft AI image generation

All three are also registered on the official MCP Registry and listed on Glama.

If you're about to publish an MCP server for the first time, the short version: check the npm name is actually yours before you build docs around it, get a 2FA-bypass token with the box checked before you're mid-npm publish, use mcp-publisher instead of looking for a PR template, and read your own auth code once more before you make anything easier to find.