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/WenchaoD/FSPagerView 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 1y ago

• 10 active contributors
• MIT licensed
• ⚠ Stale — last commit 1y ago
• ⚠ Single-maintainer risk — top contributor 89% 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 WenchaoD/FSPagerView repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/WenchaoD/FSPagerView.

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

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

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

FSPagerView is a UICollectionView-based screen pagination library for iOS/tvOS that enables infinite, automatically-scrolling carousel views with rich 3D transformers and fully customizable page controls. It solves the problem of building polished banner sliders, product showcases, and onboarding flows without managing complex scroll view logic or state synchronization. Dual-structure monorepo: FSPagerView/ contains the core library code (Objective-C & Swift implementations sharing UICollectionView base), while FSPageViewExample-Swift/ and FSPagerViewExample-Objc/ are separate example projects demonstrating banner, transformer, and page-control patterns. The library is packaged as a CocoaPod and SPM package (.swiftpm/xcode/).

iOS app developers (Swift & Objective-C) who need production-ready carousel components for marketing banners, product galleries, and guided onboarding experiences without building UICollectionView pagination from scratch.

This is a mature, production-ready library. It supports Swift 5.0+ and Objective-C, has CocoaPods/Carthage/SPM package manager support, includes two full example projects (Swift and Objc), and shows active maintenance with cross-platform compatibility (iOS & tvOS). The extensive feature set (infinite scrolling, auto-sliding, 3D transformers, customizable page controls) and polished API suggest solid real-world usage.

Single-maintainer repo (WenchaoD) with no visible CI/CD pipeline, test suite, or GitHub Actions in the file structure—maintenance risk if the creator becomes unavailable. No obvious breaking-change log or semantic versioning strategy visible. Dependency on UICollectionView internals means iOS API changes could require updates, though the core architecture is stable.

Based on file structure, active development includes both Swift and Objective-C implementations with example coverage of basic banners, transformer animations, and page controls. The presence of .swiftpm/ suggests recent SPM support was added. No recent commit log visible in provided data, so active maintenance status is unclear.

Clone the repo and open either example project:

git clone https://github.com/WenchaoD/FSPagerView.git
cd FSPagerView/FSPageViewExample-Swift
open FSPagerViewExample.xcodeproj

Or install via CocoaPods: pod 'FSPagerView'

Daily commands: For Swift example:

cd FSPageViewExample-Swift
open FSPagerViewExample.xcodeproj
# Build & run in Xcode (⌘R)

For Objective-C example:

cd FSPagerViewExample-Objc
open FSPagerViewExample-Objc.xcodeproj
# Build & run in Xcode (⌘R)

• FSPagerView/FSPagerView/FSPagerView.h: Objective-C header exposing the primary public API; essential for understanding protocol contracts and configuration properties
• FSPageViewExample-Swift/FSPagerViewExample/BasicExampleViewController.swift: Reference implementation for basic infinite banner scrolling with auto-slide timer—best starting point for understanding real usage
• FSPageViewExample-Swift/FSPagerViewExample/TransformerExampleViewController.swift: Demonstrates the 3D transformer system and CATransform3D effects; critical for advanced customization
• FSPageViewExample-Swift/FSPagerViewExample/PageControlExampleViewController.swift: Shows how to integrate and customize the page control indicator UI alongside the pager view
• FSPagerView.podspec: Defines the library's CocoaPods distribution, version, dependencies, and supported platforms (iOS 8.0+, tvOS 9.0+)

For new carousel features: Edit FSPagerView/FSPagerView/ (core UICollectionView logic). For transformers: Look in example ViewControllers' TransformerExampleViewController.swift/h for 3D effect patterns. For page controls: Study PageControlExampleViewController.swift/h to see customization hooks. To add features: Start by duplicating a transformer or example VC, then modify the core library's delegate/datasource methods.

No visible test suite in the file list—QA relies on manual testing via example projects. UICollectionView internals dependency: Relying heavily on UICollectionView's scrolling and layout APIs means iOS version updates could break edge cases (e.g., scroll deceleration logic). Infinite scrolling math: Duplicating cells via modulo requires careful datasource logic; off-by-one errors can break pagination. Page control state sync: Manually syncing FSPageControl indicator position with scroll offset is error-prone if automatic scroll logic changes. No explicit Objective-C nullability annotations visible—could cause Swift interop warnings.

• Infinite Scrolling via Modulo Arithmetic — FSPagerView's core trick for seamless looping—understanding modulo wrapping of cell indices is essential to avoid off-by-one bugs and to customize pagination behavior
• UICollectionView Cell Reuse & IndexPath Mapping — FSPagerView delegates cell configuration to datasource—misunderstanding reuse pools or IndexPath math causes visual glitches and memory leaks in large carousels
• CATransform3D & 3D Affine Transforms — The transformer system applies perspective and rotation matrices to cells during scroll—reading the perspective matrices in TransformerExampleViewController requires understanding 3D graphics transforms
• UIScrollView Deceleration Distance & Paging Boundaries — FSPagerView's decelerationDistance property controls multi-cell momentum scrolling—understanding scroll deceleration curves is key to tuning swipe-to-next behavior
• Timer-based Auto-Scroll with Invalidation Patterns — The automaticSlidingInterval feature uses NSTimer scheduling—understanding timer lifecycle and deallocation prevents memory leaks in carousel implementations
• Swift-Objective-C Interoperability (Bridging Headers) — FSPagerView maintains both Swift and Objc implementations in a single package—the .h header and bridging patterns are critical when integrating into mixed-language codebases

• nicklockwood/iCarousel — Predecessor carousel library for iOS; inspired many pagination patterns but FSPagerView modernizes the approach using UICollectionView instead of custom scroll logic
• Alamofire/Alamofire — Not directly related but commonly paired with FSPagerView in real apps for async image loading in banner cells
• onevcat/Kingfisher — Image caching library frequently used in FSPagerView examples to load remote banner images efficiently
• esnoeohc/CHIPageControl — Alternative page control library; often compared with FSPagerView's built-in customizable page control for design flexibility
• lkzhao/Hero — Shared element transition library often paired with FSPagerView for animated page-to-detail-screen transitions in product showcases

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 FSPagerView core functionality

The repo has UI test files (FSPagerViewExampleUITests.swift, FSPagerViewExample_ObjcUITests.swift) but lacks unit tests for the core FSPagerView library itself. Testing scroll behavior, data source methods, transformer calculations, and page control synchronization would improve reliability and prevent regressions.

• [ ] Create FSPagerView/FSPagerViewTests/ directory with XCTestCase subclasses
• [ ] Add tests for FSPagerView scroll delegate methods (e.g., scrollViewDidScroll, scrollViewWillEndDragging)
• [ ] Add tests for FSPagerViewDataSource methods (cellForItemAt, numberOfItems)
• [ ] Add tests for FSPagerViewTransformer calculations and visual transformations
• [ ] Add tests for FSPageControl synchronization with FSPagerView page changes
• [ ] Integrate test target into FSPagerView.xcodeproj and set up scheme

Add GitHub Actions CI workflow for Swift Package Manager validation

The repo supports SPM (Package.swift exists) but has no CI pipeline to validate Swift builds across iOS versions. This prevents catching breaking changes early and ensures SPM users have confidence in the package.

• [ ] Create .github/workflows/spm-build.yml GitHub Action workflow
• [ ] Configure matrix to test against multiple Swift versions (5.0+) and iOS deployment targets
• [ ] Add build step: swift build for the FSPagerView SPM package
• [ ] Add test step: swift test if unit tests are added (see PR #1)
• [ ] Document in README.md that CI passing ensures SPM compatibility

Create comprehensive API documentation for FSPagerViewTransformer subclasses

TransformerExampleViewController.swift exists in both examples but there's no dedicated documentation explaining how to create custom transformers or the built-in transformer options. Users need clear examples of transformer usage, timing, and customization.

• [ ] Create TRANSFORMERS.md documenting all built-in FSPagerViewTransformer subclasses
• [ ] Add code examples for each transformer type (ScaleTransformer, RotationTransformer, etc.)
• [ ] Document the FSPagerViewTransformer protocol and required methods (transform(attr:) signature)
• [ ] Add a 'Creating Custom Transformers' section with a step-by-step example
• [ ] Link TRANSFORMERS.md from main README.md and update the TransformerExampleViewController comments to reference it

• Add unit tests for infinite scrolling math (modulo wrapping, edge cases at start/end)—test file would live in a new FSPagerViewTests/ directory with XCTest covering the core pagination logic used by both example projects
• Document the transformer API with code snippets showing how to chain CATransform3D effects—add a new Transformers.md guide explaining the pattern used in TransformerExampleViewController.swift
• Add tvOS-specific example (gesture handling, focus engine integration)—create a new TransformerExampleViewController variant in the Swift example that uses UIKit focus-based navigation instead of gesture recognizers

FSPagerView is a UI library with relatively low security risk. The codebase shows no obvious injection vulnerabilities, hardcoded secrets, or dangerous API usage patterns based on the file structure analysis. Primary concerns are minor: incomplete version control exclusions (xcuserdata files) and inability to assess dependencies without examining Package.swift content. The project follows standard iOS library practices. Recommendations focus on hygiene rather than critical security issues.

• Low · User data stored in Xcode user data directory — FSPagerViewExample-Objc/FSPagerViewExample-Objc.xcodeproj/xcuserdata/. The repository contains xcuserdata files (FSPagerViewExample-Objc/.xcodeproj/xcuserdata/) which may contain local user-specific build settings, breakpoints, and other metadata. While typically not sensitive, these should be excluded from version control. Fix: Add xcuserdata/ to .gitignore to prevent committing user-specific Xcode data
• Low · Missing dependency vulnerability information — Package.swift. The Package.swift file content was not provided in the analysis. Without examining the declared dependencies, potential transitive vulnerabilities cannot be assessed. Fix: Review Package.swift dependencies for known vulnerabilities using tools like Swift Package Manager audit or GitHub dependency scanning
• Low · Incomplete .gitignore coverage — .gitignore. While a .gitignore file exists, the specific rules are not visible. Xcode projects typically require additional exclusions for build artifacts and derived data. Fix: Ensure .gitignore includes: *.xcworkspace/xcuserdata/, DerivedData/, .build/, *.playground, and other Xcode build artifacts

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.