GNOME-macOS-Tahoe: a macOS look for a GNOME desktop

A theme, and the extensions it expects you to pair with it

GNOME-macOS-Tahoe is a macOS Tahoe like theme for GNOME desktops, and the project is written in CSS, which is what a GTK theme is.

The interesting part of the README is not the theme itself but the two lists that sit above the installer. The first is the recommended applications, which are Ulauncher as the application launcher, and either GNOME Tweaks or Refine for the settings, with Refine marked as the recommended one and available on Flathub.

The second is the recommended GNOME Shell extensions, and there are nine of them. Open Bar, Blur My Shell, Dash to Dock, Gnome 4x UI Improvements, Space bar, Tiling Shell, User Themes, Vitals, and the wallpapers from the repository's own.config/walls directory.

That list is a specification of what the theme needs. Those extensions are the parts of the shell the theme's look depends on, and the README recommends installing them alongside the theme. Installing the theme without them produces a hybrid, and the README is effectively saying so by listing them as recommended.

The project is published under a licence the repository metadata does not classify, so the state of the licence is worth checking before you redistribute anything derived from it. The default branch is main, the last push was on 2026-08-22, and the recent releases are v0.6.7 from that day, v0.6.6 from 2026-08-19, and v0.6.5 from 2026-08-02, so the project is shipping frequently and at a pre-1.0 version.

One installer, an interactive menu, and a set of flags

The install is a clone and a script:

git clone https://github.com/kayozxo/GNOME-macOS-Tahoe
cd GNOME-macOS-Tahoe
./install.sh

The script will automatically install Gum if it is needed, which is the charmbracelet library that provides the interactive prompts. No flags are needed, because the installer shows an interactive menu that guides you through the options: install the light, dark, or both themes, generate and install accent colour variants, whether all sixteen or specific ones, install the generated accent variants into the themes directory, install the libadwaita override for modern GTK4 apps and the GNOME Shell, install the extras which are the MacTahoe icons, the MacTahoe wallpapers, the WhiteSur cursors, a Ulauncher theme, and a GDM theme, uninstall the themes, and a help and documentation entry.

The same operations are available as flags, and the README describes this path as the advanced one:

# Install themes
./install.sh -l    # Light theme only
./install.sh -d    # Dark theme only
./install.sh -u    # Uninstall

# Install wallpapers
./install.sh -w    # Tahoe 26 dynamic wallpapers

# Generate accent colors
./install.sh --colors        # Generate all 16 variants
./install.sh --color blue    # Generate specific color

So there are three installation flags for the theme itself, one for the wallpapers, and two for the accent colours. The -w flag is worth noting separately, because the Tahoe 26 dynamic wallpapers are a different kind of asset from a static theme, and they are the piece that most directly produces the macOS impression on a Linux desktop.

After the install you reboot or log out and back in, and the README says your GNOME should now resemble macOS Tahoe. There is also a .config directory in the repository, which holds the configuration the theme expects, including the extensions document the update instructions point you back to.

Sixteen accent colours, and how they become themes

The accent colour system is the feature that has grown most, and the README is specific about the scope. Tahoe now supports 16 beautiful accent colors with complete theming support across GTK4, GTK3, and GNOME Shell.

The sixteen are listed in a two column table, and they are named after colour families rather than single hues: Blue, Green, Purple, Pink, Orange, Red, Teal, and Indigo on one side, with Rose, Emerald, Violet, Amber, Cyan, Lime, Sky, and Slate on the other.

The generation and installation are separate steps, which is a useful distinction. The flags are:

# Generate all 16 accent color variants
./install.sh --colors

# Generate and install specific color (dark & light)
./install.sh --color blue

# Dark mode only with purple accent
./install.sh -d --color purple

# Light mode only with green accent
./install.sh -l --color green

The mode and the colour are orthogonal, so a dark theme with a purple accent and a light theme with a green accent are both one flag away, and the menu entry for installing generated variants into the themes directory is what makes them selectable.

After installation you select your preferred variant in Tweaks under Appearance, with names like Tahoe-Dark-Blue, Tahoe-Light-Green, and Tahoe-Dark-Amber. The accent colours then apply to all applications and to the GNOME Shell elements including the dash, notifications, and popups.

The repository has a generate_accent_variants.py script at the top level, which is where the generation actually happens, and the install script is what calls it. That is a much better arrangement than maintaining sixteen hand-tuned colour sets, and it is why the accent list can grow without the theme itself being rewritten.

The libadwaita problem, which the theme cannot fix properly

The libadwaita section is the most honest part of the README, and the heading itself says the fix is not perfect.

Since the release of Gnome 43.0, more and more built-in apps use libadwaita, and libadwaita does not support custom themes, which means the appearance of an app using libadwaita cannot be changed through gnome-tweaks or dconf-editor. The README puts it plainly: for users who love custom themes, it is really sucks.

The workaround is to use the theme file to overwrite the gtk-4.0 configuration file. The result, as described, is that all GTK4 apps are forced to use one theme and cannot be switched, and in particular cannot switch to dark mode. To change the theme, you re-overwrite the gtk-4.0 configuration file with a new one. The README acknowledges the method is not perfect but notes that at the moment it is the only possible way to continue using themes for libadwaita's applications.

The install commands are the -la variants, and the combination of mode and colour carries through:

./install.sh -l -la          # install light theme for libadwaita
./install.sh -d -la          # install dark theme for libadwaita
./install.sh -d --color blue -la    # install dark blue theme for libadwaita
./install.sh -l --color green -la    # install light green theme for libadwaita

The note on the -la flag is that it also applies the accent colour to the GNOME Shell elements, the dash, notifications, and popups, when it is used together with --color.

So the theme has two modes of operation. The normal mode restyles the GTK3 and shell surfaces that a theme can reach. The -la mode goes further and replaces the GTK4 configuration file, which reaches the libadwaita applications but at the cost of locking every GTK4 app to one theme.

That trade is worth understanding before you run it, because a user who switches between light and dark after installing with -la will find that the switch has stopped working for the modern applications, and the fix is to run the installer again with the other mode.

Flatpak, and the permission that explains the whole problem

The Flatpak section is short and solves a problem that would otherwise look like a bug.

If you use Flatpak applications, you run this to fix the theme issue:

sudo flatpak override --filesystem=xdg-config/gtk-3.0 && sudo flatpak override --filesystem=xdg-config/gtk-4.0

The reason is the sandbox. A Flatpak application cannot read your GTK configuration directory by default, so a theme installed in your home directory is simply invisible to it, and the application renders with the default theme. The override grants the sandboxed applications access to exactly the two directories the theme lives in, and nothing else.

The second half connects the theme to Flatpak for the GTK 3 case, with a parameter called --flatpak, used as ./install.sh --flatpak. The README is careful about the scope of this, noting that Snap is not supported.

So there are two separate mechanisms here, and they are worth keeping apart. The flatpak override is a system level permission change you apply with sudo, and it affects every Flatpak application on the machine. The --flatpak parameter is a theme side setting, and it is scoped to the GTK 3 configuration.

The fact that this needs documenting at all tells you something about the shape of the project. A theme that is meant to make the whole desktop look consistent has to deal with the fact that the desktop is a mix of sandboxed and unsandboxed applications, and the permission boundary is the reason a theme can look right in your browser and wrong in a Flatpak application.

The repository, and how updating works

The top level of the repository is small, and each entry is easy to account for.

There is the gtk/ directory, which holds the theme itself, and the src/ directory, which is where the source the theme is generated from lives. There is install.sh, the interactive installer, and generate_accent_variants.py, the script that produces the sixteen accent variants. There is a .config/ directory holding the configuration the theme expects, including the walls directory with the wallpapers and the extensions document, plus a screenshots/ directory and a .github/ directory.

The update procedure is three steps and it is not a package manager upgrade. You change into the cloned directory, you run git pull origin main, and you run ./install.sh again. Then you continue from the extensions document in the .config directory.

That last part is the hint about how this project is used. Because the theme depends on a specific set of shell extensions, and because the configuration for those lives in the repository, the flow is to pull, reinstall, and then reapply the extension configuration, which is a dotfiles style workflow rather than a package update. The repository topics list includes dotfiles, which confirms that reading.

The fact that the extensions list and the theme configuration ship together is the real design decision in the project. A macOS-like desktop is not a colour scheme, it is a set of coordinated pieces, and shipping them as one repository with a script that installs both is how the pieces stay coordinated.

Editorial conclusion

Adopt GNOME-macOS-Tahoe if you want a GNOME desktop that reads as macOS and you are prepared to install the shell extensions it expects, because the theme alone will not get you there. Do not adopt it if you want the GNOME defaults preserved, since the install modifies your own configuration. Verify first that your shell extensions and the accent variant you pick agree on the palette, since the theme colours the shell and the extensions colour the rest.

Frequently asked questions

Official sources

1. Issues
2. kayozxo/GNOME-macOS-Tahoe on GitHub
3. README
4. Releases