build-macos-apps

build-macos-apps

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

7Sterne
0Forks
Aktualisiert 1/22/2026
SKILL.md
readonlyread-only
name
build-macos-apps
description

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

<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:

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>

**Ask the user:**

What would you like to do?

  1. Build a new app
  2. Debug an existing app
  3. Add a feature
  4. Write/run tests
  5. Optimize performance
  6. Ship/release
  7. Something else

Then read the matching workflow from workflows/ and follow it.

| Response | Workflow | |----------|----------| | 1, "new", "create", "build", "start" | `workflows/build-new-app.md` | | 2, "broken", "fix", "debug", "crash", "bug" | `workflows/debug-app.md` | | 3, "add", "feature", "implement", "change" | `workflows/add-feature.md` | | 4, "test", "tests", "TDD", "coverage" | `workflows/write-tests.md` | | 5, "slow", "optimize", "performance", "fast" | `workflows/optimize-performance.md` | | 6, "ship", "release", "notarize", "App Store" | `workflows/ship-app.md` | | 7, other | Clarify, then select workflow or references |

<verification_loop>

After Every Change

# 1. Does it build?
xcodebuild -scheme AppName build 2>&1 | xcsift

# 2. Do tests pass?
xcodebuild -scheme AppName test

# 3. Does it launch? (if UI changed)
open ./build/Build/Products/Debug/AppName.app

Report to the user:

  • "Build: ✓"
  • "Tests: 12 pass, 0 fail"
  • "App launches, ready for you to check [specific thing]"
    </verification_loop>

<when_to_test>

Testing Decision

Write a test when:

  • Logic that must be correct (calculations, transformations, rules)
  • State changes (add, delete, update operations)
  • Edge cases that could break (nil, empty, boundaries)
  • Bug fix (test reproduces bug, then proves it's fixed)
  • Refactoring (tests prove behavior unchanged)

Skip tests when:

  • Pure UI exploration ("make it blue and see if I like it")
  • Rapid prototyping ("just get something on screen")
  • Subjective quality ("does this feel right?")
  • One-off verification (launch and check manually)

The principle: Tests let the user verify correctness without reading code. If the user needs to verify it works, and it's not purely visual, write a test.
</when_to_test>

<reference_index>

Domain Knowledge

All in references/:

Architecture: app-architecture, swiftui-patterns, appkit-integration, concurrency-patterns
Data: data-persistence, networking
App Types: document-apps, shoebox-apps, menu-bar-apps
System: system-apis, app-extensions
Development: project-scaffolding, cli-workflow, cli-observability, testing-tdd, testing-debugging
Polish: design-system, macos-polish, security-code-signing
</reference_index>

<workflows_index>

Workflows

All in workflows/:

File Purpose
build-new-app.md Create new app from scratch
debug-app.md Find and fix bugs
add-feature.md Add to existing app
write-tests.md Write and run tests
optimize-performance.md Profile and speed up
ship-app.md Sign, notarize, distribute
</workflows_index>

You Might Also Like

Related Skills

cache-components

cache-components

137Kdev-frontend

Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.

vercel avatarvercel
Holen
component-refactoring

component-refactoring

128Kdev-frontend

Refactor high-complexity React components in Dify frontend. Use when `pnpm analyze-component --json` shows complexity > 50 or lineCount > 300, when the user asks for code splitting, hook extraction, or complexity reduction, or when `pnpm analyze-component` warns to refactor before testing; avoid for simple/well-structured components, third-party wrappers, or when the user explicitly wants testing without refactoring.

langgenius avatarlanggenius
Holen
web-artifacts-builder

web-artifacts-builder

47Kdev-frontend

Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, or shadcn/ui components - not for simple single-file HTML/JSX artifacts.

anthropics avataranthropics
Holen
frontend-design

frontend-design

47Kdev-frontend

Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.

anthropics avataranthropics
Holen
react-modernization

react-modernization

28Kdev-frontend

Upgrade React applications to latest versions, migrate from class components to hooks, and adopt concurrent features. Use when modernizing React codebases, migrating to React Hooks, or upgrading to latest React versions.

wshobson avatarwshobson
Holen
tailwind-design-system

tailwind-design-system

28Kdev-frontend

Build scalable design systems with Tailwind CSS v4, design tokens, component libraries, and responsive patterns. Use when creating component libraries, implementing design systems, or standardizing UI patterns.

wshobson avatarwshobson
Holen