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/Juanpe/About-SwiftUI 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.

AVOID — Stale and unlicensed — last commit 4y ago

• 47+ active contributors
• Distributed ownership (top contributor 40% of recent commits)
• ⚠ Stale — last commit 4y ago
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ 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 Juanpe/About-SwiftUI repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Juanpe/About-SwiftUI.

What it runs against: a local clone of Juanpe/About-SwiftUI — 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 Juanpe/About-SwiftUI | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 3 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 1320 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Juanpe/About-SwiftUI. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Juanpe/About-SwiftUI.git
#   cd About-SwiftUI
#
# 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 Juanpe/About-SwiftUI and re-run."
  exit 2
fi

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

# 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 "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "main.swift" \\
  && ok "main.swift" \\
  || miss "missing critical file: main.swift"
test -f "_config.yml" \\
  && ok "_config.yml" \\
  || miss "missing critical file: _config.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1320 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1290d)"
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/Juanpe/About-SwiftUI"
  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).

About-SwiftUI is a curated resource index repository that aggregates official Apple documentation, WWDC videos, community tutorials, books, courses, and open-source projects related to SwiftUI—Apple's declarative UI framework announced at WWDC 2019. It serves as a single reference point for SwiftUI learning materials across all Apple platforms (iOS, macOS, watchOS, tvOS). Simple structure: a single README.md as the main content file, organized by clear sections (Apple docs, WWDC videos, tutorials, books, courses, websites, articles, testing, Xcode extensions, community repos). Assets/ folder contains banner images and Sketch design files. _config.yml provides GitHub Pages configuration. No source code—purely documentation and curated links.

iOS/macOS developers transitioning from UIKit/AppKit to SwiftUI, and beginners learning SwiftUI for the first time. Also useful for community maintainers and educators who want to discover or contribute high-quality SwiftUI learning resources.

This is a mature, actively maintained reference repository. It's a documentation/curation project (not a library), so traditional metrics like test coverage don't apply. The repo demonstrates consistent community engagement with a well-organized README structure and clear contribution guidelines, making it reliable for pointing developers to official and vetted community resources.

Low risk for a curation repository—there are no code dependencies, runtime risks, or breaking changes. The main risk is link rot: external URLs to tutorials, articles, and videos may become outdated or removed. Single-maintainer risk is present, but the nature of the repo (curation + links) makes it resilient to abandonment.

The repository is stable in maintenance mode. Based on the README structure, recent activity likely involves curating new community resources, adding emerging SwiftUI libraries to the repositories section, and keeping Layout component links up-to-date as the SwiftUI ecosystem matures.

Clone and view locally: git clone https://github.com/Juanpe/About-SwiftUI.git && cd About-SwiftUI && open README.md (or view on GitHub). No build step required—this is a pure documentation repository.

Daily commands: No runtime. This is a reference repository. View the README.md in any Markdown viewer or GitHub browser: https://github.com/Juanpe/About-SwiftUI

• README.md — Primary entry point documenting SwiftUI resources, links, and curated content structure that all contributors must understand
• main.swift — Core Swift implementation file containing example SwiftUI code that demonstrates the framework patterns covered in this repository
• _config.yml — Jekyll site configuration file that governs how the repository documentation is built and deployed

• README.md (Markdown, GitHub flavor syntax) — Acts as central knowledge hub, organizing and categorizing SwiftUI learning resources, tutorials, and documentation from Apple and community
  • Failure mode: Broken external links, outdated resource references, poor organization reduces discoverability
• main.swift (Swift 5.1+, SwiftUI framework) — Provides concrete, runnable SwiftUI code examples demonstrating framework patterns, views, and best practices
  • Failure mode: Syntax errors or outdated API usage prevent compilation; poor examples confuse learners
• Assets (Images & Design) (Sketch, JPEG image format) — Manages visual branding and banner graphics displayed in README and deployed site
  • Failure mode: Broken image links or missing files prevent proper README rendering
• _config.yml (YAML, Jekyll 3.x) — Configures Jekyll static site generator for GitHub Pages deployment, controlling site metadata and build settings
  • Failure mode: Misconfiguration prevents site deployment or causes incorrect metadata rendering

• GitHub Repository → README.md — Main repository content synchronized to README display on GitHub and exported to Jekyll static site
• Assets/ → README.md — Banner images linked and embedded in README.md for visual branding on landing page
• README.md → GitHub Pages — Jekyll processes README.md and _config.yml to generate static HTML site accessible via web browser
• main.swift → Developer Environment — Developers copy example code into Xcode or Swift playgrounds for local compilation and execution
• README.md → External Resources — README contains hyperlinks to Apple documentation, WWDC videos, and third-party tutorials for deeper learning

Add a new SwiftUI resource link

1. Edit README.md and locate the appropriate section (e.g., '📚 Documentation', '📹 WWDC videos', or community tutorials) (README.md)
2. Add a new entry with markdown link formatting following the existing style: - [Resource Title](URL) - Brief description (README.md)
3. Maintain alphabetical or logical ordering within each section to preserve readability (README.md)

Add a new SwiftUI code example

1. Create or extend the example code in main.swift with a new SwiftUI view or pattern demonstration (main.swift)
2. Add comments explaining the SwiftUI pattern being demonstrated (main.swift)
3. Reference the new example in README.md under an appropriate section if creating a notable pattern (README.md)

Customize repository branding

1. Edit the banner design in Assets/banner_about_swift.sketch using Sketch application (Assets/banner_about_swift.sketch)
2. Export updated design as JPG to Assets/banner_about_swift.jpg (Assets/banner_about_swift.jpg)
3. Update site configuration in _config.yml if changing site title or description metadata (_config.yml)

• Markdown (README.md) — Simple, universally readable format for curating and organizing SwiftUI learning resources and links
• Swift (main.swift) — Native language for SwiftUI examples, allowing developers to run sample code directly on macOS or in Xcode playgrounds
• Jekyll (_config.yml) — Enables static site generation and GitHub Pages hosting for accessible web-based documentation viewing
• Git/GitHub — Provides version control and collaborative contribution workflow for community-driven resource curation

• Content-focused repository without application logic

  • Why: Repository serves as a reference and learning hub rather than a functional framework implementation
  • Consequence: Minimal runtime dependencies and complexity, but limited interactive learning or hands-on tooling

• Centralized README.md as primary information hub

  • Why: GitHub's default display of README maximizes discoverability and reduces navigation friction
  • Consequence: README can become lengthy; requires careful organization with table of contents to remain navigable

• External resource linking over embedded tutorials

  • Why: Avoids duplication of Apple and third-party documentation while remaining a unified discovery point
  • Consequence: Depends on external sites remaining available; requires periodic maintenance to fix broken links

• Not an interactive SwiftUI course or hands-on coding platform
• Does not provide SwiftUI runtime execution environment
• Not a replacement for official Apple SwiftUI documentation
• Does not include automated testing or CI/CD workflows
• Not designed as a Swift package or framework dependency

• Avg cyclomatic complexity: ~1.5 — Repository is primarily documentation and reference content with minimal algorithmic or architectural complexity; main.swift contains only example code without complex business logic
• Largest file: README.md (250 lines)
• Estimated quality issues: ~1 — Limited code review issues due to minimal executable code; primary concern is documentation maintenance (link validity, up-to-date resource references)

• Link rot in resource collection (Medium) — README.md: External resource links to third-party tutorials and community content may become broken or outdated over time without active maintenance
• Single monolithic example file (Low) — main.swift: All SwiftUI examples consolidated in one file reduces modularity and makes it difficult to isolate and demonstrate specific patterns
• Manual documentation synchronization (Low) — README.md & main.swift: Code examples in main.swift and references in README.md require manual coordination; no automated consistency validation

• README.md (User Experience / Discoverability) — Large curated resource list can become difficult to navigate without a detailed, well-maintained table of contents; information discovery depends on reader scrolling
• main.swift (Code Organization) — Single example file lacks namespace organization; adding many examples increases file size and reduces code clarity
• External resource links (External Dependency) — Dependency on third-party websites for content delivery introduces latency and availability risk beyond repository control

No significant hidden traps—this is a documentation repository. One minor consideration: external links can break over time (link rot). Maintainers should periodically validate URLs in README.md. GitHub Pages requires proper _config.yml setup if converting to a static site, but the repo works fine as a regular GitHub repository viewed in the browser.

• Declarative UI — The core paradigm shift in SwiftUI—developers describe what the UI should be, not imperative steps to build it, making code more concise and maintainable
• View Composition & Reusability — SwiftUI's lightweight View struct protocol enables extreme composability where small views nest into larger ones, a pattern explored extensively in community tutorials linked here
• Property Wrappers (@State, @Binding, @ObservedObject) — Swift language feature leveraged by SwiftUI for reactive state management—critical to understand for building stateful apps and is heavily covered in courses/articles indexed here
• Combine Framework Integration — SwiftUI's publisher/subscriber pattern for reactive data flow—many community resources teach Combine-backed data models for SwiftUI views
• SwiftUI Previews — Real-time, interactive preview system in Xcode that allows live iteration on UI without rebuilding—a core feature that makes SwiftUI development faster, central to tutorials in this repo
• Dynamic Type & Accessibility — SwiftUI bakes in automatic support for system text scaling and accessibility features; understanding this prevents common app accessibility regressions
• Platform-Agnostic View Hierarchy — One SwiftUI codebase can target iOS, macOS, watchOS, and tvOS with platform-specific adaptations using conditional modifiers—a unique capability highlighted throughout community examples

• apple/swift-org-website — Official Swift.org source—contains canonical Swift language documentation and RFC discussions, complementary to SwiftUI-specific resources
• pointfreeco/swift-composable-architecture — Production-grade SwiftUI state management architecture heavily cited in community learning materials linked in this repo
• realm/SwiftUIX — Community-driven SwiftUI extensions and missing components library—a prime example of the type of repos curated in About-SwiftUI
• apple/swift-evolution — Official Swift Enhancement Proposals repository—governs language and stdlib changes that directly impact SwiftUI APIs
• Juanpe/iOS-Developer-Roadmap — Sibling project by the same maintainer providing broader iOS learning structure into which SwiftUI fits as a modern UI framework

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.

Create a RESOURCES.md with categorized and annotated SwiftUI learning materials

The README mentions that 'tons of docs, examples, videos and tutorials have appeared' but the repo lacks a structured, categorized index of these resources. A dedicated RESOURCES.md file would be the core value proposition of this repo - providing the 'unique place' promised in the README. This should include links organized by: Official Apple docs, Video tutorials, Blog posts, Code examples, and Books, with brief descriptions and difficulty levels.

• [ ] Create RESOURCES.md in the root directory with clear categories
• [ ] Add at least 15-20 curated links from Apple's official SwiftUI documentation
• [ ] Include a 'Video Tutorials' section with WWDC sessions and community content
• [ ] Add difficulty/level indicators (Beginner, Intermediate, Advanced) for each resource
• [ ] Link back to RESOURCES.md prominently in README.md

Create CONTRIBUTING.md with guidelines for submitting new SwiftUI resources

As a community-driven resource aggregator, this repo needs clear contribution guidelines so the community can help maintain and expand the resource collection. Currently there's no CONTRIBUTING.md, making it unclear how contributors should suggest new tutorials, examples, or documentation links.

• [ ] Create CONTRIBUTING.md with PR/issue templates for adding resources
• [ ] Define submission criteria (official vs community content, quality standards)
• [ ] Establish a format template for resource entries (title, URL, description, category, date added)
• [ ] Add instructions for maintaining quality and avoiding duplicates
• [ ] Include a maintainer checklist for reviewing resource submissions

Create CHANGELOG.md to track major SwiftUI version updates and repo milestones

SwiftUI evolves with each iOS/macOS release (SwiftUI 1.0, 2.0, 3.0+), and this repo should maintain a changelog documenting which resources correspond to which SwiftUI versions. This helps contributors and users find version-appropriate tutorials and prevents confusion when resources become outdated.

• [ ] Create CHANGELOG.md documenting SwiftUI version history (1.0, 2.0, 3.0, etc.)
• [ ] Add section headers for major Apple releases (iOS 13, 14, 15, etc.)
• [ ] Tag resources in RESOURCES.md with compatible SwiftUI versions
• [ ] Include notable API additions/deprecations for each version
• [ ] Link to official Apple release notes for each version

• Add a new 'SwiftUI State Management' subsection under 'by the community' → 'Repositories' to collect popular state management libraries (MVVM, Redux-style, Combine patterns) with 3–5 curated repo links matching the style of existing sections.
• Create a '⚠️ Migration Guide' section under 'by Apple' documenting official Apple resources specifically for UIKit→SwiftUI migration, filling a gap visible in the current README structure.
• Validate and update all external links in README.md (especially WWDC video links and community course URLs) to ensure no 404 errors; document results in a PR with a link-checker tool output.

This repository appears to be a documentation/information gathering project for SwiftUI with minimal security risks. The codebase contains only markdown documentation, images, and configuration files with no backend logic, databases, or authentication mechanisms. No hardcoded secrets, injection vulnerabilities, or misconfigurations were identified. Primary recommendations focus on improving open-source security best practices (SECURITY.md) and ensuring proper dependency management if any are added in the future. The project's low complexity reduces attack surface significantly.

• Low · Missing repository security configuration — Repository root. The repository lacks standard security files such as SECURITY.md, which would provide guidelines for responsible vulnerability disclosure. This is a best practice for open-source projects. Fix: Add a SECURITY.md file with instructions for reporting security vulnerabilities responsibly.
• Low · No dependency vulnerability scanning — Repository root (Package.swift, Podfile, Cartfile, or similar). The dependency/package file content section is empty, making it impossible to assess if known vulnerable dependencies are in use. However, the presence of this empty section suggests either no formal dependency management or lack of a visible package manifest file. Fix: Ensure a package manager is used with pinned versions, and implement automated dependency scanning tools (e.g., Dependabot, GitHub's dependency scanning).
• Low · Sketch file version control — Assets/banner_about_swift.sketch. The repository includes a .sketch file (binary design file) in version control. While not directly a security risk, binary files in Git can lead to repository bloat and potential issues with merge conflicts. Fix: Consider using Git LFS (Large File Storage) for binary files or exclude them with .gitignore, storing design files in a dedicated design tool instead.

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.