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/ReactiveCocoa/ReactiveSwift 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.

GO — Healthy across all four use cases

• Last commit 10mo ago
• 23+ active contributors
• Distributed ownership (top contributor 25% of recent commits)
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 10mo ago

_{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 ReactiveCocoa/ReactiveSwift repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ReactiveCocoa/ReactiveSwift.

What it runs against: a local clone of ReactiveCocoa/ReactiveSwift — 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 ReactiveCocoa/ReactiveSwift | 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 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 344 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ReactiveCocoa/ReactiveSwift(\\.git)?\\b" \\
  && ok "origin remote is ReactiveCocoa/ReactiveSwift" \\
  || miss "origin remote is not ReactiveCocoa/ReactiveSwift (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"

# 4. Critical files exist
test -f "Sources/Event.swift" \\
  && ok "Sources/Event.swift" \\
  || miss "missing critical file: Sources/Event.swift"
test -f "Sources/Signal.swift" \\
  && ok "Sources/Signal.swift" \\
  || miss "missing critical file: Sources/Signal.swift"
test -f "Sources/SignalProducer.swift" \\
  && ok "Sources/SignalProducer.swift" \\
  || miss "missing critical file: Sources/SignalProducer.swift"
test -f "Sources/Property.swift" \\
  && ok "Sources/Property.swift" \\
  || miss "missing critical file: Sources/Property.swift"
test -f "Sources/Disposable.swift" \\
  && ok "Sources/Disposable.swift" \\
  || miss "missing critical file: Sources/Disposable.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 344 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~314d)"
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/ReactiveCocoa/ReactiveSwift"
  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).

ReactiveSwift is a framework that models asynchronous streams of values over time using composable, declarative primitives—specifically Signal, SignalProducer, and Property types. It enables developers to chain transformations on streams of events (values, errors, completions) without manual callback management, making temporal data flow explicit and testable. Single-module Swift library structure: Sources/ contains the core primitives (Signal, SignalProducer, Property), Tests/ holds comprehensive test coverage, Documentation/ houses API guides and tutorials, and ReactiveSwift-UIExamples.playground/ provides interactive learning examples (e.g., ValidatingProperty example in Pages/). CI workflows in .github/workflows/ run tests on each commit.

iOS/macOS/Swift developers building event-driven applications who need to handle async operations (network requests, user interactions, property changes) and coordinate multiple streams of data without callback hell or race conditions. Particularly useful for those building reactive architectures with properties that need to propagate changes automatically.

Production-ready and actively maintained. The codebase is substantial (~971K lines of Swift), has comprehensive CI via .github/workflows/test.yml and master.yml, ships with detailed documentation in Documentation/ folder (APIContracts.md, BasicOperators.md, ReactivePrimitives.md), and supports multiple platforms (iOS, macOS, tvOS, watchOS, Linux). Swift 5.1+ requirement and multi-package manager support (Carthage, CocoaPods, SwiftPM) indicate strong stability commitment.

Low risk for adoption. The framework has minimal external dependencies (uses Carthage/CocoaPods/SwiftPM which are well-established), and provides companion libraries (ReactiveCocoa/ReactiveCocoa for UIKit bindings, ReactiveCocoa/Loop for data flow). Main risk is learning curve—reactive patterns require paradigm shift from imperative code. No single-maintainer dependency visible; backed by ReactiveCocoa organization with multiple repos.

Active maintenance with CI automation visible in .github/workflows/test.yml and master.yml. The codebase is structured for continuous delivery via release tags. Companion ecosystem continues to evolve (ReactiveCocoa, Loop) and recent additions include Composable Architecture compatibility. CONTRIBUTING.md and PULL_REQUEST_TEMPLATE.md indicate structured contribution process.

Clone the repo with git clone https://github.com/ReactiveCocoa/ReactiveSwift.git && cd ReactiveSwift. Install dependencies via carthage bootstrap --platform iOS (Carthage preferred in Cartfile) or use SwiftPM: swift package resolve. Build with swift build or open in Xcode: open Package.swift (uses Package.swift for SPM).

Daily commands: Development: swift build to compile, swift test to run test suite (runs XCTest). For interactive learning, open ReactiveSwift-UIExamples.playground in Xcode (targets iOS with UIKit examples). CI runs via master.yml (release builds) and test.yml (test builds) on push/PR.

• Sources/Event.swift — Core Event type (value, error, completed) that encapsulates all state changes in reactive streams.
• Sources/Signal.swift — Primary reactive primitive representing push-based streams that emit events over time; foundational to all stream processing.
• Sources/SignalProducer.swift — Lazy, repeatable stream factory that creates signals on demand; essential for resource management and subscription semantics.
• Sources/Property.swift — Mutable reactive property that holds and broadcasts current state; bridges imperative UI patterns with reactive streams.
• Sources/Disposable.swift — Lifecycle and cleanup abstraction for subscriptions; critical for memory management and resource deallocation.
• Sources/Observers/Operators.swift — Central operator composition layer defining map, filter, flatMap, and other stream transformations used across all layers.
• Sources/Action.swift — High-level abstraction for user-triggered async operations that binds inputs, execution, and outputs reactively.

Add a new operator

1. Create a new observer file in Sources/Observers/ (e.g., MyOperator.swift) implementing the transformation logic. (Sources/Observers/MyOperator.swift)
2. Add a public extension method on Signal and SignalProducer delegating to the observer in Sources/Observers/Operators.swift. (Sources/Observers/Operators.swift)
3. Write unit tests validating the operator's behavior on values, errors, and completion events. (Tests/ReactiveSwiftTests/OperatorTests.swift)
4. Document the operator's purpose, parameters, and examples in Documentation/BasicOperators.md. (Documentation/BasicOperators.md)

Extend Foundation types for reactive emission

1. Add a new extension (e.g., for URLSession, Timer, or Notification) in Sources/FoundationExtensions.swift returning a Signal or SignalProducer. (Sources/FoundationExtensions.swift)
2. Ensure proper lifetime management by tying subscriptions to Lifetime if needed (Sources/Lifetime.swift). (Sources/Lifetime.swift)
3. Test the extension against the actual Foundation type and verify disposal semantics. (Tests/ReactiveSwiftTests/FoundationExtensionsTests.swift)

Create a reusable Action

1. Subclass or compose Action (Sources/Action.swift) defining input type, async work closure, and output/error types. (Sources/Action.swift)
2. Bind enabled state to a Property controlling when the action can execute. (Sources/Property.swift)
3. Subscribe to action.values and action.errors in your view/coordinator to handle results and failures. (Sources/Action.swift)
4. Document the action's purpose, preconditions, and lifecycle in the class docstring or API Contracts. (Documentation/APIContracts.md)

Add thread-safe mutable state with reactive updates

1. Create a MutableProperty or @Atomic-wrapped value (Sources/Atomic.swift) holding your state. (Sources/Atomic.swift)
2. Emit changes via a Signal or expose as a Property (Sources/Property.swift) for observation. (Sources/Property.swift)
3. Test concurrent access patterns to verify atomicity (no data races or dropped updates). (Tests/ReactiveSwiftTests/AtomicTests.swift)

• Swift generics & protocols — Enable type-safe, zero-cost abstractions for heterogeneous stream values and error types without runtime overhead.
• Atomic operations (Swift Concurrency primitives) — Provide lock-free thread-safety for mutable state without blocking observers; critical for concurrent emission.
• Closures & higher-order functions — Allow flexible operator composition and custom transformations; central to functional-reactive programming model.
• Lifetime/Disposable pattern — Prevent memory leaks and resource exhaustion by deterministically cleaning up subscriptions tied to object lifetime.

• Push-based (Signal) vs. pull-based (SignalProducer) primitives

  • Why: Push is simpler and synchronous; pull is lazy and repeatable. Both required for different use cases.
  • Consequence: API surface is larger; developers must understand when to use each (Signal for hot streams, SignalProducer for cold/resource-heavy).

• Eager operator application vs. lazy evaluation

  • Why: Operators apply immediately on Signal; deferred on SignalProducer. Balances predictability vs. efficiency.
  • Consequence: SignalProducer operators may have subtle timing differences; developers must be aware of subscription semantics.

• Synchronous error propagation via Event enum

  • Why: Avoids try/catch overhead; all state changes (value, error, completion) flow through one type-safe channel.
  • Consequence: Errors are not thrown; they travel through the stream, requiring explicit handling at subscription or via operators.

• No built-in scheduler/context switching

  • Why: Keeps core lightweight; FoundationExtensions provide ObserveOn for explicit thread hopping.
  • Consequence: Observers run on caller's thread by default; race conditions require careful queue management by user.

• Real-time scheduling or guaranteed latency; targets UI/data binding, not hard real-time systems.
• Automatic backpressure handling; operators do not buffer or apply flowcontrol (manual with collect/deboun

Signal completion is final—once a Signal completes or errors, it will not emit new values even if re-subscribed. SignalProducer re-executes per subscription (creating a new Signal), which is easy to forget. Memory leaks from retain cycles are possible if observers capture self without [weak self]—no automatic cycle breaking. Playground examples require iOS target in Xcode (not macOS playground target). Threading is not automatic—use observe(on:) to marshal onto specific schedulers; default is caller's thread.

• Signal vs SignalProducer — Core abstraction choice in ReactiveSwift—Signal is hot (live), SignalProducer is cold (lazy). Knowing which to use prevents bugs like missed events or unexpected re-execution.
• FlatMap semantics (flatMap vs flatMapLatest) — Incorrect choice between flatMap (preserve all inner streams) and flatMapLatest (cancel previous inner stream on new outer event) causes race conditions or lost events.
• Scheduler-driven threading — ReactiveSwift operations default to caller's thread; explicit observe(on:) scheduling prevents UIThread blocking and ensures thread-safety on mutable state.
• Lifetime management with Disposable — Subscriptions return Disposable tokens; discarding them causes memory leaks and resources never freed. [lifetime: self] syntax in ReactiveSwift ties disposal to object lifecycle.
• Property binding and DynamicProperty — Property enables two-way reactive binding; MutableProperty and DynamicProperty (for KVO) are distinct—mixing them creates subtle update-order bugs.
• Backpressure and buffer semantics — Signal buffers have fixed sizes; overflow strategies (drop oldest, drop newest, error) differ per buffer type. Incorrect choice causes lost events or unexpected errors.

• ReactiveCocoa/ReactiveCocoa — Official companion framework providing UIKit and Cocoa bindings for ReactiveSwift (UIControl, NSObject extensions, etc.)
• ReactiveCocoa/Loop — Unidirectional data flow architecture built on ReactiveSwift—complementary library for state management
• apple/combine — Apple's native reactive framework (iOS 13+); ReactiveSwift predates Combine and provides alternative with different API philosophy
• ReactiveX/RxSwift — Alternative Swift reactive library based on Rx pattern; Documentation/RxComparison.md exists in this repo for cross-reference

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 Swift Package Manager CI workflow

The repo has .github/workflows/test.yml and master.yml but no explicit SPM build/test verification. Given that Package.swift exists and SwiftPM is listed as a supported installation method in the README, a dedicated CI workflow would ensure SPM consumers aren't broken by changes. This is critical for a reactive streams library used as a dependency.

• [ ] Create .github/workflows/spm.yml to test swift build and swift test on multiple Swift versions
• [ ] Test on macOS and Linux runners to ensure cross-platform SPM compatibility
• [ ] Add matrix strategy for Swift 5.5+ versions to catch compatibility regressions early
• [ ] Document SPM testing process in CONTRIBUTING.md if not already present

Add documentation page for advanced operator composition patterns

The Documentation/ folder has BasicOperators.md, FrameworkOverview.md, and RxComparison.md, but lacks a guide on composing complex reactive chains. Given the 'streams of values over time' nature and the RxCheatsheet.md reference, a new file would help intermediate users avoid common pitfalls when combining Signal/SignalProducer operators.

• [ ] Create Documentation/AdvancedOperatorComposition.md with real-world examples
• [ ] Include sections on memory management with captures, backpressure handling, and operator ordering
• [ ] Reference existing playground examples from ReactiveSwift.playground/Pages/
• [ ] Link to this new guide from Documentation/FrameworkOverview.md and README.md

Add Linux/cross-platform compatibility tests to CI

ReactiveSwift targets macOS and iOS (per the xcschemes folder), but Swift is increasingly used on Linux servers. The test.yml workflow should verify Linux compatibility using swift:latest Docker images. This prevents subtle platform-specific bugs that reactive stream users might encounter in server-side Swift projects.

• [ ] Extend .github/workflows/test.yml to include a Linux test job using docker://swift:latest
• [ ] Run swift test target on Linux to catch any Darwin-specific API usage
• [ ] Document any platform-specific limitations in Documentation/APIContracts.md
• [ ] Add a 'Platform Support' section to CONTRIBUTING.md detailing testing requirements

• Add operator documentation examples to Documentation/BasicOperators.md for debounce and throttle operators—currently lack concrete before/after timing diagrams that would help new users understand rate-limiting
• Create a minimal Console/REPL example in ReactiveSwift-UIExamples.playground showing how Signal vs SignalProducer differ when subscribed multiple times—currently only has ValidatingProperty example
• Write integration tests in Tests/ demonstrating proper use of [weak self] in reactive chains to prevent memory leaks—currently no examples in test suite showing anti-patterns to avoid

ReactiveSwift demonstrates good security posture overall. The codebase is a well-maintained reactive programming library with minimal identified vulnerabilities. No hardcoded secrets, injection risks, or critical misconfigurations were detected in the file structure analysis. Primary recommendations focus on dependency management, regular security audits of third-party packages, and CI/CD pipeline hardening. The project follows Swift best practices and maintains clear separation of concerns in its modular structure.

• Low · Carthage Dependency Lock File Management — Cartfile.resolved. The repository contains a Cartfile.resolved file which locks specific versions of dependencies. While this is good practice, without seeing the actual dependency versions and their known CVEs, there's a potential risk if dependencies are outdated. Fix: Regularly update dependencies and audit them for known vulnerabilities using tools like Snyk or OWASP Dependency-Check. Ensure CI/CD pipeline includes dependency vulnerability scanning.
• Low · SwiftLint Configuration Visibility — .swiftlint.yml. The .swiftlint.yml file is committed to the repository. While generally safe, it may reveal code quality expectations that could be leveraged by attackers to understand code patterns. Fix: This is a minor concern. Continue monitoring SwiftLint rules for security-related linting (e.g., rules for detecting hardcoded credentials).
• Low · GitHub Workflow Configuration Exposure — .github/workflows/master.yml, .github/workflows/test.yml. CI/CD workflow files (.github/workflows/*.yml) are committed to the repository. These can potentially reveal build processes, testing strategies, and deployment mechanisms. Fix: Ensure workflow files do not contain secrets or credentials. Use GitHub Secrets for sensitive data. Regularly audit workflow permissions and restrict access to deployment workflows.

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.