DEV Community: Dor Lugasi-Gal

One app, two native codebases: how I keep Swift and C# in step, and ship both from one commit

Dor Lugasi-Gal — Fri, 23 Oct 2026 08:32:18 +0000

Annotator is a free, open-source app for drawing on your screen while you explain something. You pick a tool from a small floating toolbar and draw over any app: circle a number, bend an arrow to a button, highlight a line. The marks stay on screen while you keep working in the app underneath, and you can move, restyle or undo them later.

Arrows are placed point by point, so you can bend them around things. Smart Draw turns a quick sketch into a neat box or arrow.

It also zooms around the pointer, puts a spotlight on it, blurs a busy picture for a moment, and shares one part of your screen in a meeting with your drawings in it. There are about 40 tools in all, and there's a short demo on getannotator.app.

No account, nothing leaves your computer, and usage counts are off unless you turn them on.

Why two native apps

It started on the Mac in Swift. When people asked for Windows, I had to decide between a cross-platform UI toolkit and a second native app.

I went native twice. The overlay has to sit above every other window, pass clicks through to the app underneath, and read the screen for zoom and blur. Those are the parts where each OS has its own rules. So the Mac app is Swift, AppKit and Metal, and the Windows app is C# on .NET 10 with WinUI 3, compiled ahead of time with Native AOT.

Two codebases drift apart. Here's what keeps them together, and how one GitHub Actions run ships both.

The Mac is the reference

Every behavior is defined by the Mac app first. The Windows app matches it, and "matches" has to be something a test can check, not a feeling.

A conformance corpus. A small Swift tool, ConformanceExport, runs the Mac's annotation core and writes the results to reference/conformance: how a shape is stored, where a hit test lands, how a rough ellipse is drawn for a given seed. A manifest records a SHA-256 for every file. The Windows test project reads the same files and runs the C# port against them. If the Mac changes a rule and nobody ports it, the Windows tests fail.

A UX reference. The Mac's native UI tests can capture each panel and menu: labels, accessibility identifiers, values, order and frames. A script packs those into reference/ux-reference. The Windows tests compare their own surfaces with that capture, within 1 DIP, with exact labels and order.

Both folders are generated on the Mac and never edited by hand. A Mac change that affects them regenerates them in the same pull request, so the diff shows exactly what Windows now has to match.

Plain rules in review. Every user-visible change ships on both platforms in the same release. If something can't work the same way on Windows, it gets a written deviation in the parity docs instead of a silent difference.

One commit, every channel

A release has a lot of destinations: a signed and notarized Mac disk image and ZIP, a Sparkle update feed, a Homebrew cask, a Microsoft Store bundle, portable Windows ZIPs for winget, and the website. I wanted all of them to come from one commit, built once.

The release notes live in releases/notes.json. That one file produces the changelog, the GitHub release text and the app's own "What's changed" screen. When a version is ready, its entry records the exact source commit. A check then fails if any app code changed after that commit, so the thing I tested is the thing I ship.

The Release workflow only starts by hand, on main. It runs, roughly:

Preflight checks that the commit, the version and the frozen notes agree, and stops before anything is built if they don't.
Validate runs the release and packaging guards.
Sign builds the Mac app, signs it with a Developer ID, notarizes and staples it, and builds the disk image.
Windows packages builds the x64 and ARM64 Native AOT packages, the MSIX bundle and the portable ZIPs. The Windows package version is derived from the shared one, (Major + 1).Minor.Build.0, because the Store wants a version that only goes up.
Publish creates the GitHub release and updates the Homebrew tap.
Store sends the bundle to the Microsoft Store.

After that, a website workflow deploys the site and the update feeds from the published release.

Secrets sit in GitHub environments, each visible only to the job that needs it, and each environment waits for my approval. Pull requests, including ones from forks, get no secrets at all.

Things that bit me

A signing step failed with "a base64 signing secret is invalid". The secret it pointed at was fine. The real problem was a public key variable missing its final =. Now I check every value when signing fails, not only the one I suspect.
The pull request checks used cancel-in-progress. Opening a labelled pull request fires two events at once, one run got cancelled, and its cancelled checks blocked the merge. The checks take seconds, so every event now gets its own run.
The Microsoft Store CLI refuses every command until it has been signed in with reconfigure, even setting its own options. The order matters.

Try it, or help

Annotator is free and Apache-2.0: https://github.com/dorlugasigal/annotator. On the Mac, brew install --cask dorlugasigal/annotator/annotator. On Windows, it's in the Microsoft Store.

The open issues are written so anyone can pick one up. Several need real hardware I don't have: an Intel Mac, an ARM64 PC, a pen display, a second screen at another scale. If you have one of those, an hour of testing helps a lot.

dorlugasigal / annotator

Draw on your screen as you explain. Native apps for macOS and Windows. Free and open source.

Annotator

Draw on your screen as you explain.
Use it in demos, reviews and lessons. Every mark stays editable Native apps for macOS and Windows.

Download · Website · Help · Release notes

annotator-reel.mp4

Recorded in the real Mac app, with a scripted pointer and made-up sample apps.
Music: “Product Launch Advertising Commercial Music” by lNPLUSMUSIC, from Pixabay.

Note

Annotator is in public beta. Expect rough edges, and please report them.

What you can do

Pick a tool in the floating toolbar and draw over any app. Your marks stay on screen while you keep working in the app underneath, and you can move, restyle or undo them later.

Circle Choose Ellipse and circle a number. The Sketchy style keeps it hand-drawn.	Arrow Click to place points and press Return. Drag a point to bend the arrow.
Smart Draw Sketch a box or an arrow, and Smart Draw makes

…

View on GitHub

GitHub Just Proved That Remote Terminal Access Matters - Here's the Mobile IDE I Built for It

Dor Lugasi-Gal — Tue, 14 Apr 2026 08:54:40 +0000

GitHub just shipped copilot --remote - the ability to stream a Copilot CLI session to your phone or browser. Claude Code has had something similar with their --remote flag. The idea is the same: you should be able to reach your coding session from wherever you are.

I agree. In fact, I've been building exactly that in the last month.

TermBeam is an open-source tool that turns your terminal into a mobile IDE. Run npx termbeam, scan the QR code, and you get a full terminal on your phone — any shell, any command, any folder. It's a PWA, so after the first scan you add it to your home screen and it's just an app. One tap and you're in, works on any device since its just a web page.

TermBeam's built-in Copilot SDK integration — markdown rendering, tool call visibility, and the terminal right there on my phone.

I can be pushing my daughter on the swings at the park, or sitting in a bomb shelter during a missile alert, and still pull out my phone, open TermBeam, and create a new session in whatever folder I need. thinking retrospectively, that kind of access isn't a nice-to-have for work-life balance, it's a necessity.

What It Does

npx termbeam
// or
npm install -g termbeam
termbeam

That starts a server, prints a QR code, and when you scan it you get a real terminal session in your browser. Full PTY — whatever shell you use, whatever commands you run. It tunnels through Azure DevTunnels by default so it works from anywhere.

You start it in whatever folder you want, with whatever shell you want. You're not locked into a specific tool's session model. And you can create new sessions from your phone — pick a folder, pick a shell, go.

For something permanent, install it as a background service:

termbeam service install

PM2-managed, starts on boot. Your terminal is always one tap away.

It Runs AI Agents Too

This is where the copilot --remote connection gets interesting. TermBeam has a proper @github/copilot-sdk integration — a dedicated UI pane with markdown rendering, tool call display, and a chat interface, all alongside the terminal. It's built specifically for interacting with Copilot on a small screen.

On top of that, TermBeam auto-detects AI coding tools in your PATH — Copilot CLI, Claude Code, Aider, Codex, OpenCode — and lets you launch any of them from the new session dialog. One tap.

So while copilot --remote gives you remote access to an existing Copilot session, TermBeam gives you the ability to open a full terminal session where Copilot (or any other agent) is just one of the things you can run. Different approach to a similar idea — and they work well together.

What Makes It Usable on a Phone

A terminal on your phone is a gimmick unless the UX is built for touch, like the existing ssh solutions. Here's what makes the difference:

Touch bar. Two rows of dedicated buttons: Esc, Copy, Paste, Home, End, ↑, ←, ↓, →, Enter, Ctrl, Shift, Tab, ^C, and a microphone for voice commands. These are the keys phone keyboards either don't have or hide behind long-presses. This makes running a Copilot session — or vim, or anything — actually practical on a phone.

Multiple tabs at the top, git and folder context info, and the touch bar above your keyboard. This is a real session on my phone.

Command palette. Tap the Tools button on the top right and you get a panel with six sections: Session (new tab, upload/download files, view markdown, close/rename/split/stop sessions, resume agent sessions), Search (find in terminal), View (font size, themes, port preview, code viewer, git changes), Share (copy shareable link), Notifications (toggle push notifications), and System (refresh, clear terminal, about). Every feature is two taps away.

The full command palette. Upload files, view markdown, preview a port, switch themes, check git changes — all from one panel.

Sessions hub. Each session gets a card showing the working directory, shell, PID, git branch, repo name, and git status — which sessions have staged changes, which are clean, how long ago they were active. The "+ New Session" button lets you create a session in any folder, right from your phone.

Three sessions across different projects, each showing git info and status. Tap to connect, "+ New Session" to start one anywhere.

File browser. Browse the session's working directory, search files, view code, download files, and see git changes — all in a side panel. The Changes tab shows what's modified and staged.

The file browser with Files and Changes tabs, browsing a project directory.

And the rest: 40 themes (yes, i got carried away lol), push notifications when commands finish, port preview that proxies your local dev server. It's a PWA with iPhone safe-area support, so it feels native.

Under the Hood

TermBeam spawns a PTY with your shell, serves a React frontend (xterm.js, Zustand, Radix UI) over Express, and bridges them with WebSocket. Azure DevTunnels handles the public URL, or you can choose to work on LAN. Sessions persist when you disconnect.

npx termbeam                           # default: tunnel + auto password
termbeam --password secret --lan       # LAN only, custom password
termbeam --persisted-tunnel            # stable URL across restarts
termbeam resume                        # reconnect from CLI
termbeam service install               # always-on background service

On security — auto-generated passwords, rate-limited login (5 attempts/min/IP), httpOnly cookies, CSP and X-Frame-Options headers, WebSocket origin validation, and single-use QR auth tokens that expire in 5 minutes. Full threat model in SECURITY.md.

1350+ tests across Windows, macOS, and Linux on Node 20, 22, and 24. The less glamorous work was the mobile edge cases — Safari viewport bugs, PTY behavior differences across platforms, WebSocket reconnection after screen locks.

Try It

TermBeam is open source, MIT licensed, v1.20.1 on npm:

npx termbeam

Scan the QR code, add to home screen, and you've got a terminal on your phone.

GitHub · npm · Docs