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/JakeLin/SwiftLanguageWeather 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

• 21+ active contributors
• MIT licensed
• ⚠ Stale — last commit 3y ago
• ⚠ Concentrated ownership — top contributor handles 59% of recent commits
• ⚠ 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 JakeLin/SwiftLanguageWeather repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/JakeLin/SwiftLanguageWeather.

What it runs against: a local clone of JakeLin/SwiftLanguageWeather — 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 JakeLin/SwiftLanguageWeather | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 1009 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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"

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

Swift Language Weather is an iOS weather app built in Swift 4 that fetches real-time weather data from OpenWeatherMap API and displays it with a custom-designed UI. It demonstrates modern iOS development patterns including MVVM architecture, custom UIViews with @IBDesignable/@IBInspectable, UIStackView layouts, and adaptive Size Classes for device compatibility. Single-app structure: SwiftWeather/ contains core app code organized by domain (Weather.swift, Forecast.swift, LocationService.swift, OpenWeatherMapService.swift) plus UI layer (WeatherViewController.swift, ForecastView.xib) following MVVM with separate *ViewModel.swift files. Observable.swift implements a reactive binding pattern. SwiftWeatherTests/ contains unit tests. Design/ holds Sketch design files referenced in development.

iOS developers learning Swift 4 who want a production-quality reference implementation of a weather app using MVVM, custom UI components, and location services. It's particularly useful for developers interested in design-driven development and reusable UI component patterns.

Actively maintained educational project (last major version V4 supports iOS 10+ with Swift 4). Has CI via BuddyBuild and includes unit tests (SwiftWeatherTests/UnitTests/). However, targeting Xcode 9.1 suggests it may not track cutting-edge Swift/iOS versions. Not a large-scale production app (43KB Swift code), but architecturally sound and intentionally designed as a learning resource.

Single maintainer (JakeLin) with Swift/Xcode version constraints (Xcode 9.1 requirement is outdated). Minimal test coverage (only ForecastDateTimeSpec.swift visible). Dependency on external OpenWeatherMap API means API changes or service downtime break functionality. Legal trademark dispute mentioned in README suggests external pressures. Reasonable risk for learning but verify API keys work before deployment.

Based on file structure, this repo is in maintenance mode focused on Swift 4 compatibility and iOS 10+ support. The README documents historical migrations (V1→V4) but no recent changelog visible in provided data. Suggests active community reference project rather than feature-driven development.

git clone https://github.com/JakeLin/SwiftWeather.git && cd SwiftWeather && pod install && open SwiftWeather.xcworkspace (uses CocoaPods per Podfile presence). Requires Xcode 9.1+ and valid OpenWeatherMap API key.

Daily commands: pod install && open SwiftWeather.xcworkspace, then select SwiftWeather scheme and run on simulator or device. App requires location permission and OpenWeatherMap API key configured (check AppDelegate.swift and OpenWeatherMapService.swift for configuration points).

• SwiftWeather/OpenWeatherMapService.swift: Core API integration layer that fetches weather data; primary point to update if API contract changes
• SwiftWeather/WeatherViewController.swift: Main view controller and entry point to understand UI flow and how ViewModels bind to the view
• SwiftWeather/WeatherViewModel.swift: MVVM presentation logic; demonstrates Observable reactive binding pattern without RxSwift
• SwiftWeather/Observable.swift: Custom reactive property binding implementation; core pattern enabling MVVM in this codebase
• SwiftWeather/LocationService.swift: iOS location permission handling and CLLocationManager wrapper; critical for requesting user location
• SwiftWeather/ForecastView.xib: Custom @IBDesignable forecast cell UI demonstrating reusable component pattern with Interface Builder
• SwiftWeather/TemperatureConverter.swift: Domain logic for Celsius/Fahrenheit conversion; simple but important for localizing temperature display

Feature additions: new API endpoints go in OpenWeatherMapService.swift; new data models inherit from existing Weather.swift/Forecast.swift pattern; UI changes use ForecastView.xib/WeatherViewController.swift as templates. To add tests, mirror existing ForecastDateTimeSpec.swift pattern in SwiftWeatherTests/UnitTests/. Design changes reference Design/SwiftWeather.sketch with @IBDesignable components in SwiftWeather/.

OpenWeatherMap API key must be configured (likely in AppDelegate or hardcoded—check for API key initialization). Location services require Info.plist privacy strings (NSLocationWhenInUseUsageDescription). Xcode 9.1 version requirement may require downloading legacy Xcode if on newer macOS. Podfile dependencies (Alamofire, SwiftyJSON inferred) must match Swift 4 compatibility. Custom Observable.swift binding is synchronous—may cause main thread blocking if used with heavy async operations.

• MVVM (Model-View-ViewModel) — This repo uses MVVM as its primary architecture pattern (WeatherViewModel, ForecastViewModel separate from view controllers); critical to understand why business logic lives in *ViewModel.swift files, not UIViewController
• Reactive Property Binding — Observable.swift implements custom reactive binding without RxSwift; this is a core pattern enabling the MVVM architecture and how ViewModel changes automatically update the UI
• @IBDesignable and @IBInspectable — ForecastView and other components use these annotations to enable visual editing in Interface Builder; demonstrates iOS-specific patterns for reusable UI components with live preview
• Size Classes and Adaptive Layout — App uses Size Classes (mentioned in README) instead of device-specific code to support iPhone and iPad with a single layout; fundamental to modern iOS responsive design
• UIStackView Layout — Used throughout ForecastView.xib and WeatherViewController for declarative, flexible layouts without manual frame calculations; key to maintainable iOS UI code
• CLLocationManager Integration — LocationService.swift wraps CoreLocation for fetching user's GPS coordinates; necessary to understand permission handling and delegate patterns for location-aware apps
• Design-Driven Development — README emphasizes design-driven approach with Sketch design file (Design/SwiftWeather.sketch) as source of truth before coding; demonstrates how UX design and implementation workflow integrates in professional iOS teams

• raywenderlich/swift-weather — Alternative Swift weather app reference implementation; useful for comparing MVVM patterns and API integration approaches
• apple/swift-corelibs-foundation — Foundation framework source; relevant for understanding LocationService and Date/TimeZone handling in ForecastDateTime.swift
• Alamofire/Alamofire — HTTP client dependency (in Podfile); source of truth for networking patterns used in OpenWeatherMapService
• SwiftyJSON/SwiftyJSON — JSON parsing dependency (in Podfile); used for parsing OpenWeatherMap API responses
• JakeLin/Design-Patterns-In-Swift — Same author's companion repo on design patterns; provides theoretical foundation for Observable and MVVM patterns used here

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 unit tests for LocationService.swift and OpenWeatherMapService.swift

The UnitTests folder only contains tests for model classes (Temperature, Weather, Forecast) and builders, but the critical service layer (LocationService.swift and OpenWeatherMapService.swift) lacks test coverage. These services handle location fetching and API calls—core functionality that should have unit tests with mocked dependencies to ensure reliability and prevent regressions.

• [ ] Create SwiftWeatherTests/UnitTests/LocationServiceSpec.swift with tests for location permission handling and CLLocationManager delegation
• [ ] Create SwiftWeatherTests/UnitTests/OpenWeatherMapServiceSpec.swift with tests for API request building, response parsing, and error handling
• [ ] Mock URLSession and CLLocationManager using protocol-based dependency injection to avoid making real network/location requests
• [ ] Add tests for error cases (network failures, invalid API responses, permission denied)

Add UI tests for WeatherViewController weather data display and location updates

The SwiftWeatherUITests folder contains only a single placeholder test file. WeatherViewController.swift is the main user-facing component but lacks UI test coverage for critical user flows like displaying weather data, handling location updates, and refreshing forecasts. This would catch regressions in the presentation layer.

• [ ] Expand SwiftWeatherUITests/SwiftWeatherUITests.swift with tests for initial weather data display
• [ ] Add UI tests for location permission flow and weather update after location change
• [ ] Add tests for ForecastView.xib rendering and forecast data presentation
• [ ] Test error states (network errors, missing location permissions) and user recovery flows

Add GitHub Actions CI workflow for Swift linting and test execution

The repo uses buddybuild for CI but includes .swiftlint.yml configuration without an automated check on pull requests. Adding a GitHub Actions workflow would provide free, integrated CI that runs SwiftLint validation and executes the existing unit/UI tests on every PR, improving code quality and preventing lint violations from merging.

• [ ] Create .github/workflows/swift-lint-and-test.yml with steps for running swiftlint using the repo's .swiftlint.yml config
• [ ] Add swift build and test steps using xcodebuild to run SwiftWeatherTests and SwiftWeatherUITests
• [ ] Configure workflow to trigger on pull requests and pushes to main branches
• [ ] Add status badges to README.md showing workflow status (following pattern of existing BuddyBuild badge)

• Add unit tests for WeatherViewModel.swift and ForecastViewModel.swift (only ForecastDateTimeSpec.swift exists); mock OpenWeatherMapService to test ViewModel binding logic without API calls
• Expand Temperature.swift enum to include Kelvin support; currently only Celsius/Fahrenheit, limiting API data handling
• Create documentation in README for how to set up OpenWeatherMap API key, since current setup instructions omit this critical step

The Swift Language Weather iOS application has moderate security posture. The primary concerns are potential API key exposure in source code and unverified dependency security. The codebase lacks visible evidence of comprehensive input validation and security testing. As a native iOS application, the attack surface is reduced compared to web applications, but proper handling of location data, API credentials, and external data is critical. No infrastructure or Docker-related security issues were identified. Recommendations include implementing proper secrets management, conducting a security audit of dependencies, and adding security-focused unit tests.

• Medium · Missing Dependency Lock File Analysis — Podfile, Podfile.lock. The Podfile.lock file is present but not included in the analysis. CocoaPods dependencies should be audited for known vulnerabilities. The project uses external dependencies (indicated by Podfile) which may contain security vulnerabilities if outdated. Fix: Run 'pod install' to update dependencies, audit pods using 'pod install --repo-update', and regularly check for security advisories. Consider using tools like 'pod install --deployment' in CI/CD pipelines.
• Medium · Potential API Key Exposure Risk — SwiftWeather/OpenWeatherMapService.swift. The OpenWeatherMapService.swift file suggests integration with OpenWeatherMap API. No .env file or secrets management file was found in the repository. API keys for weather services may be hardcoded in the Swift source files. Fix: Store API keys in a secure configuration file (not committed to git), use environment variables, or implement a backend proxy. Add API keys to .gitignore and use build configuration variables.
• Low · Missing Input Validation Evidence — SwiftWeather/LocationService.swift, SwiftWeather/OpenWeatherMapService.swift. The LocationService.swift and OpenWeatherMapService.swift files handle external data and location information. Without reviewing the source code, it's unclear if proper input validation and sanitization are implemented for API responses. Fix: Implement strict input validation for all API responses, use type-safe JSON decoding with Codable, validate coordinate ranges for location data, and implement error handling for malformed responses.
• Low · No Security Headers Configuration Visible — SwiftWeather/OpenWeatherMapService.swift. This is a native iOS application, but if any web-based components or API endpoints are used, there's no visible configuration for security headers (HTTPS enforcement, certificate pinning, etc.). Fix: Implement certificate pinning for API calls, enforce HTTPS only, validate SSL certificates, and consider using URLSessionConfiguration with security policies.
• Low · Third-Party Design Files Included — Design/ directory. Design files (Sketch files) are included in the repository. While not a direct security issue, they may contain sensitive information or metadata. Fix: Consider storing design files in a separate repository or design management system rather than in the main source code repository.
• Low · Insufficient Test Coverage for Security — SwiftWeatherTests/UnitTests/. Unit tests are present but no security-focused tests (e.g., API response validation, location permission checks, data sanitization) are evident from the file names. Fix: Add security-focused unit tests for API response validation, location permission handling, and data encryption/decryption if applicable.

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.