DEV Community: Miura Acoustic

Neumorphism vs. Glassmorphism: I Had AI Build Both for My App, Then Picked Glass

Miura Acoustic — Mon, 09 Nov 2026 13:51:40 +0000

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).

In 1.1.1, I gave the app a completely new look: frosted glass, with your desktop showing through, blurred, behind the window. In other words, glassmorphism.

I didn't pick glass right away, though. I had the AI build prototypes of both neumorphism and glassmorphism, used them side by side, and only then decided. This post is about how that went.

Why: the app looked "just like the default"

Until now, Memotori mostly used the operating system's standard controls as they were. Nothing wrong with them for everyday use, but lined up as store screenshots, it looked plain.

So I wanted a more modern look. Two styles came up:

Neumorphism: controls in the same color as the background, with a light shadow on one side and a dark shadow on the other, so they look pressed out of clay. You read it by its shadows.
Glassmorphism: translucent panels stacked on a blurred background, like frosted glass. You read it by its transparency, blur, and bright edges.

Glass was actually my first idea. But my first version was too timid: on Mac, the OS sidebar and toolbar already look like glass, so only a few hand-painted parts would change; on Windows, only the sidebar and the summary pane would become frosted glass. The AI made browser mock-ups for me, and next to the current app they barely looked different. So I dropped it.

Next I asked, "What about neumorphism?" The AI pushed back before building anything, for four reasons:

Everything is the same color as the background and lifted only by shadows, so the difference between what you can click and what you can't is small. Not great for an app where pressing the wrong thing (start/stop recording) matters.
On a dark background the shadows nearly disappear, so dark mode loses the 3D effect.
The app is built from the OS's standard controls, so buttons, inputs, and lists would all have to be redrawn. A lot of work.
It tends to break with screen readers and high-contrast mode.

It also suggested a middle ground: add a soft shadow to just the record button.

I still liked the look, so I compared mock-ups of "everything" and "just the record button." To my surprise, the full version looked better. Comparing in words wasn't going to settle it, so I decided to actually build it.

What I did: two prototypes of the Windows version

The best part of building with AI, I think, is that prototypes are cheap. By hand, even one of these would take days. This time, two rounds of browser mock-ups plus two in-app prototypes, all the way to a decision, took one day (November 8).

Both prototypes were built in the Windows version, each on its own branch. The one I didn't pick was never merged; I kept the branch as it is.

The neumorphism prototype

Made the background a single color, and built a control that casts a light shadow to the top left and a dark shadow to the bottom right. Buttons sink in while pressed.
Inputs and checkboxes got a "pressed in" color; list rows became raised cards.
Fixed glitches (shadows cut off at the edge of a list, small buttons in the corner looking puffy) by showing the AI screenshots.

The neumorphism prototype. Background, cards, and buttons are all the same color, lifted only by shadows.

Behind the scenes, this was harder than expected. Windows UI controls have no built-in way to cast a light shadow and a dark shadow at the same time, so the AI built its own control. First the shadows didn't show up at all, then they were offset, then only the dark one vanished. The cause was different every time: rounded corners clipping the content to their frame, padding shifting the shadows, the blur of the light shadow painting over the dark one. The AI kept taking screenshots and fixing things until it finally came together.

The glassmorphism prototype

Once the neumorphism version was in shape, I built glass on a separate branch. This time, not the timid version: I asked for "not just a see-through background — make the buttons and everything translucent too, for a modern feel."

Changed the window background to show the desktop behind it, blurred. Cards, buttons, and inputs became translucent panels with bright edges.
Edges catch the light at the top left and fade toward the bottom right; panels are slightly brighter at the top.
Made the transparency adjustable in settings.

The glass prototype. The colors of the wallpaper show through the whole window, blurred.

Hands-on: why glass won

Side by side, neumorphism had real strengths.

It's unusual. A screen where everything is the same color and rises out of the background through shadows alone is something you rarely see in other apps.

At a glance, buttons were easier to find than with glass. They clearly stick out, so I knew where to click right away. The AI's worry that clickable controls would be hard to tell apart didn't hold up when I actually used it.

Neumorphism in dark mode. Notice how much space the shadows take up between rows.

I still passed on it, for two reasons.

The shadows waste space. To look raised, every control needs room around it for its shadow. Rows and buttons spread out, and less fits in the same window. During the prototype, I even had to widen the gaps further just to stop the shadows from being cut off at the edges.

It felt a little clunky. For all its novelty, the overall impression was slightly dated and heavy.

Glass just puts translucent panels on the background, so it doesn't need any extra space. It looks clean and simple, and it goes the same direction operating systems and other apps are heading right now. So I went with glass.

Glass in dark mode. Rows stay close together, and the light on their edges still shows their shapes.

I wrote the decision into the spec (spec 0019), including why neumorphism was rejected. The neumorphism prototype stays on its own branch, unmerged.

Small decisions along the way

The details I settled while trying things out went into the spec too.

Corner radius: 12 for cards, 6 for buttons and inputs. At 8 or more, checkboxes turned into circles and looked like radio buttons.
In light mode, the bottom-right edge gets a faint shadow color. On a bright background, a white edge alone made the panel's outline disappear.
Transcript lines are not panels. There are many of them, and a panel per line was too busy.
Users choose the transparency. Settings has a "Background transparency" slider (0–100, default 50), because the more you see through, the harder text can be to read over a bright wallpaper. Even at maximum, a little color is always laid on top so text stays readable.
Where to put the color overrides. The neumorphism prototype taught us that color overrides placed in the app-wide settings didn't reach the controls. With glass, we loaded them in the window and in dialogs from the start. Building two prototypes paid off here.
No blur-strength setting. The prototype offered "strong / light" blur, but Windows doesn't let you set the blur radius, and switching between its two kinds barely changed anything. A setting that does nothing shouldn't exist, so I removed it.

Background transparency: 0 (nearly opaque) on the left, 100 (most transparent) on the right. It changes the moment you move the slider.

The same look on Mac

Based on that spec, the Mac version got the same look. Different OS, though, so not everything carries over as is:

On Mac, toolbar buttons already sit inside the OS's own glass frame. Stacking another panel on top was too much, so they keep the OS look.
Pickers and menus can't be restyled, so they stay standard.
The record start/stop buttons became translucent red.

Store screenshots of the Mac version: dark on top, light below.

Writing these per-platform differences into the spec means that later, nobody has to wonder, "Windows does this differently — is that a bug or on purpose?" (I wrote about how the specs are organized in my previous dev log.)

What went wrong

To be honest, bugs showed up after release.

On Windows, switching between light and dark could crash the whole app. The custom glass background was calling the OS in the wrong order. On top of that, text stayed pale white in light mode and was hard to read.

Both happened because I polished the prototype in dark mode and didn't test switching to light enough. When changing how an app looks, I should have been much more deliberate about testing every combination of light/dark and bright/dark wallpapers.

What I took away

When in doubt, build both. With AI, prototypes are cheap. Using them showed me things screenshots can't. I only noticed how much space the shadows take once they were in the real app. And the AI's worry about clickable controls turned out not to be a problem in practice.
Write down why you said no. If I ever want neumorphism again six months from now, the reason I dropped it is in the spec, and I won't have to build the same prototype twice.
Modern is fine, but keep it readable. Glass shows what's behind it, so some wallpapers make text harder to read. That's why transparency is adjustable and why transcript lines aren't panels.

Memotori 1.1.1

Finally, let me introduce Memotori 1.1.1, which ships with this new look.

A fresh, frosted-glass look. You can adjust the background transparency in settings.
Choose your appearance: system, light, or dark.
Silent stretches are no longer transcribed, so words that were never said are less likely to appear.
Lines the app isn't sure it heard correctly are shown faded, so they're easy to check.
Recording keeps going even if your microphone or earphones switch mid-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-design-en&mt=8
Windows (Microsoft Store): https://apps.microsoft.com/detail/9N7KPTFRFX2M?cid=devto-design-en
Questions, bug reports, and requests on Discord: https://discord.gg/rrH2DnJJjr

Previous dev logs:

Thanks for reading.

Originally published on Medium (link added once the Medium story is live).

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

Miura Acoustic — Sun, 08 Nov 2026 09:09:31 +0000

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:

Write the spec first. Copy the template into changes/, give it a number, and add a row to the status table.
Ship it on both versions. If we stop with only one side done, say so in the status table and the spec.
One PR per platform. Each PR mentions the spec number (e.g. spec 0008).
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:

Thanks for reading.

Originally published on Medium.