Building a Safer macOS-Style Setup for Windows 11

I like the visual language of macOS: the dock, the clean menu bar, the rounded surfaces, and especially the small red, yellow, and green window controls. Windows 11 is already a polished operating system, but I wanted to see how close I could get to that macOS desktop feeling without doing the risky thing most transformation packs do: modifying system files.

This started as a customization experiment, but it turned into a small software project. The result is a safer macOS-style Windows 11 setup built around reversible tools, with my own utility, MacTrafficLights, handling the macOS-style window control buttons.

This post is part of the Observatory section because it is not just a theme showcase. It is a build log about desktop UX, Win32 limitations, tradeoffs, and how far you can push Windows customization while still keeping the system recoverable.

The problem with full transformation packs

The fastest way to make Windows look like macOS is to install a full macOS transformation pack. That also tends to be the most dangerous way.

A lot of those packs touch sensitive areas of the system. Some patch theme files. Some modify Explorer behavior. Some depend on old Windows internals. Some ask for restarts before replacing pending system files. When something goes wrong, uninstalling is not always clean.

For this setup, I wanted a stricter rule: If I cannot remove it without repairing Windows, I do not want it in the setup.

So the goal became clear. I wanted the macOS feel, but I did not want to patch System32, replace DWM, modify Explorer binaries, inject into apps, or depend on anything that could break Windows updates.

The setup goal

The target desktop experience was simple:

• a macOS-style dock
• a top menu bar
• clean dark-window styling
• macOS-inspired traffic-light window controls
• no permanent system patching
• no risky theme engine modifications
• easy uninstall

Tools like MyDockFinder already cover a big part of the macOS-style desktop experience: the dock, Finder-like behavior, and the top bar. The missing piece for me was the window controls.

Windows puts close, maximize, and minimize buttons on the top-right. macOS puts close, minimize, and maximize on the top-left as colored traffic lights. That difference is small, but visually it changes the whole desktop.

So I built my own version.

Introducing MacTrafficLights

MacTrafficLights is a lightweight Windows 11 utility that adds macOS-style traffic-light controls to normal app windows.

The buttons are simple: red closes the window, yellow minimizes the window, green maximizes or restores the window.

The important part is how it works. MacTrafficLights does not patch Windows. It does not replace system DLLs. It does not inject code into Spotify, Discord, Brave, Edge, Explorer, or any other app.

Instead, it uses separate lightweight overlay windows that sit above the normal Windows title bar area. Those overlays cover the native controls visually and provide macOS-style buttons on top.

That is not as powerful as a real native Windows theme engine, but it is much safer.

Project links:
GitHub repository · Latest release

Why I avoided true embedding

The obvious question is: why not embed the buttons directly into every app window?

On Windows, doing that properly usually means using one of the approaches I wanted to avoid: DLL injection, subclassing windows from another process, patching app windows at runtime, modifying system theme behavior, or replacing/altering native caption rendering.

Those methods can work, but they come with real costs. They can trigger antivirus warnings. They can fail on elevated administrator windows. They can break when apps update. They can behave badly with Chromium apps, Electron apps, UWP apps, games, or protected windows.

For a personal desktop experiment, that is not worth it. MacTrafficLights stays on the safer side. It behaves more like a visual companion layer than a system modification.

What changed in v4

Earlier versions proved the idea, but they were not good enough.

The first builds tracked only the foreground window. That meant if two windows were visible, only one got traffic lights. It looked fine in a simple screenshot, but it felt incomplete during normal use.

The v4 rewrite changed the architecture completely.

Instead of one overlay chasing one window, v4 uses a multi-window overlay manager. Every visible normal app window can get its own traffic-light overlay. The active window gets brighter buttons, while background windows get dimmed controls. That makes the result feel closer to macOS, where inactive windows still have visible controls but they are less emphasized.

v4 also became z-order aware. If one window covers another window’s control area, the covered window’s overlay is hidden instead of floating above the foreground window. That was an important fix because an overlay that ignores window stacking instantly feels fake.

The result is still not native rendering, but it is a more serious version of the idea.

Handling custom title bars

The hardest apps are not always the classic Windows apps. They are the custom ones.

Spotify, Discord, browsers, and Electron-based apps often draw their own top bars. Some have search boxes, profile buttons, navigation icons, queues, side panels, or custom controls near the same area where the overlay wants to appear.

That created two problems: the overlay background could visibly mismatch the app title bar, or the traffic lights could overlap actual app UI.

To reduce that, MacTrafficLights v4 uses different masking behavior depending on the app. Normal apps can use a color-matched patch over the native Windows controls. Apps like Spotify and Discord use a smaller micro-mask style so the overlay does not become a giant rectangle over custom UI.

There is still a tradeoff here. Windows apps are not consistent. Some use native title bars, some use custom-drawn regions, and some change layout depending on window size. A universal overlay has to make practical guesses.

That is why MacTrafficLights includes tray options for alignment, button size, app exclusion, and custom micro-mask behavior.

Dragging windows

Dragging was another edge case.

When a window moves, an overlay has to follow it. If it updates too slowly, the native Windows controls briefly become visible. If it updates too aggressively, the utility can feel laggy.

v4 keeps the native controls covered while the target window is moving, then restores the traffic-light rendering when the window settles. This keeps the illusion cleaner without modifying the actual app window.

Again, it is not the same as native compositor-level rendering. It is a practical compromise that keeps the setup reversible.

Safety design

The main design rule is that MacTrafficLights should be removable without repairing Windows.

It does not modify System32, patch uxtheme.dll, replace Explorer, replace DWM, inject DLLs into apps, permanently alter app window styles, or require a custom boot process.

If I exit MacTrafficLights, the overlays disappear and the original Windows controls are visible again. If I do not want it anymore, I can remove it like a normal utility.

That is the biggest difference between this setup and a traditional transformation pack.

Build and run

Extract this folder to a permanent location, for example Documents\MacTrafficLights.

Double-click Build-and-Run.bat.

After it builds, MacTrafficLights.exe can be launched directly.

The build uses the .NET Framework C# compiler already present on most Windows 11 installations. No third-party compiler or NuGet packages are required.

Windows SmartScreen can warn about MacTrafficLights.exe because it is a locally compiled unsigned personal executable. The complete source is included in MacTrafficLights.cs.

What the final setup includes

My current macOS-style Windows 11 setup is built from safer layers:

• MyDockFinder for the dock and top menu bar experience
• MacTrafficLights v4 for macOS-style window controls
• a macOS-style wallpaper
• matching icons where needed
• dark mode across Windows and apps
• optional cursor and sound tweaks

The goal is not to pretend Windows has become macOS. It has not. The goal is to make Windows feel visually cleaner while keeping it stable, reversible, and usable for daily work.

Known limitations

MacTrafficLights is still an overlay utility, not a native Windows shell replacement.

That means there are limits:

• some protected or elevated windows may not respond to normal commands
• games and exclusive fullscreen apps are not ideal targets
• unusual custom title bars can require manual adjustment
• aggressive topmost windows can fight for visual priority
• app updates can change layouts and require tuning

For me, those limitations are acceptable because the safer design is the point. I would rather have a reversible utility with a few edge cases than a deep system patch that looks cleaner but creates repair problems later.

Why this matters

Desktop customization is usually treated like a visual hobby, but there is an engineering side to it.

A theme can look good in a screenshot and still be badly designed. If it breaks updates, modifies protected files, or cannot be removed cleanly, then it is not a good setup for daily use.

This project became a reminder that good customization should respect the system it runs on. The cleanest-looking solution is not always the best one. Sometimes the better solution is the one that leaves the operating system untouched.

Final thoughts

MacTrafficLights started because I wanted three small colored buttons on Windows. The real project became figuring out how to do that without turning the system into a fragile theme experiment.

v4 is the first version that feels close to the direction I wanted: multi-window support, safer overlays, active and inactive states, app-specific behavior, and no system patching.

It is not perfect, and it is not pretending to be native macOS. But as part of a complete macOS-style Windows 11 setup, it gets surprisingly close while staying practical.

That is the kind of customization I want to keep building: visual, experimental, reversible, and safe enough to actually use.