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/Ramotion/folding-cell 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 2y ago

• 5 active contributors
• MIT licensed
• CI configured
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 66% of recent commits
• ⚠ 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 Ramotion/folding-cell repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Ramotion/folding-cell.

What it runs against: a local clone of Ramotion/folding-cell — 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 Ramotion/folding-cell | 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 ≤ 771 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Ramotion/folding-cell(\\.git)?\\b" \\
  && ok "origin remote is Ramotion/folding-cell" \\
  || miss "origin remote is not Ramotion/folding-cell (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 "FoldingCell/FoldingCell/FoldingCell.swift" \\
  && ok "FoldingCell/FoldingCell/FoldingCell.swift" \\
  || miss "missing critical file: FoldingCell/FoldingCell/FoldingCell.swift"
test -f "FoldingCell/FoldingCell-Demo/TableViewController.swift" \\
  && ok "FoldingCell/FoldingCell-Demo/TableViewController.swift" \\
  || miss "missing critical file: FoldingCell/FoldingCell-Demo/TableViewController.swift"
test -f "FoldingCell/FoldingCell-Demo/DemoCell.swift" \\
  && ok "FoldingCell/FoldingCell-Demo/DemoCell.swift" \\
  || miss "missing critical file: FoldingCell/FoldingCell-Demo/DemoCell.swift"
test -f "FoldingCell/FoldingCell/FoldingCell.h" \\
  && ok "FoldingCell/FoldingCell/FoldingCell.h" \\
  || miss "missing critical file: FoldingCell/FoldingCell/FoldingCell.h"
test -f "FoldingCell.podspec" \\
  && ok "FoldingCell.podspec" \\
  || miss "missing critical file: FoldingCell.podspec"

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

FoldingCell is a reusable iOS UITableViewCell subclass that animates expansion/collapse with a paper-folding paper-card material design effect. Built in Swift (31.5KB) with Objective-C bindings, it provides a self-contained cell class that unfolds to reveal expanded content via configurable RotatedView subviews, eliminating the need to implement complex CABasicAnimation sequences manually. Monolithic structure: core library is the single FoldingCell.swift file; two complete demo apps (FoldingCell-Demo/ in Swift, FoldingCell-DemoObjc/ in Objective-C) show integration patterns. Assets include OpenSans fonts, demo images, and storyboards. CocoaPods podspec and Carthage/SPM support files at root.

iOS app developers building content-rich table views who want polished expand/collapse animations without writing CALayer transform and animation code. Particularly useful for UX designers and mobile engineers at agencies building material-design-compliant apps (Ramotion builds custom UIs for mobile).

Production-ready and actively maintained. The project has CocoaPods/Carthage/SPM distribution, passes Travis CI, and carries the Ramotion agency credibility. Supports iOS 8.0+ through Swift 5.0+. However, the lack of visible recent commit dates in the provided file list suggests possible maintenance slowdown—verify current activity on GitHub.

Low risk for stable consumption. The library is self-contained (single FoldingCell.swift file can be dragged directly into projects), has no external dependencies, and uses only native UIKit/CoreAnimation. Main risk: single-maintainer/agency project (Ramotion) means breaking changes could arrive with little notice if they decide to modernize for iOS 15+ API changes. No visible test suite in file list.

Unable to determine from file list alone—no CHANGELOG dates or recent commit info visible. Recommend checking the GitHub repo's 'Commits' tab and open PRs to assess current activity level.

Clone and open in Xcode: git clone https://github.com/Ramotion/folding-cell.git && cd folding-cell && open FoldingCell.xcodeproj. Run FoldingCell-Demo scheme on an iOS simulator. Or integrate via CocoaPods: add pod 'FoldingCell' to Podfile and pod install.

Daily commands: Open FoldingCell.xcodeproj → select FoldingCell-Demo scheme → Cmd+R on an iOS 12+ simulator. Or integrate library into your own project via CocoaPods (pod install then import FoldingCell) and call toggleFold() on a FoldingCell instance.

• FoldingCell/FoldingCell/FoldingCell.swift — Core UITableViewCell subclass implementing the folding animation logic and state management—all cell behavior depends on this.
• FoldingCell/FoldingCell-Demo/TableViewController.swift — Primary Swift demo showing integration patterns, data feeding, and cell lifecycle management for developers.
• FoldingCell/FoldingCell-Demo/DemoCell.swift — Concrete demo cell subclass demonstrating how to customize content views and map data to folding cell UI.
• FoldingCell/FoldingCell/FoldingCell.h — Objective-C bridging header enabling interoperability and defining public API surface for both Swift and ObjC projects.
• FoldingCell.podspec — CocoaPods specification defining versioning, dependencies, and distribution configuration for the library.
• FoldingCell/FoldingCell-DemoObjc/TableViewController.m — Objective-C demo implementation showing equivalent patterns to Swift demo for hybrid or legacy projects.

• FoldingCell (core class) (Swift, UITableViewCell, CABasicAnimation, Core Graphics) — Manages fold/unfold state, creates rotation transforms, applies CABasicAnimation, and handles layout for expanded/collapsed views.
  • Failure mode: Incomplete animation or transform bugs lead to distorted or frozen-looking cells; state mismanagement causes wrong content visibility.
• DemoCell (subclass in Swift demo) (Swift, UIView, UILabel, UIImageView) — Customizes FoldingCell with specific UI (labels, images, buttons) for foregroundView and containerView.
  • Failure mode: Layout conflicts or constraint issues during animation; misaligned content in expanded state.
• TableViewController (Swift demo) (Swift, UITableViewController, UITableViewDataSource, UITableViewDelegate) — Dequeues cells, configures data, manages open/closed state tracking, and triggers fold/unfold on user tap.
  • Failure mode: Cells not configured on reuse; state tracking lost on scroll; animations triggered on already-animating cells.
• CABasicAnimation instance — undefined

Create a custom FoldingCell subclass

1. Subclass FoldingCell imported from FoldingCell.swift (FoldingCell/FoldingCell/FoldingCell.swift)
2. Override init(style:reuseIdentifier:) to set up your custom content views in foregroundView and containerView (FoldingCell/FoldingCell-Demo/DemoCell.swift)
3. Implement a configure method to bind data (text, images) to the expanded and collapsed layouts (FoldingCell/FoldingCell-Demo/DemoCell.swift)
4. In UITableViewController, dequeue your custom cell and call its configure method in cellForRowAt (FoldingCell/FoldingCell-Demo/TableViewController.swift)

Add folding animation on cell tap

1. In UITableViewController, implement didSelectRowAt to detect which cell was tapped (FoldingCell/FoldingCell-Demo/TableViewController.swift)
2. Call the unfold() or fold() method on the FoldingCell instance to trigger animation (FoldingCell/FoldingCell/FoldingCell.swift)
3. Optionally track opened/closed state using a Set and call unfold with isAnimated parameter (FoldingCell/FoldingCell-Demo/TableViewController.swift)

Customize folding animation timing and appearance

1. Examine the unfold/fold method signatures in FoldingCell.swift to see animation duration parameters (FoldingCell/FoldingCell/FoldingCell.swift)
2. Modify foregroundView and containerView layouts in your custom cell subclass to change content positioning (FoldingCell/FoldingCell-Demo/DemoCell.swift)
3. Adjust CABasicAnimation and rotationLayer properties in FoldingCell.swift to alter fold mechanics (FoldingCell/FoldingCell/FoldingCell.swift)

• UITableViewCell subclass — Standard iOS UIKit pattern for reusable, scrollable content; integrates seamlessly with UITableView lifecycle and cell reuse.
• CABasicAnimation (Core Animation) — Hardware-accelerated 2D/3D transforms enable smooth 60 fps folding effect without blocking main thread.
• Swift + Objective-C interop (bridging header) — Supports both modern Swift projects and legacy ObjC codebases, maximizing adoption across existing apps.
• CocoaPods + SPM — Dual package manager support ensures broad compatibility across dependency management preferences.

• UITableViewCell-based (not custom CALayer view)

  • Why: Leverages iOS's proven cell reuse and scrolling optimization out-of-the-box.
  • Consequence: Inherits UITableView's lifecycle constraints; less flexible for non-scroll contexts but more performant at scale.

• Single animation duration parameter instead of per-transform tuning

  • Why: Simpler API surface for common use case.
  • Consequence: Developers cannot independently adjust fold vs. scale timing; requires fork to customize at that level.

• Separate foregroundView (collapsed) and containerView (expanded) layers

  • Why: Clean separation of concerns; avoids layout conflicts during animation.
  • Consequence: More view hierarchy depth; requires careful geometry setup in subclasses.

• Real-time content updates during fold animation (animation snapshots static content).
• Accessibility (VoiceOver) optimizations—focus on visual polish over A11y.
• Support for RTL (right-to-left) layouts.
• Swipe gestures or multi-touch interactions—tap-only model.

No explicit hidden traps documented in provided file list. However: (1) RotatedView outlet wiring is mandatory—forgetting to connect in storyboard will silently break animation. (2) The library uses CABasicAnimation so performance depends on device GPU; test on iPhone 6s and older. (3) Mixing with custom CALayer animations on the same cell may cause animation conflicts. (4) The Objective-C demo exists but bridging details are not visible in file list—consult FoldingCell-DemoObjc/ files for ObjC usage patterns.

• CABasicAnimation Transform — FoldingCell's folding effect is built entirely on CABasicAnimation of CATransform3D properties (scale, rotation, perspective); understanding CATransform3D matrix math is key to customizing the animation
• CATransaction and Animation Grouping — Multiple layers animate in sync (front/back panels folding simultaneously); learning CATransaction ensures animations complete atomically and prevents flickering
• IBOutlet and Storyboard View Wiring — FoldingCell requires RotatedView subviews to be connected via storyboard outlets; misunderstanding IB wiring is the #1 integration failure point
• UITableViewCell Reuse and Lifecycle — FoldingCell inherits UITableViewCell's reuse pool behavior; animations must be cancelled on prepareForReuse() to avoid animation state leaking between visible cells
• Material Design Animation Principles — The paper-folding effect mimics material design's physical motion metaphor; understanding easing curves and duration constraints from Material Design spec improves animation feel
• CADisplayLink for Smooth Animation Orchestration — While not explicitly visible in file list, production-grade folding implementations may use CADisplayLink instead of CABasicAnimation for frame-perfect multi-layer sync; worth understanding the alternative
• 3D Perspective and Depth in UIView Transforms — The folding effect uses m34 perspective transform property on CALayer; mastering this enables pseudo-3D depth cues that make the fold feel physical

• Ramotion/expanding-collection — Sister Ramotion library that provides similar expansion animation but for collection views instead of table cells
• Ramotion/gliding-collection — Companion Ramotion UI library demonstrating coordinated collection-view animations and material design patterns for iOS
• Ramotion/circle-menu — Related Ramotion interaction pattern library showing animated reveal/collapse UI patterns built with CABasicAnimation
• davedelong/MVCTemplate — Orthogonal resource: template for structuring UITableViewCell subclasses cleanly (architecture reference, not animation-specific)
• realm/realm-swift — Common companion for iOS table apps; FoldingCell users often pair with Realm for persistence

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 Swift Package Manager support with Package.swift manifest

The repo currently uses CocoaPods (FoldingCell.podspec exists) but lacks Swift Package Manager support, which is now the preferred dependency manager for Swift projects. This would make the library more accessible to modern iOS projects and reduce friction for adoption.

• [ ] Create Package.swift file at the root with proper product and target definitions
• [ ] Verify the package can be resolved by adding it to a test project via Xcode's 'Add Package Dependency'
• [ ] Update README.md with Swift Package Manager installation instructions (currently only shows CocoaPods)
• [ ] Test that the library builds and functions correctly when integrated via SPM

Migrate iOS demo from Storyboards to SwiftUI with modern patterns

The demo app (FoldingCell/FoldingCell-Demo) uses legacy Storyboard-based UI (Base.lproj/Main.storyboard, Base.lproj/LaunchScreen.storyboard). Creating a SwiftUI version would showcase the library with modern iOS development patterns and serve as a better reference for new contributors using current Xcode templates.

• [ ] Create a new SwiftUI-based TableViewController replacement (e.g., DemoView.swift) using SwiftUI's List with custom cells
• [ ] Convert DemoCell.swift to work with SwiftUI or create a SwiftUI equivalent
• [ ] Update AppDelegate.swift to initialize the SwiftUI view hierarchy for iOS 14+
• [ ] Ensure the SwiftUI demo maintains feature parity with the Storyboard version
• [ ] Add documentation in README showing SwiftUI integration patterns

Add comprehensive unit and snapshot tests for FoldingCell animation behavior

The repo lacks visible test files (no Tests/ directory in the file structure). Adding tests for the core animation logic, cell state transitions, and layout calculations would improve code reliability and prevent regressions as the library evolves.

• [ ] Create Tests/ directory at the root level with unit test targets for both Swift and Objective-C variants
• [ ] Add unit tests covering: cell expansion/collapse state transitions, animation duration validation, and layout constraint updates
• [ ] Implement snapshot tests using a library like iOSSnapshotTestCase to capture expected visual states during animation frames
• [ ] Test edge cases: rapid tap gestures, memory management during animation, cell reuse in table views
• [ ] Add test execution to .travis.yml CI configuration

• Add unit tests for animation completion and timing: create Tests/ folder with XCTest covering FoldingCell.toggleFold() state transitions and CABasicAnimation duration assertions
• Document RotatedView subview hierarchy requirements: add comments to DemoCell.swift or create ARCHITECTURE.md explaining exactly how many RotatedView layers are needed and their constraint setup for non-obvious layouts
• Create a Swift Playgrounds example: add FoldingCell as an interactive playground page in Playgrounds app to lower onboarding friction for designers/junior devs exploring the animation without building a full app

The FoldingCell repository is a UI component library with a relatively secure posture. No critical vulnerabilities were identified. The main concerns are related to maintaining current Swift/compiler versions, ensuring proper dependency management with lock files, and verifying custom assets. The codebase does not appear to handle sensitive data, perform database operations, or expose network services, reducing the attack surface. Recommendations focus on keeping development tools updated and maintaining proper build reproducibility through dependency locking.

• Medium · Outdated Swift Version — .swift-version. The repository contains a .swift-version file which may indicate use of an outdated Swift compiler. Outdated Swift versions may contain known security vulnerabilities and lack modern security features. Fix: Update to the latest stable Swift version and specify it in .swift-version file. Regularly monitor Swift security advisories.
• Low · Incomplete README Security Information — README.md. The README.md file is truncated and may not contain complete security guidelines or contribution guidelines. The URL reference appears incomplete (ends with '/), which could indicate malformed documentation. Fix: Complete and review all documentation, including security guidelines and proper URL references.
• Low · Missing Dependency Lock File — FoldingCell.podspec / Dependency management. No Package.lock or Podfile.lock file content provided. For CocoaPods projects (indicated by .podspec), lock files ensure reproducible builds and prevent unexpected dependency updates. Fix: Ensure Podfile.lock is committed to version control to lock dependency versions and prevent supply chain attacks via unexpected updates.
• Low · Embedded Custom Fonts — FoldingCell/FoldingCell-Demo/Fonts/ and FoldingCell/FoldingCell-DemoObjc/Fonts/. Multiple custom TTF font files are included in the demo app bundles. While generally safe, custom fonts should be from trusted sources and verified for integrity. Fix: Verify font sources, ensure fonts are from trusted providers, and consider using system fonts where possible.

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.