Some ideas begin as tools inside other ideas.

PaletteWright began that way.

It did not start as a plan to build another color picker, another palette generator, or another place to admire swatches. It started inside Mandelbrot Metal, where color was never just decoration. In a fractal renderer, color is how mathematical behavior becomes visible. A palette is part of the rendering pipeline.

That realization changed how I thought about color.

In Mandelbrot Metal, every pixel begins as a mathematical result: an escape value, an iteration count, or a continuous signal derived from the behavior of a point in the complex plane. But that signal is not yet an image. It has to pass through interpolation, lookup tables, smoothing, display color spaces, HDR presentation, and export logic before it becomes something a person can see, save, and share.

The more I worked on that pipeline, the more obvious one thing became:

Color is data.

And if color is data, it deserves engineering.

At first, the palette system in Mandelbrot Metal had one job: turn numerical fractal structure into beautiful, stable, repeatable images.

That required more discipline than a casual swatch picker. The palette engine needed gradient stops, wide-gamut color, perceptual interpolation, exact lookup-table preview, stepped palettes, dithering, export stability, and reproducible rendering. A fractal bookmark only makes sense if the image can be reconstructed later. A palette only works if it behaves predictably across interactive rendering, high-resolution export, and different displays.

So the palette system became serious.

It needed to know where colors lived.

It needed to preserve relationships between colors.

It needed to preview what would happen before committing to an export.

It needed to treat color not as a loose row of swatches, but as structured input to a larger system.

That was the seed of what eventually became PaletteWright.

For a while, the app carried the working name ChromaForge. I still like that name. It captured the idea of forging color into something durable.

But as the product matured, PaletteWright became the better name.

A wright is a maker. A craftsperson. Someone who builds something useful with care. PaletteWright is not only about forging color. It is about shaping palettes into production color systems: something expressive enough for designers, precise enough for developers, and structured enough to survive the trip from inspiration to implementation.

The name also helped clarify the product.

PaletteWright is not trying to be a gallery of pretty colors. It is a native app for people who need color to do work.

Once you start thinking about color this way, it is hard to stop seeing the same problem everywhere.

App developers do not just need attractive colors. They need colors that survive real interface requirements.

Web designers do not just need inspiration. They need CSS variables, OKLCH values, Display-P3 output, dark-mode behavior, accessible contrast, component roles, and tokens that can move into production.

Design-system teams do not just need a palette. They need a reliable translation layer between creative intent and implementation.

The usual workflow is surprisingly fragile. A palette begins as a screenshot, a photo, a website, a CSS file, a client brand color, or a few manually chosen swatches. Then it gets copied into a design tool, renamed by hand, adjusted by eye, pasted into code, checked for contrast, patched for dark mode, translated into framework-specific roles, and eventually exported into formats that all want the same truth expressed differently.

That is not a color workflow.

That is a chain of opportunities for drift.

PaletteWright grew out of the belief that this should be treated more like compilation.

The core idea is simple:

A source palette goes in. A usable color system comes out.

The source might come from manual stops, a photo, a website, CSS, a design-token file, a Mandelbrot Metal palette, a CSV, a GIMP GPL file, Adobe ASE swatches, or a color copied from somewhere else.

Then PaletteWright does what a compiler should do.

• It normalizes the input.
• It converts colors through perceptual models like OKLab, OKLCH, CIELAB, and CIELCH.
• It analyzes contrast, accessibility, color-vision resilience, semantic roles, component usage, and export readiness.
• It maps raw swatches into practical interface concepts: background, foreground, surface, border, primary, secondary, accent, success, warning, danger, links, focus rings, buttons, cards, alerts, sidebars, charts, and more.

Then it emits something really usable:

CSS variables. Semantic CSS. Modern CSS with OKLCH and Display-P3 output. Tailwind themes. shadcn/ui roles. SwiftUI colors. Android XML. Jetpack Compose. Flutter. React Native. DTCG design-token JSON. Tokens Studio. Style Dictionary. Figma Variables.

The goal is not to make another place to admire swatches.

The goal is to move color from inspiration to implementation without losing meaning along the way.

The Mac became the center of PaletteWright because color work on a desktop often starts with capture.

You see a color in a website, a design comp, an app, a chart, a PDF, a client deck, a screenshot, or a browser inspector. The best tool is the one that lets you grab it immediately and move on.

That is why PaletteWright now has a Mac-first workflow.

Quick Pick samples one onscreen color and immediately copies it in your default format.

Multi-Pick samples several onscreen colors in a row and keeps the clipboard updated with the collected values.

The menu-bar extra keeps capture and recent colors available without reopening the main window.

Settings let you choose the default copy format: Hex, RGB, OKLCH, Display-P3, SwiftUI, CSS Variable, or a custom template.

Paste / Convert Color handles the other common case: the color already exists as text. Paste a hex value, RGB string, OKLCH value, Display-P3 color, CSS variable, or token snippet, preview the parsed color, then copy it as any built-in or custom output.

That matters because fast capture is not a luxury. It is where the workflow begins. A color tool that makes capture feel heavy loses the moment. PaletteWright is designed so the first step can be almost invisible, while the later steps remain deep enough for production work.

A picker is useful, but a picker is only the beginning.

After capture, the real questions begin:

• Does this palette hold together?
• Does it work in light and dark themes?
• Does the foreground pass against the background?
• Does the danger color still read inside a badge?
• Do chart colors remain distinguishable?
• Can this become SwiftUI code, CSS variables, Tailwind tokens, Figma Variables, and a CI-friendly audit artifact without hand translation?

PaletteWright is built around those questions.

It can inspect WCAG contrast pairs, preview APCA-style readability, simulate protanopia, deuteranopia, and tritanopia, and test colors in component contexts instead of only isolated swatches.

It can compile light, dark, and high-contrast variants from the same source palette.

It can repair failing WCAG AA semantic pairs with OKLCH-aware foreground adjustments.

That repair step matters because accessibility should not feel like punishment. It should feel like refinement. The designer should still recognize the palette. The developer should still get usable tokens. The app should help bring the system into compliance without flattening its character.

There is a continuity between Mandelbrot Metal and PaletteWright that I find satisfying.

Mandelbrot Metal turns mathematics into visual experience.

PaletteWright turns visual intent into production systems.

They sound like different problems, but they share the same underlying principle: beauty becomes more powerful when the pipeline behind it is disciplined.

In Mandelbrot Metal, the equation is not enough. You need precision, interpolation, palette lookup, color management, display handling, and export consistency.

In PaletteWright, a good palette is not enough. You need semantic roles, accessibility checks, dark-mode behavior, component previews, framework mapping, token output, shareable designer handoff, and automation hooks.

Both apps are about respecting the path from raw source to finished result.

One starts with mathematical structure.

The other starts with color inspiration.

Both ask the same question:

How do we preserve the original spark while making it reliable enough to ship?

PaletteWright is a native SwiftUI app because color work benefits from immediacy.

When you are shaping a palette, you should be able to see the gradient, inspect the stops, sample from the screen, preview UI components, simulate color-vision differences, repair contrast, and export code without feeling like the tool is fighting you.

The Mac is the primary platform because it is where developers and designers already live with websites, source files, design comps, browser inspectors, app windows, and production repos.

iPad and iPhone still matter, but they serve a different mode: touch-first palette building, photo inspiration, validation, and portable review. The same color system should travel across those moments.

That is also why PaletteWright includes a command-line audit helper. The native app is the authoring surface. The CLI is the automation surface. Together, they let color live both in the designer's hands and in the developer's build process.

The most interesting software often emerges from pressure.

Mandelbrot Metal needed a better palette engine because fractal images depend on color in unusually deep ways. That pressure created reusable ideas: perceptual interpolation, LUT previews, export stability, wide-gamut handling, palette metadata, and a serious respect for reproducibility.

PaletteWright is what happened when those ideas stepped outside the fractal.

It is a product born from a practical question:

What if color palettes were treated like real build artifacts?

Not screenshots.

Not vibes.

Not a row of disconnected swatches.

True Artifacts!

Inputs that can be imported, captured, normalized, analyzed, transformed, repaired, mapped, exported, audited, and reused.

That is the heart of PaletteWright.

Mandelbrot Metal began with a lifelong fascination with mathematical beauty and the technology needed to finally explore it in real time.

PaletteWright begins from a related fascination: the point where beauty becomes usable.

Color has always carried emotion. It gives software identity, mood, hierarchy, warmth, urgency, calm, delight, and clarity. But in modern apps and websites, color also has a job to do. It has to adapt. It has to pass contrast checks. It has to survive dark mode. It has to become tokens. It has to compile into multiple frameworks. It has to remain recognizable after all of that transformation.

That is the problem PaletteWright is built to solve.

It takes color seriously because color is not the last step.

Color is part of the system.

And when the system is built well, the original inspiration does not get lost.

It becomes something you can ship.

Michael