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/soapyigu/Swift-30-Projects 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 3y ago

• 7 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 87% of recent commits
• ⚠ No CI workflows 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 soapyigu/Swift-30-Projects repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/soapyigu/Swift-30-Projects.

What it runs against: a local clone of soapyigu/Swift-30-Projects — 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 soapyigu/Swift-30-Projects | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.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 ≤ 1097 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.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 "Project 01 - GoodAsOldPhones/GoodAsOldPhones/AppDelegate.swift" \\
  && ok "Project 01 - GoodAsOldPhones/GoodAsOldPhones/AppDelegate.swift" \\
  || miss "missing critical file: Project 01 - GoodAsOldPhones/GoodAsOldPhones/AppDelegate.swift"
test -f "Project 01 - GoodAsOldPhones/GoodAsOldPhones/Product.swift" \\
  && ok "Project 01 - GoodAsOldPhones/GoodAsOldPhones/Product.swift" \\
  || miss "missing critical file: Project 01 - GoodAsOldPhones/GoodAsOldPhones/Product.swift"
test -f "Project 01 - GoodAsOldPhones/GoodAsOldPhones/ProductsTableViewController.swift" \\
  && ok "Project 01 - GoodAsOldPhones/GoodAsOldPhones/ProductsTableViewController.swift" \\
  || miss "missing critical file: Project 01 - GoodAsOldPhones/GoodAsOldPhones/ProductsTableViewController.swift"
test -f "Project 02 - Stopwatch/Stopwatch/Stopwatch.swift" \\
  && ok "Project 02 - Stopwatch/Stopwatch/Stopwatch.swift" \\
  || miss "missing critical file: Project 02 - Stopwatch/Stopwatch/Stopwatch.swift"
test -f "Project 02 - Stopwatch/Stopwatch/ViewController.swift" \\
  && ok "Project 02 - Stopwatch/Stopwatch/ViewController.swift" \\
  || miss "missing critical file: Project 02 - Stopwatch/Stopwatch/ViewController.swift"

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

A curated collection of 30 self-contained Swift iOS apps demonstrating UIKit patterns, animations, frameworks (MapKit, Core Data, Core ML), and modern Swift 5 best practices. Each project is a standalone Xcode workspace designed for self-study and architectural learning rather than tutorial-following. Monorepo structure: 30 independent Xcode projects under numbered folders like Project 01 - GoodAsOldPhones/, each containing its own .xcodeproj workspace and source tree. No shared code layer or umbrella framework—each project is copy-paste study material. Assets.xcassets are per-project; AppDelegate.swift, ViewControllers, and domain models live directly in each project's GoodAsOldPhones/ folder.

iOS developers (particularly those 6-18 months into Swift) learning modern UIKit patterns, animation techniques, and framework integration. Developers upskilling on Core Data, local notifications, 3D Touch, and design patterns in production-grade code.

Actively maintained and mature for educational purposes. Written in Swift 5 with iPhone X+ compatibility, follows raywenderlich.com style guide strictly, includes per-project READMEs and screenshots. Contains 406KB of Swift code across 30 projects but notably lacks comprehensive unit tests (README promises XCTest coverage being added). No visible CI/CD setup in file structure.

Single-maintainer (soapyigu) with no CI pipeline visible. Test coverage is incomplete (README acknowledges unit tests 'will be added'). Each project's dependencies are isolated to their .xcodeproj, so no central dependency management or lock file visible—upgrade risk is per-project. Last activity state unknown from metadata, but promise of ongoing maintenance with 'latest syntax' suggests active stewardship.

Repository is in 'maintenance + documentation' phase: README commits promise unit tests and deeper code comments are pending. No active PR or milestone data visible, but the explicit commitment to 'latest syntax' and Swift 5 updates suggests semi-regular touchups as Xcode/iOS versions advance.

1. git clone https://github.com/soapyigu/Swift-30-Projects.git 2. cd 'Project 01 - GoodAsOldPhones/GoodAsOldPhones.xcodeproj' (or any numbered project) 3. Open in Xcode 13+ (requires macOS 11+, Swift 5 toolchain). 4. Select iPhone simulator target and press Cmd+R to build and run. No CocoaPods, SPM, or external package manager setup required per file structure.

Daily commands: Per-project basis (no global entry point). Navigate to any Project NN - AppName/ folder, open AppName.xcodeproj in Xcode. Select a simulator or device target (iPhone 12+ recommended for UI fit), then Cmd+R. Each project self-contained; no build scripts or Makefile.

• Project 01 - GoodAsOldPhones/GoodAsOldPhones/AppDelegate.swift — Application entry point and lifecycle management for the first sample project; all contributors should understand iOS app initialization patterns.
• Project 01 - GoodAsOldPhones/GoodAsOldPhones/Product.swift — Core data model demonstrating Swift struct design; establishes the pattern used across projects for data representation.
• Project 01 - GoodAsOldPhones/GoodAsOldPhones/ProductsTableViewController.swift — UITableViewController implementation showing the primary UI pattern used throughout the repo; demonstrates data source and delegate patterns.
• Project 02 - Stopwatch/Stopwatch/Stopwatch.swift — Core business logic for timer functionality; exemplifies separation of logic from UI controllers used across projects.
• Project 02 - Stopwatch/Stopwatch/ViewController.swift — UI controller demonstrating timer state management and UI updates; shows the view-controller-as-coordinator pattern.
• Project 03 - FacebookMe/FacebookMe/AppDelegate.swift — Secondary entry point demonstrating app delegation patterns across multiple projects with varying frameworks.

Add a New Product in GoodAsOldPhones

1. Define the new product data in Product.swift as a static property or array extension (Project 01 - GoodAsOldPhones/GoodAsOldPhones/Product.swift)
2. Update ProductsTableViewController.swift to reload data if products array is dynamic, or ensure it reads from the updated Product data source (Project 01 - GoodAsOldPhones/GoodAsOldPhones/ProductsTableViewController.swift)
3. Add corresponding product image assets in Assets.xcassets with @2x variants (Project 01 - GoodAsOldPhones/GoodAsOldPhones/Assets.xcassets/image-cell1.imageset/Contents.json)
4. Update Main.storyboard if the detail layout needs adjustment, or ensure ProductViewController.swift handles the new product fields (Project 01 - GoodAsOldPhones/GoodAsOldPhones/ProductViewController.swift)

Add a New Stopwatch Feature or Test Case

1. Extend the Stopwatch.swift model with new computed properties or methods following the immutability pattern (Project 02 - Stopwatch/Stopwatch/Stopwatch.swift)
2. Write corresponding unit tests in StopwatchTests.swift to validate the new logic independently (Project 02 - Stopwatch/StopwatchTests/StopwatchTests.swift)
3. Update ViewController.swift to call the new Stopwatch methods and bind their results to UI elements (Project 02 - Stopwatch/Stopwatch/ViewController.swift)
4. Adjust Main.storyboard or auto-layout constraints if UI changes are needed (Project 02 - Stopwatch/Stopwatch/Base.lproj/Main.storyboard)

Create a New Sample Project (Project N+1)

1. Create a new directory following the pattern 'Project NN - ProjectName' at repository root (Project 01 - GoodAsOldPhones)
2. Initialize AppDelegate.swift following the same structure as existing projects (AppDelegate.swift template) (Project 01 - GoodAsOldPhones/GoodAsOldPhones/AppDelegate.swift)
3. Create core data models (Product.swift pattern) or business logic classes as needed (Project 01 - GoodAsOldPhones/GoodAsOldPhones/Product.swift)
4. Build view controllers extending UIViewController or UITableViewController following naming conventions (ProductsTableViewController pattern) (Project 01 - GoodAsOldPhones/GoodAsOldPhones/ProductsTableViewController.swift)
5. Create Main.storyboard with scenes and segues using Interface Builder (Project 01 - GoodAsOldPhones/GoodAsOldPhones/Base.lproj/Main.storyboard)
6. Add test target with Info.plist and write XCTest cases (see StopwatchTests pattern) (Project 02 - Stopwatch/StopwatchTests/StopwatchTests.swift)
7. Include a README.md in the project directory explaining features and architecture (Project 01 - GoodAsOldPhones/README.md)

• Swift 5 with UIKit — Native iOS development with modern syntax; UIKit provides battle-tested components (UITableViewController, UICollectionView) for rapid prototyping
• Storyboard & XIB (Interface Builder) — Visual layout definition enables quick iteration and WYSIWYG design; reduces boilerplate constraint code
• XCTest Framework — Built-in testing; demonstrates Test-Driven Development patterns and business logic isolation from UI
• Core Data, MapKit, Core ML (per project) — Each project showcases a different iOS framework; exposes learners to modern Apple frameworks with real examples

• Storyboards for navigation rather than programmatic UINavigationController setup

  • Why: Faster visual feedback and learning for beginners; easier to understand flow at a glance
  • Consequence: Harder to merge in version control; less flexible for dynamic navigation; Storyboard merge conflicts on team projects

• ViewControllers as coordinators (handling data passing, segues)

  • Why: Simpler for 30 small projects; follows Apple's documentation patterns
  • Consequence: ViewControllers become fat/god objects; harder to test in isolation; violates Single Responsibility

• Static data models (e.g., Product properties) vs. Core Data persistence

  • Why: Project 1 uses in-memory data for simplicity; not all projects need persistence
  • Consequence: Data lost on app exit; no offline capability; doesn't demonstrate real-world data

1. Xcode version lock: Projects built for iPhone X+ UI (Safe Area, notch handling); older Xcode (< 13) may misrender layouts. 2. Swift 5 syntax assumed: Older Swift 4 code will not compile; no backward-compat mode. 3. No Podfile/Package.resolved in list: If a project uses CocoaPods, the workspace file must exist but wasn't shown—cloning and opening .xcodeproj might fail; check for Podfile at project root and run pod install first. 4. Single app per project: Unlike many learning repos, no shared code base means 30× boilerplate duplication (AppDelegate, Info.plist patterns repeat)—intentional by design for isolation. 5. Assets path assumptions: Image references like UIImage(named: 'phone-fullscreen1') are fragile; asset name must match exactly in xcassets.

• UITableView Delegation & DataSource — Foundation of iOS list UIs. Project 01 (GoodAsOldPhones) and others lean heavily on UITableViewDataSource/Delegate patterns; mastering these is prerequisite for modern UIKit development.
• Core Data NSFetchRequest & Predicates — Local persistence layer used in several projects. NSPredicate-based filtering and NSFetchedResultsController are non-obvious; critical for app state durability.
• CABasicAnimation & CAKeyframeAnimation — Low-level animation framework underlying smooth UIView transitions. Projects in this repo likely use CATransaction and implicit animations; understanding Core Animation is distinct from UIView.animate().
• Local Notifications (UserNotifications framework) — iOS 11+ notification scheduling (mentioned in README). UNUserNotificationCenter replaces older UILocalNotification; async permission handling is error-prone.
• Safe Area & Layout Guides — iPhone X+ notch handling. Projects explicitly target iPhone X compatibility; misunderstanding safeAreaLayoutGuide leads to notch overlap bugs.
• Core ML Model Integration — Machine learning inference on-device (mentioned in README). CoreML models (.mlmodel) are compiled into the app bundle; using MLModel and MLFeatureProvider is distinct from typical Swift code.
• 3D Touch & Peek/Pop — Pressure-sensitive interactions (mentioned in README). UIViewControllerPreviewingDelegate and force-touch gesture handling are deprecated on modern iPhones but exemplify UIKit capability depth.

• raywenderlich/swift-style-guide — Official style guide this repo strictly adheres to; essential reference for understanding code conventions and design decisions in Swift-30-Projects.
• vsouza/awesome-ios — Curated list of iOS libraries and projects; helps contextualize which frameworks (MapKit, Core ML, Core Data) in Swift-30-Projects are industry-standard vs. niche.
• realm/realm-swift — Modern alternative to Core Data for persistence; many Swift-30-Projects use Core Data; Realm is a companion learning target for database design patterns.
• Alamofire/Alamofire — Canonical HTTP networking library absent from Swift-30-Projects file list but likely needed for projects involving APIs; bridges gap in learning progression.
• airbnb/lottie-ios — Animation library used in some advanced iOS projects; learning complement if Swift-30-Projects animation projects inspire further exploration of complex motion design.

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 comprehensive README files for remaining projects (03-30)

The repo shows Project 01 and 02 have individual README.md files with screenshots and learning objectives, but the file structure indicates 30 projects total. Most projects are missing dedicated README files. This is critical for a self-study repo where learners need to understand what each project teaches and how to run it.

• [ ] Audit all Project directories (03-30) for missing README.md files
• [ ] For each missing README, document: project objective, key Swift/iOS concepts covered, prerequisites, and build instructions
• [ ] Follow the same format/structure as existing Project 01 README.md and Project 02 README.md
• [ ] Include screenshot/GIF references (check if .gif files exist in each project folder like Project01/GoodAsOldPhones.gif and Project02/Stopwatch.gif)
• [ ] Reference the specific frameworks used (MapKit, Core Data, CAAnimations, etc.) mentioned in main README

Create GitHub Actions workflow for Xcode builds across multiple Swift projects

With 30 Xcode projects in one repo, there's no CI/CD mentioned. Adding a GitHub Actions workflow to verify that all projects build successfully (especially for different Swift versions and Xcode versions) would catch regressions when contributors update code. This is essential for a learning repo that needs to stay maintainable.

• [ ] Create .github/workflows/xcode-build.yml that iterates through each Project directory
• [ ] Configure matrix strategy to test against latest 2-3 Xcode/Swift versions
• [ ] Add build steps: xcodebuild -scheme <ProjectName> -configuration Debug for each project's .xcodeproj
• [ ] Add optional linting step using swiftlint (if swift style guide enforcement is desired)
• [ ] Document in contributing guide how to test locally before pushing

Add unit tests for Project 01 (GoodAsOldPhones) data models and view controllers

Project 01 has concrete business logic (Product.swift, ProductsTableViewController.swift) but no visible test files in the xcodeproj structure. Adding XCTest test cases for the Product model and table view logic would demonstrate TDD best practices mentioned in the README and serve as a template for other projects.

• [ ] Create Project01-GoodAsOldPhones/GoodAsOldPhones/GoodAsOldPhonesTests.xctest target (if missing)
• [ ] Add unit tests for Product.swift: initialization, property validation
• [ ] Add view controller tests for ProductsTableViewController: data source methods, cell configuration
• [ ] Add tests for ContactViewController basic initialization (if applicable)
• [ ] Ensure tests follow raywenderlich.com Swift testing conventions mentioned in repo philosophy
• [ ] Document test coverage in Project 01 README.md

• Add XCTest suite to Project 01 (GoodAsOldPhones): Create GoodAsOldPhonesTests/ target, write 3–5 unit tests for a simple model or ViewController (e.g., test phone list filtering, price calculation). This fulfills the README's stated goal of adding unit tests and provides a template for other 29 projects.
• Document each project's learning goals in a per-folder README: Currently only top-level README exists. Add Project 01 - GoodAsOldPhones/README.md describing UITableView fundamentals, custom cells, and delegation patterns used; repeat for 5–10 high-value projects.
• Add code comments to high-complexity animation projects: Review any project using CABasicAnimation or UIView.animate; add 2–3 sentence comments above non-obvious frame/opacity/duration calculations. Improves readability for self-study learners.

This is an educational Swift projects repository with generally good security posture for a learning resource. The primary concerns are related to Xcode project configuration files (xcuserdata, user state files) being committed to version control, which is a common mistake but relatively low-risk for a public educational repo. No hardcoded secrets, credentials, or injection vulnerabilities were detected in the visible file structure. The codebase follows standard iOS best practices with no Docker/infrastructure components to evaluate. Recommendations focus on proper .gitignore configuration for Xcode projects.

• Medium · User Data Stored in Xcode User State Files — Project 01 - GoodAsOldPhones/GoodAsOldPhones.xcodeproj/project.xcworkspace/xcuserdata/Yi.xcuserdatad/UserInterfaceState.xcuserstate and similar files. The repository contains xcuserdata directories with UserInterfaceState.xcuserstate files. These are checked into version control and may contain sensitive information about the developer's environment, local paths, or user-specific data that should not be shared. Fix: Add xcuserdata/ and .xcuserstate to .gitignore to prevent checking in user-specific Xcode data. The .gitignore file should include: '.xcuserstate' and 'xcuserdata/'
• Medium · Xcode Build Metadata in Version Control — Project 01 - GoodAsOldPhones/GoodAsOldPhones.xcodeproj/xcuserdata/Yi.xcuserdatad/xcschemes/. The repository contains xcschememanagement.plist and other Xcode scheme files that are user-specific and should not be committed. These files can expose local development configuration. Fix: Ensure .gitignore excludes the entire xcuserdata directory: '.xcworkspace/xcuserdata/' and '.xcodeproj/xcuserdata/'
• Low · Incomplete README File — README snippet in root directory. The main README.md appears to be incomplete (text cuts off at 'I will maintain the project with latest syntax and most ad'). This may indicate incomplete documentation which could hide important security guidance or disclaimers. Fix: Complete the README file with full documentation including security considerations and version compatibility information

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.