Compositor: a free Photoshop alternative for Mac that you build in Xcode

What Compositor replaces, and for whom

The README states the motivation plainly: Photoshop costs too much, and GIMP does not feel familiar enough to stay in flow. Compositor is the author's answer, a full-featured image editor that is free and open source, built around the compositing and post-processing workflow rather than around illustration or photo management. The target reader is a Mac user who already knows Photoshop's toolset and keyboard shortcuts and wants the same muscle memory without a subscription.

That framing matters, because it sets the scope. This is not a Lightroom-style catalog tool and not a vector design app. The feature list is organized around assembling a final pixel image: layers and folders with blend modes, layer masks, clipping masks, adjustment layers, layer effects, selections, retouching brushes, and a transform system that stays non-destructive. If your work is stacking exposures, masking subjects, and grading a composite, the surface area is aimed at you. If your work is drawing, page layout, or batch cataloging, the README does not claim to cover it.

How layers, masks and GPU effects fit together

The architecture visible in the README is a conventional layer stack with two deliberate departures. The first is that transform is non-destructive: move, scale, rotate and flip keep the image at full resolution no matter how small you display it. That is a real design commitment, since it means the transform is stored as state rather than baked into pixels, and it is what makes free distort with axis locking and exact numeric position, size, scale and angle values meaningful.

The second is that layer effects (Stroke, Drop Shadow, Color Overlay, Inner Shadow, Outer Glow) are rendered on the GPU and remain editable at any time. The README does not describe the rendering pipeline beyond that, so treat the claim as a statement of behavior rather than an architectural detail. What it does tell you is the intended workflow: effects are parameters you can revisit, not pixels you commit to.

Masks get their own treatment. You can paint, fill, invert, blur and feather a mask, and link or unlink it so the mask transforms independently of its layer. Folders behave as groups with their own opacity, and a folder's opacity dims everything inside it. Clipping masks and folder masks are both supported, and Merge Down, Merge Layers and Merge Group all sit on Command-E. Layers can be dragged between open projects, which is unusual and useful for assembling a composite from separate files.

Building Compositor from source with Xcode

There is no published installer described in the README. The stated path is to build from source, and the requirements are macOS 26.5 or later and Xcode 26 or later. The build instructions are one sentence: open Compositor.xcodeproj and run the Compositor scheme. The repository layout matches that, with Compositor.xcodeproj, Compositor/, CompositorTests/ and CompositorUITests/ at the top level.

git clone https://github.com/robbietilton/Compositor.git
cd Compositor
open Compositor.xcodeproj

After opening the project in Xcode, select the Compositor scheme and run it. The README gives no command-line build target, no package manager step, and no prebuilt download link, so the Xcode route is the only one documented.

For a first real use, the README's own example workflow is the PSD import. Compositor imports JPEG, PNG, HEIC, TIFF and Photoshop PSD, but the PSD support is explicitly limited to 8-bit RGB, not PSB and not CMYK. PSD folders, masks, a subset of blend modes, and fill rectangles and ellipses stay editable, while text and other vectors become pixels. The README states that a conversion report is shown before anything is applied, so the first thing to do with a real file is import it and read that report rather than clicking through it. Export is JPEG with a live preview on Shift-Option-Command-S, and Copy Merged is available for moving a flattened result elsewhere.

The PSD boundary is the limitation that will bite first

The clearest constraint in the README is the PSD import scope. 8-bit RGB only, no PSB, no CMYK. For a tool positioned as a Photoshop alternative for compositing, that is the boundary most likely to decide adoption. A composite that arrives as a 16-bit RGB PSD will not round-trip at full depth, and any CMYK document from a print pipeline is out of scope entirely. The README does not document a conversion path for either case.

The second constraint is rasterization. Text and other vectors in an imported PSD become pixels. Compositor has its own Type tool with inline multiline editing, draggable and resizable paragraph boxes, font, size, color, alignment and spacing controls, and the ability to transform text or use it as a clipping mask. But that live text is Compositor's text, not the text recovered from someone else's PSD. If your workflow depends on round-tripping editable type between applications, this is the wrong tool.

The README also does not document rollback or undo behavior for the conversion report, and it does not describe what happens to unsupported blend modes beyond saying a subset is supported. Those are gaps to probe with your own files rather than assume.

Where Compositor sits next to GIMP and Krita

The README names its own comparison: Photoshop costs too much, and GIMP does not feel familiar enough. That is the gap Compositor targets, and it explains the emphasis on Photoshop-style keyboard shortcuts throughout, remappable under Edit > Keyboard Shortcuts. GIMP is cross-platform and has a long plugin ecosystem, but its interaction model is its own. Compositor is macOS-only, Swift, and deliberately imitates the shortcut and tool conventions of the application it replaces.

Krita is a different comparison the README does not make. Krita is built around painting and illustration, with brush engines as the center of gravity. Compositor's feature list puts layers, masks, selections, retouching and adjustment layers first, with a single Brush tool offering size, hardness, opacity and smoothing in Paint or Erase mode. If your work is painting, that difference in emphasis matters more than any shared layer stack. If your work is compositing, Compositor's selection and mask tooling (Select Subject, Expand, Contract, Feather, Content-Aware Fill that can extend an image past its edges, Load Layer as Selection) is the part that maps to the job.

The other real difference is distribution. GIMP and Krita ship signed binaries. Compositor's README documents a release script rather than a download, and the script expects credentials you must supply yourself.

Releasing your own build, licensing and upkeep

The README documents the release path in scripts/release.sh. It builds a Release version, signs it with Developer ID, notarizes and staples it, and packages it into dist/Compositor-<version>.dmg. The dependencies are all kept outside the repository: a Developer ID Application certificate in the login keychain, notarization credentials stored with xcrun notarytool store-credentials "compositor-notary", and create-dmg installed via brew install create-dmg.

brew install create-dmg
xcrun notarytool store-credentials "compositor-notary" \
  --apple-id <your-apple-id> --team-id <your-team-id> --password <app-specific-password>
./scripts/release.sh

That is a meaningful maintenance cost. Building for yourself is cheap; distributing a notarized build to anyone else requires a paid Apple Developer account and a credential setup the repository deliberately does not contain. The README also mentions automatic updates that are signed and notarized, and the repository carries an appcast.xml at the top level, which is the shape of a Sparkle-style update feed. The README does not name the update framework, so verify that yourself if update behavior matters to you.

On licensing: Compositor is MIT, with the LICENSE file at the repository root. MIT permits modification and redistribution, including in closed products, provided the copyright notice and permission notice are preserved. That is the general shape of the license, not legal advice for your situation. One practical consequence worth noting: because the project is MIT and the README invites you to add, remove or modify any feature, forking is explicitly within the intended use.

What to check before you commit a project to it

The README is detailed about features and thin about internals. It does not describe the rendering pipeline beyond noting that layer effects run on the GPU, it does not document memory behavior for large documents, and it does not describe undo semantics for destructive operations like Content-Aware Fill. Those are the areas where a compositing tool either holds up or does not.

The practical sequence is to build the Compositor scheme from Compositor.xcodeproj, then run one representative PSD through the import and read the conversion report in full before applying it. That single step exercises the 8-bit RGB limit, the blend mode subset, the fill shape preservation and the text rasterization at once. If the report is clean for your files, the rest of the feature list is conventional enough that the shortcut remapping under Edit > Keyboard Shortcuts will tell you quickly whether the muscle memory transfers.

Editorial conclusion

Adopt Compositor if you work on macOS 26.5 or later, you are comfortable building from Xcode, and your compositing pipeline stays inside 8-bit RGB with JPEG, PNG, HEIC, TIFF or PSD sources. Skip it if you need CMYK or PSB files, 16-bit editing, or a signed binary you can hand to colleagues who will not open Xcode. Before committing, open Compositor.xcodeproj and build the Compositor scheme, then import one of your own PSDs and read the conversion report it shows before applying anything, since that report is where the 8-bit RGB limit and the rasterized text will surface.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. robbietilton/Compositor on GitHub