How I Keep the Mac and Windows Versions of My App in Sync When AI Writes the Code: One Home for the Specs

Hi, I'm Shu.

I'm building Memotori, an on-device transcription and summary app, for both Mac and Windows. Almost all of the code is written by AI (Claude).

I just shipped 1.1.0 on both platforms. It's the first release where the Mac and Windows versions got the same features, with the same wording.

What made that possible wasn't how the code was written. It was giving the specs a single home. In this post I'll show how that works, with the real files. I hope it helps anyone building an app for more than one OS with AI.

The problem: two versions slowly drifting apart

The Mac version (Swift) and the Windows version (C#) live in separate repositories. At first, I asked the AI to "add this feature" in each repository separately.

Little by little, they drifted:

• The same feature had different button labels on each platform
• A bug fixed on one side was still there on the other
• I forgot that some features existed on only one side

The AI only knows the repository it has open. Whatever we decided for the other version, it only knows if I explain it every time. And I forget to explain.

What I did: a spec folder that sits outside both versions

I created a shared working folder above the two repositories, with a spec/ folder for specs that apply to both.

Memotori/
├── Memotori-mac/   ← Mac repository
├── Memotori-win/   ← Windows repository
├── spec/           ← specs shared by both versions
├── releases/       ← release notes shared by both
└── CLAUDE.md       ← working rules for the AI

The AI works in this folder, so it sees both codebases and the specs at once.

Inside spec/ there are four parts:

• features/ — the current spec, one file per feature
• changes/ — numbered change proposals (0001, 0002…), with the background and what changes
• differences.md — what we deliberately don't align, or haven't aligned yet
• ideas.md — ideas that aren't specs yet

The key is separating "the current spec" from "change proposals." I want to keep each proposal with the discussion behind it. But when I just want to know how things work today, rereading ten proposals is painful. So once a proposal ships on both platforms, I rewrite the current spec in features/.

The flow for adding a feature

The working rules live in CLAUDE.md, which the AI reads every time. Adding a feature goes like this:

1. Write the spec first. Copy the template into changes/, give it a number, and add a row to the status table.
2. Ship it on both versions. If we stop with only one side done, say so in the status table and the spec.
3. One PR per platform. Each PR mentions the spec number (e.g. spec 0008).
4. After merging, update the spec's status and the table, and rewrite the current spec in features/.

The spec template is just this:

# NNNN Feature name

| Platform | Status | PR |
|---|---|---|
| macOS | Not started | — |
| Windows | Not started | — |

## Background       why we're adding it
## Spec             what it does, and how it behaves
## Wording          on-screen text in Japanese and English
## Settings         what each setting is called on Mac and on Windows
## Differences      what can't be aligned, and why

What worked 1: write the UI text in the spec, in both languages

This helped the most. Button labels and messages go into the spec's "Wording" table, in both Japanese and English. The implementation uses that text as-is.

That way, the AI doesn't invent wording on the spot, and the Mac and Windows button labels stopped drifting.

Some words do change by OS, though. Where the Mac says "this Mac," Windows says "this PC." So I made one substitution table:

• this PC → this Mac
• File Explorer → Finder
• Recycle Bin → Trash

Specs are written with the Windows words, and the Mac version substitutes them using this table.

What worked 2: say clearly when something is one-sided

The status table records, for every feature, whether it's "Not started / In progress / Done / Won't do" on Mac and on Windows.

"Won't do" matters too. For example, one bug fix (spec 0016) was marked "Won't do (the check doesn't exist there)" for Windows, because Windows never had that check in the first place. Writing down the reason means that six months later, I won't wonder, "Did we forget this on Windows?"

The same goes for bug fixes. When we fix something on one side, we check whether the other side has the same bug. That's also a rule in CLAUDE.md.

What worked 3: keep the release notes in the shared folder too

releases/1.1.0.md lists the specs included in the release, plus the "What's New" text for the stores in Japanese and English. Both stores use exactly the same text.

What didn't work

To be honest, there are still holes.

Forgetting to update the status. The headline feature of 1.1.0, to-dos (spec 0008), is on both platforms and already shipped. But when I looked back while writing this post, the status table still said "Not started." Neither I nor the AI had done the "update the status" step after merging. Even with a system in place, that last rewrite is easy to miss. Now I cross-check the status table whenever I write the release notes.

Writing specs takes effort. Writing a spec even for small changes felt like a chore at first. But when I talk it through with the AI at the spec stage, the "what happens in this case?" questions come up early. There's less rework after implementation, so overall I think it's faster.

Memotori 1.1.0, built this way

Finally, let me introduce Memotori 1.1.0, built with this process. Ten specs, 0004 through 0013, shipped on both Mac and Windows.

You can now pull to-dos out of your meetings and check them off as you go. Suggested to-dos aren't added to your list automatically; you review them first.

Press "Extract To-dos" on a transcript and suggestions appear on the right. Phrases like "by next Friday" become suggested due dates. (The screenshot shows the Japanese UI.)

Added to-dos go into one list across all your meetings, sorted by due date.

Other changes in this release:

• Summaries and to-dos now live in a pane on the right, with copy, delete, and stop in its header.
• Rename recordings in your history, and keep the meeting date and time separately.
• Choose the microphone and language right on the recording screen. Speakers are now identified after you stop recording.
• If your selected microphone can't be found, you can pick another one and start recording.

Transcription and summaries run entirely on your device. Your audio and transcripts never leave it.

• Mac (App Store): https://apps.apple.com/app/memotori/id6814051112?pt=359959&ct=devto-en&mt=8
• Windows (Microsoft Store): https://apps.microsoft.com/detail/9N7KPTFRFX2M?cid=devto-en
• Questions, bug reports, and requests on Discord: https://discord.gg/rrH2DnJJjr

Previous dev logs:

• I Built an On-Device Transcription App for Mac and Windows with AI — Without Touching the Code
• One Week of Promoting My Indie App: The Real Numbers, and Two Traps I Fell Into

Thanks for reading.

Originally published on Medium.