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/MengTo/Spring 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

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

What it runs against: a local clone of MengTo/Spring — 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 MengTo/Spring | 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 ≤ 1072 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "MengTo/Spring(\\.git)?\\b" \\
  && ok "origin remote is MengTo/Spring" \\
  || miss "origin remote is not MengTo/Spring (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 1072 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1042d)"
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/MengTo/Spring"
  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).

Spring is a Swift library that simplifies iOS animations by providing declarative CABasicAnimation wrappers with a rich set of preset animations (shake, pop, bounce, flip, slide, fade, zoom) that can be applied to UIView subclasses via code or Interface Builder attributes. It abstracts away Core Animation boilerplate, letting developers animate with one line like layer.animation = "squeezeDown"; layer.animate() instead of configuring CABasicAnimation parameters manually. Single-package structure: Spring/ directory contains the core library split by UI component type (SpringView, SpringButton, SpringImageView, SpringLabel, SpringTextField, etc.), with SpringAnimation.swift as the animation engine and Designable* classes enabling Interface Builder integration. SpringApp/ is a separate demo/test application using Storyboards and a CodeViewController.

iOS developers building UIs in Swift who want to add polished animations (transitions, micro-interactions, entrance effects) without deep Core Animation knowledge. Specifically useful for designers and junior developers who prefer declarative, preset-driven animation over frame-by-frame CABasicAnimation configuration.

Moderately mature but showing age: the codebase is 120K+ lines of Swift (updated to Swift 4.2 per .swift-version), installable via CocoaPods, and ships with a working demo app (SpringApp/). However, the README indicates a 'known issue' with animations not autostaring via performSegueWithIdentifier, and the lack of visible test files (none in file list) and no CI config snippet suggest limited test coverage and no automated testing setup.

Moderate risk: single-maintainer project (MengTo), no visible test suite or CI pipeline, and the known segue issue suggests unresolved compatibility problems. Swift 4.2 is old (from 2018), so compatibility with modern Swift versions (5.x+) and iOS 15+ is uncertain. No open issue count visible, but the dated Swift target and lack of maintenance signals are concerning for new projects.

No recent activity visible from the file list. The README references a ChangeLog wiki page, but no git metadata, recent commits, or active PRs are shown. The project appears dormant or in maintenance mode.

git clone https://github.com/MengTo/Spring.git
cd Spring
# Option 1: Copy Spring/ folder into your Xcode project (manual)
# Option 2: Via CocoaPods - add to Podfile: pod 'Spring', :git => 'https://github.com/MengTo/Spring.git' && pod install
# Option 3: Open SpringApp.xcodeproj in Xcode 10+ and build to see the demo

Daily commands: Open SpringApp.xcodeproj in Xcode 10+, select SpringApp scheme, and press Run (⌘R) to launch the demo app showing all preset animations. For library use: integrate Spring/ folder or install via CocoaPods, then apply animations in code (layer.animation = "fall"; layer.animate()) or via Storyboard Identity/Attribute Inspectors.

• Spring/SpringAnimation.swift: Core animation engine defining all preset animations (shake, pop, bounce, etc.) and the CABasicAnimation configuration logic
• Spring/SpringView.swift: Base UIView subclass that all animated components inherit from, contains animate(), animateTo(), animateNext() methods
• Spring/DesignableView.swift: Enables @IBDesignable/@IBInspectable Interface Builder integration, allowing animations to be set in Xcode without code
• Spring/SpringButton.swift: UIButton subclass showing how to apply Spring animations to interactive controls
• SpringApp/CodeViewController.swift: Demo code showing all preset animations and how to use the API programmatically

For new animations: edit Spring/SpringAnimation.swift to add preset definitions. For new UI components: create a new Designable* or Spring* subclass in Spring/ (follow pattern of SpringView.swift, SpringButton.swift). For demo changes: modify SpringApp/CodeViewController.swift or update SpringApp/Base.lproj/Main.storyboard. Interface Builder integration lives in Spring/DesignableView.swift.

1. Autostart animations fail when views are pushed via performSegueWithIdentifier (documented known issue in README). 2) Not all animation properties work together (force, damping, velocity interact in complex ways per CABasicAnimation docs). 3) Interface Builder requires Xcode 10+ and Swift 4.2 compiler; older projects may have compatibility issues. 4) No test coverage visible; you are responsible for validating animations work in your target iOS versions. 5) CocoaPods integration requires :git reference rather than version pin, so lockfile behavior may be unpredictable.

• CABasicAnimation — Core Foundation framework that Spring wraps; understanding keyPath bindings, timing functions, and animation groups is essential to extend or debug Spring animations.
• IBDesignable and IBInspectable — iOS Interface Builder attributes that Spring uses to let designers set animation properties in Xcode without writing code; critical for understanding how DesignableView.swift works.
• Damping and Spring Physics — Spring animations use CASpringAnimation with damping/velocity parameters to create bouncy, natural-feeling motion; misunderstanding these causes animations to feel stiff or overdamped.
• Key-Value Coding (KVC) — Spring uses KVC to bind animation properties (x, y, rotate, scale) to CABasicAnimation keyPaths; errors here cause silent animation failures.
• UIView Timing and RunLoop — Spring animations are synced to the screen's refresh cycle via Core Animation's runloop integration; understanding CADisplayLink and -[CATransaction flush] helps debug timing issues.
• Easing Functions (Cubic Bezier) — Spring's curve property (spring, linear, easeIn, easeOut, easeInOut) maps to CAMediaTimingFunction with different control points; tweaking these dramatically changes feel.

• Kitura/Kitura — Not actually related—ignore this placeholder; instead see below real alternatives.
• realm/SwiftLint — Code quality tool; Spring would benefit from SwiftLint rules to maintain consistency across Designable* classes.
• airbnb/lottie-ios — Direct alternative: Lottie animates from JSON exports; Spring animates programmatically. Lottie is more powerful for complex animations, Spring simpler for common presets.
• CocoaPods/CocoaPods — Spring's dependency manager; understanding CocoaPods is required for installation and local development setup.
• jdg/MBProgressHUD — Overlapping use case for LoadingView.swift; MBProgressHUD is more mature and widely adopted for progress indicators, while Spring's LoadingView is a basic alternative.

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 SpringAnimation.swift core animation logic

The SpringAppTests folder only contains SpringAppTests.swift with no visible test coverage for the core animation engine. SpringAnimation.swift is the heart of the library but lacks unit tests for animation properties (timing, damping, velocity), animation state management, and the animate()/animateTo() methods. This would catch regressions and give contributors confidence when modifying animation behavior.

• [ ] Create SpringAppTests/SpringAnimationTests.swift with test cases for SpringAnimation initialization with different animation presets (shake, pop, morph, etc.)
• [ ] Add tests for animation property setters (duration, delay, damping, velocity) to verify they correctly configure CABasicAnimation
• [ ] Add tests for the animate() and animateTo() methods to ensure they properly trigger and chain animations
• [ ] Add tests for edge cases like invalid animation names or negative timing values

Add GitHub Actions CI workflow for Swift building and testing

The repo has no visible CI configuration (.github/workflows/ missing). Given that Spring targets iOS with Swift 4.2, automated testing on every PR would prevent regressions. The README mentions 'Requires Xcode 10 and Swift 4.2' but there's no automated verification that PRs maintain this compatibility.

• [ ] Create .github/workflows/swift-build.yml to run on every PR and push to main branch
• [ ] Configure the workflow to build Spring.xcscheme and SpringApp.xcscheme targets using xcodebuild on macOS-latest
• [ ] Add step to run SpringAppTests to execute the test suite and report results
• [ ] Add step to verify swift version compatibility (Swift 4.2 minimum) in the workflow output

Refactor monolithic Spring.swift into feature-specific modules

Spring.swift appears to be a single catch-all file for the framework. Based on the file structure showing separate Designable* and Spring* variants (SpringButton, SpringLabel, SpringView, etc.), the core Spring.swift likely contains shared animation logic duplicated across these UI component files. Breaking this into focused modules (SpringAnimationEngine.swift, SpringProperties.swift, etc.) would reduce maintenance burden and improve code reusability.

• [ ] Analyze Spring.swift to identify core animation engine logic separate from UI-specific code
• [ ] Extract animation property definitions (damping, velocity, delay, timing curves) into SpringAnimationProperties.swift
• [ ] Extract shared animation execution logic into SpringAnimationEngine.swift used by all Designable* and Spring* components
• [ ] Update imports in SpringView.swift, SpringButton.swift, SpringLabel.swift, etc. to use the new modular files instead of monolithic Spring.swift
• [ ] Verify all animations still work correctly by running SpringAppTests

• Add unit tests to Spring/SpringAnimation.swift covering all 20+ preset animations (shake, pop, squeeze variants) to validate CABasicAnimation parameter correctness and duration calculations—currently zero test coverage visible.
• Document and fix the known segue issue: create a test case in SpringApp showing the performSegueWithIdentifier autostart failure, then patch SpringView.swift to detect when animation should be delayed until viewDidAppear.
• Create a Swift 5.x compatibility pass: update .swift-version to 5.x, add nullable/non-optional parameter markers where needed, and test with Xcode 12+. Add a CI workflow (.github/workflows/swift.yml) to validate Swift 5.x/iOS 15+ compatibility.

The Spring animation library is a UI-focused framework with moderate security posture. Primary concerns are around external content loading (images), audio file handling, and input validation in text components. The library lacks visible authentication mechanisms, which is appropriate for its purpose. No critical vulnerabilities were identified, but several medium and low-risk issues should be addressed, particularly around input validation and external resource loading. The codebase does not expose secrets or credentials, and no SQL injection or XSS risks are apparent given the iOS/Swift context. Recommended improvements focus on defensive programming practices for user input and external content handling.

• Medium · Potential Insecure Image Loading — Spring/ImageLoader.swift. The ImageLoader.swift component loads images from external sources. Without visible validation of URLs or certificate pinning, there's a risk of man-in-the-middle attacks or loading malicious content if URLs are not properly validated. Fix: Implement URL validation, use HTTPS only for image URLs, consider implementing certificate pinning for critical image sources, and validate image content before displaying.
• Medium · Potential Unsafe Audio File Handling — Spring/SoundPlayer.swift. The SoundPlayer.swift component plays audio files. Without visible input validation or sandbox restrictions, there's a potential risk of loading malicious audio files or executing arbitrary audio content. Fix: Validate audio file paths and sources, restrict file access to app bundle or sandboxed directories, implement proper error handling for corrupted files.
• Low · Dynamic UI Property Assignment — Spring/Designable*.swift files. Multiple Designable* files (DesignableButton, DesignableView, etc.) use IBInspectable properties that accept string-based animation names. If animation names come from untrusted sources, this could lead to unexpected behavior or crashes. Fix: Validate and whitelist animation names, avoid accepting animation parameters from untrusted sources, implement safe defaults for invalid inputs.
• Low · Missing Input Validation in Text Components — Spring/AutoTextView.swift, Spring/DesignableTextField.swift, Spring/DesignableTextView.swift. CustomTextField and TextViews (AutoTextView.swift, DesignableTextField.swift) may lack input validation, potentially allowing injection of unexpected content if used with untrusted data. Fix: Implement input validation and sanitization, set appropriate keyboard types and content restrictions, validate content before processing.
• Low · Potential Memory Management Issues with AsyncButton — Spring/AsyncButton.swift. AsyncButton.swift performs asynchronous operations. Without visible strong reference cycle prevention, there could be memory leaks or unintended object retention. Fix: Use weak self in closure captures, implement proper cleanup in dealloc/deinit, consider using autoreleasepool for long-running operations.

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.