# Build Macos Apps

Build professional native macOS apps in Swift with SwiftUI and AppKit.

- Repository: https://github.com/glittercowboy/taches-cc-resources (1986 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-04-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add glittercowboy/taches-cc-resources --skill build-macos-apps -g -a claude-code -y`
Codex: `npx skills add glittercowboy/taches-cc-resources --skill build-macos-apps -g -a codex -y`
Cursor: `npx skills add glittercowboy/taches-cc-resources --skill build-macos-apps -g -a cursor -y`
Gemini CLI: `npx skills add glittercowboy/taches-cc-resources --skill build-macos-apps -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add glittercowboy/taches-cc-resources`

## Description

Build professional native macOS apps in Swift with SwiftUI and AppKit. Full lifecycle - build, debug, test, optimize, ship. CLI-only, no Xcode.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

<essential_principles>
## How We Work

**The user is the product owner. Claude is the developer.**

The user does not write code. The user does not read code. The user describes what they want and judges whether the result is acceptable. Claude implements, verifies, and reports outcomes.

### 1. Prove, Don't Promise

Never say "this should work." Prove it:
```bash
xcodebuild build 2>&1 | xcsift  # Build passes
xcodebuild test                  # Tests pass
open .../App.app                 # App launches
```
If you didn't run it, you don't know it works.

### 2. Tests for Correctness, Eyes for Quality

| Question | How to Answer |
|----------|---------------|
| Does the logic work? | Write test, see it pass |
| Does it look right? | Launch app, user looks at it |
| Does it feel right? | User uses it |
| Does it crash? | Test + launch |
| Is it fast enough? | Profiler |

Tests verify *correctness*. The user verifies *desirability*.

### 3. Report Outcomes, Not Code

**Bad:** "I refactored DataService to use async/await with weak self capture"
**Good:** "Fixed the memory leak. `leaks` now shows 0 leaks. App tested stable for 5 minutes."

The user doesn't care what you changed. The user cares what's different.

### 4. Small Steps, Always Verified

```
Change → Verify → Report → Next change
```

Never batch up work. Never say "I made several changes." Each change is verified before the next. If something breaks, you know exactly what caused it.

### 5. Ask Before, Not After

Unclear requirement? Ask now.
Multiple valid approaches? Ask which.
Scope creep? Ask if wanted.
Big refactor needed? Ask permission.

Wrong: Build for 30 minutes, then "is this what you wanted?"
Right: "Before I start, does X mean Y or Z?"

### 6. Always Leave It Working

Every stopping point = working state. Tests pass, app launches, changes committed. The user can walk away anytime and come back to something that works.
</essential_principles>

<intake>
**Ask the user:**

The rest: https://github.com/glittercowboy/taches-cc-resources/blob/HEAD/skills/expertise/macos-apps/SKILL.md