If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ochococo/Design-Patterns-In-Swift shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 22+ active contributors
• Distributed ownership (top contributor 31% of recent commits)
• GPL-3.0 licensed
• CI configured
• ⚠ Stale — last commit 2y ago
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ochococo/Design-Patterns-In-Swift repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ochococo/Design-Patterns-In-Swift.

What it runs against: a local clone of ochococo/Design-Patterns-In-Swift — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ochococo/Design-Patterns-In-Swift | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 675 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ochococo/Design-Patterns-In-Swift. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ochococo/Design-Patterns-In-Swift.git
#   cd Design-Patterns-In-Swift
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ochococo/Design-Patterns-In-Swift and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ochococo/Design-Patterns-In-Swift(\\.git)?\\b" \\
  && ok "origin remote is ochococo/Design-Patterns-In-Swift" \\
  || miss "origin remote is not ochococo/Design-Patterns-In-Swift (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "source/Index/welcome.swift" \\
  && ok "source/Index/welcome.swift" \\
  || miss "missing critical file: source/Index/welcome.swift"
test -f "source/contents.md" \\
  && ok "source/contents.md" \\
  || miss "missing critical file: source/contents.md"
test -f "generate-playground.sh" \\
  && ok "generate-playground.sh" \\
  || miss "missing critical file: generate-playground.sh"
test -f "source/behavioral/header.md" \\
  && ok "source/behavioral/header.md" \\
  || miss "missing critical file: source/behavioral/header.md"
test -f "source/creational/header.md" \\
  && ok "source/creational/header.md" \\
  || miss "missing critical file: source/creational/header.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 675 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~645d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ochococo/Design-Patterns-In-Swift"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

An interactive Xcode Playground repository that demonstrates all 23 Gang of Four design patterns implemented in Swift 5.0, organized into Behavioral (11 patterns), Creational (6 patterns), and Structural (8 patterns) categories. It provides runnable, copy-paste-ready Swift code examples for each pattern with inline documentation, available in both English and Chinese versions as downloadable .playground.zip files. Dual-source, script-generated playground structure: raw Swift source code lives in source/ and source-cn/ directories (split by pattern type: behavioral/, creational/, structural/) with header markdown files; shell scripts (generate-playground.sh, generate-playground-cn.sh) auto-compile these into interactive Xcode Playgrounds (Design-Patterns.playground/, Design-Patterns-CN.playground/) organized by pattern category as .xcplaygroundpage files with Contents.swift. Zip archives are generated for easy distribution.

Swift developers (iOS, macOS, server-side) who want to learn or reference design patterns through executable playground code rather than static documentation. Particularly useful for junior engineers onboarding to Swift projects, code reviewers standardizing architecture decisions, and teams building pattern libraries.

Mature and stable. The repo has been consistently maintained with a comprehensive CI/CD pipeline (GitHub Actions workflow for auto-generating playgrounds), supports Swift 5.0+, includes both English and Chinese documentation, and has clear contribution guidelines. No test suite visible, but the playgrounds themselves serve as living documentation. Last activity shows active maintenance of playground generation tooling.

Low risk for a reference/educational project. Single maintainer (@ochococo) with no apparent dependency management (it's pure Swift with no external packages), so no supply-chain concerns. No issue tracking or open PRs visible in the file list, making it unclear if bugs or enhancement requests are being tracked. The main risk is that playground generation scripts (generate-playground.sh, generate-playground-cn.sh) could break silently if Xcode versions change, since the implementation is hidden in shell scripts.

Active maintenance of the playground generation pipeline (.github/workflows/generate-playground.yml suggests automated playground rebuilding on pushes). The Chinese translation is actively maintained in parallel (source-cn/, CONTRIBUTING-CN.md, README-CN.md). No open PRs or specific feature work is visible, indicating the pattern library itself is feature-complete and focused on stability and accessibility.

Clone the repository and open the playground directly in Xcode:

git clone https://github.com/ochococo/Design-Patterns-In-Swift.git
cd Design-Patterns-In-Swift
open Design-Patterns.playground

Or download the pre-built zip: Design-Patterns.playground.zip from the repo root, unzip, and open in Xcode 10.2+.

Daily commands: Open Design-Patterns.playground in Xcode and navigate between pages via the left sidebar (Index → Creational → Behavioral → Structural). Each .xcplaygroundpage file has runnable Swift code that executes in the playground's REPL. Click ▶ in the playground editor or use Cmd+Enter to execute code blocks.

• source/Index/welcome.swift — Entry point for the entire English design patterns playground; all contributors must understand the navigation structure and indexing approach
• source/contents.md — Master table of contents that maps all 23 design patterns across behavioral, creational, and structural categories; essential for organizing new pattern additions
• generate-playground.sh — Build script that compiles source Swift files into the executable Xcode playground; any contributor changing source structure must verify this script still works
• source/behavioral/header.md — Template and documentation header for all behavioral patterns; establishes the code documentation standard followed across all 11 behavioral pattern files
• source/creational/header.md — Template and documentation header for all creational patterns; establishes the code documentation standard followed across all 7 creational pattern files
• source/structural/header.md — Template and documentation header for all structural patterns; establishes the code documentation standard followed across all 9 structural pattern files
• CONTRIBUTING.md — Contributor guide explaining how to add new patterns, regenerate playgrounds, and maintain dual English/Chinese versions

Add a New Design Pattern (English)

1. Create a new Swift file in the appropriate source directory (behavioral, creational, or structural) with the pattern name (source/behavioral/your_pattern.swift (example))
2. Write the pattern implementation following the template structure and documentation style established in header.md files (source/behavioral/header.md)
3. Add the pattern entry to the master contents list (source/contents.md)
4. Run the generate-playground.sh script to regenerate the Xcode playground from source files (generate-playground.sh)
5. Verify the pattern appears in the generated playground pages (Design-Patterns.playground/Pages/Behavioral.xcplaygroundpage/Contents.swift (example))

Add a New Design Pattern (Chinese Translation)

1. Create a new Swift file in the source-cn directory with the same pattern name and translated comments (source-cn/behavioral/your_pattern.swift (example))
2. Translate the pattern implementation using the Chinese header template for consistency (source-cn/behavioral/header.md)
3. Add the translated pattern entry to the Chinese contents list (source-cn/contents.md)
4. Run the generate-playground-cn.sh script to regenerate the Chinese Xcode playground (generate-playground-cn.sh)
5. Update the README-CN.md file with the new pattern in the table of contents (README-CN.md)

Update Pattern Documentation Style

1. Modify the header template file to reflect new documentation standards (source/behavioral/header.md)
2. Apply identical changes to the structural patterns header (source/structural/header.md)
3. Apply identical changes to the creational patterns header (source/creational/header.md)
4. Run generate-playground.sh to rebuild all playgrounds with the updated template (generate-playground.sh)

• Swift 5.0 & Xcode Playgrounds — Native Apple development environment for interactive, runnable code examples that developers can experiment with directly
• Shell Scripts (generate-playground.sh) — Simple file templating to generate large Xcode playgrounds from modular source files; low dependency overhead
• GitHub Actions Workflow — Automated regeneration of playgrounds on every commit ensures playgrounds always stay in sync with source files
• Dual English/Chinese Source Trees — Enables independent maintenance of two translated versions using identical build process and automation

• Monolithic generated Xcode playground vs. modular SPM package

  • Why: Playground format is more interactive and accessible for learning; does not require compilation or build toolchain
  • Consequence: Playgrounds are auto-generated artifacts (not version-controlled in raw form), adding build complexity but improving user experience

• 27 separate source files (one per pattern) vs. single file with all patterns

  • Why: Modularity makes it easy to add/update individual patterns and maintain documentation per-pattern
  • Consequence: Build script must concatenate files in correct order; slightly higher maintenance complexity

• Shell-based code generation vs. Swift-based code generation

  • Why: Shell is simple, portable, and requires no Swift runtime dependencies
  • Consequence: String templating is basic; harder to maintain complex transformations

• Does not serve as a reference implementation for production use; examples are simplified for learning
• Does not provide language bindings beyond Swift (Go, Python, Java patterns are not covered)
• Does not include interactive testing frameworks; patterns are read-only examples
• Does not provide performance benchmarks or comparative analysis of patterns

The playground generation is not automatic locally—you must manually run ./generate-playground.sh after editing Swift source files, or your changes won't appear in the playground. The scripts assume a Unix-like environment (they use shell syntax). Xcode version compatibility is implicit: playgrounds generated for Xcode 10.2+ may not open in older versions. The Chinese playground (Design-Patterns-CN.playground) is generated separately via generate-playground-cn.sh and requires that script to stay in sync. No version constraints or environment variables are documented, but Xcode 10.2+ is the hard requirement from the README.

• Gang of Four (GoF) Design Patterns — This repo is a Swift implementation of the 23 foundational patterns from 'Design Patterns: Elements of Reusable Object-Oriented Software' (1994); understanding GoF patterns is essential for recognizing and communicating architectural decisions in any codebase
• Behavioral Patterns (Observer, State, Strategy, etc.) — 11 of this repo's 23 patterns focus on managing object communication and responsibility; mastering these is critical for building loosely-coupled, event-driven systems in Swift
• Creational Patterns (Singleton, Factory, Builder) — These 6 patterns control object instantiation; understanding them is essential for writing testable, dependency-injectable Swift code and avoiding tight coupling at object creation points
• Structural Patterns (Decorator, Adapter, Proxy, Composite) — These 8 patterns solve object composition and interface adaptation problems; they enable flexible architectures that can evolve without modifying existing classes
• Protocol-Oriented Programming (Swift protocols as pattern enablers) — Swift's protocol-first design makes patterns like Adapter, Proxy, and Decorator more elegant than in class-based languages; this repo demonstrates Swift-idiomatic pattern implementations
• Playground-Based Learning — Xcode Playgrounds allow interactive, live-executed pattern examples without boilerplate; this repo's format enables fast pattern learning and experimentation directly in Xcode
• Swift 5.0 Language Features (Codable, PropertyWrapper, Result type implications) — This repo targets Swift 5.0+, so patterns shown use modern Swift features; understanding how patterns adapt to Swift's type system (protocols, generics, value types) differs from Java/C++ examples

• raywenderlich/swift-algorithm-club — Companion reference for algorithm implementations in Swift; overlaps in educational scope and Playground delivery format
• realm/realm-swift — Production Swift database framework that uses many of these design patterns internally; good real-world reference for pattern application
• pointfreeco/swift-composable-architecture — Modern Swift architecture framework that builds on top of design patterns (Redux, middleware, state management); shows how these patterns scale to real apps
• apple/swift-nio — Apple's async networking framework for Swift; demonstrates Reactor/Observer patterns and protocol-oriented design at production scale
• refactoringguru/design-patterns-swift — Alternative design patterns reference in Swift by Refactoring Guru; similar scope but different code style and explanations

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add Structural design pattern implementations (Proxy and Proxy-like patterns)

The source-cn/structural directory is missing implementations for Proxy pattern and Chain variants. Looking at the file listing, there are 7 structural patterns documented (adapter, bridge, composite, decorator, facade, flyweight) but the repo lacks Proxy pattern which is a fundamental structural pattern in the Gang of Four. This would complete the structural patterns suite and provide valuable examples for Swift developers.

• [ ] Create source/structural/proxy.swift with Proxy pattern implementation
• [ ] Create source-cn/structural/proxy.swift with Chinese version
• [ ] Update source/contents.md to include Proxy in the structural patterns table
• [ ] Update source-cn/contents.md to include Proxy in the structural patterns table
• [ ] Run generate-playground.sh and generate-playground-cn.sh to regenerate playground files
• [ ] Verify both Design-Patterns.playground and Design-Patterns-CN.playground include the new Proxy page

Add unit tests for Swift playground code validation

Currently the repo has no automated tests validating that the Swift code in source files actually compiles and runs correctly. The .github/workflows/generate-playground.yml workflow only regenerates playgrounds but doesn't verify code correctness. Adding a Swift Package Manager test target would catch syntax errors and logical issues before they reach users downloading the playgrounds.

• [ ] Create Tests directory with Swift Package Manager structure
• [ ] Add a test file that parses and validates each pattern source file (source/.swift, source/behavioral/.swift, source/creational/.swift, source/structural/.swift)
• [ ] Create a GitHub Actions workflow (.github/workflows/test.yml) that runs swift test on pull requests
• [ ] Document test execution in CONTRIBUTING.md with instructions for local testing
• [ ] Update the workflow to fail PR checks if any pattern code doesn't compile

Create side-by-side comparison documentation for English and Chinese versions

The repo maintains two complete parallel versions (source/ and source-cn/, README.md and README-CN.md) but lacks guidance for contributors on keeping translations synchronized. Currently there's no documented process for ensuring both versions stay in sync, which could lead to English-only features missing from the Chinese translation or vice versa.

• [ ] Create docs/TRANSLATION_GUIDE.md documenting the translation workflow and file structure mapping
• [ ] Add a section to CONTRIBUTING.md explaining how to contribute to both English and Chinese versions
• [ ] Create a GitHub issue template (.github/ISSUE_TEMPLATE/translation-sync.md) for reporting translation inconsistencies
• [ ] Document which files must be kept in sync (source-cn/ mirrors source/, README-CN.md mirrors README.md, etc.)
• [ ] Add a checklist to PULL_REQUEST_TEMPLATE.md reminding contributors to update both language versions

• Add unit test or validation code to source/behavioral/observer.swift to verify the observer pattern correctly notifies all subscribers—currently the file has no test harness
• Create a examples/ directory with a runnable command-line tool (e.g., a state machine or factory demo) that imports and demonstrates one pattern in a real-world context, not just playground pseudocode
• Document the exact Xcode and macOS version constraints in README.md (currently only says 'Xcode 10.2', but unclear if Swift 5.0 runs on older macOS releases); add a version matrix table

This is a design patterns educational repository with minimal security risk. The codebase consists primarily of Swift playground files containing design pattern implementations. No dependencies, secrets, injection vectors, or infrastructure configurations were detected. The repository follows a documentation-first approach with no backend services, databases, or sensitive operations. No critical or high-severity vulnerabilities identified. Minor recommendations focus on standard repository best practices.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.