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/AliSoftware/Reusable 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

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

What it runs against: a local clone of AliSoftware/Reusable — 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 AliSoftware/Reusable | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1002 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "AliSoftware/Reusable(\\.git)?\\b" \\
  && ok "origin remote is AliSoftware/Reusable" \\
  || miss "origin remote is not AliSoftware/Reusable (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Sources/Reusable/Reusable.swift" \\
  && ok "Sources/Reusable/Reusable.swift" \\
  || miss "missing critical file: Sources/Reusable/Reusable.swift"
test -f "Sources/Reusable/UITableViewCell+Reusable.swift" \\
  && ok "Sources/Reusable/UITableViewCell+Reusable.swift" \\
  || miss "missing critical file: Sources/Reusable/UITableViewCell+Reusable.swift"
test -f "Sources/Reusable/UICollectionViewCell+Reusable.swift" \\
  && ok "Sources/Reusable/UICollectionViewCell+Reusable.swift" \\
  || miss "missing critical file: Sources/Reusable/UICollectionViewCell+Reusable.swift"
test -f "Sources/Reusable/UIView+Reusable.swift" \\
  && ok "Sources/Reusable/UIView+Reusable.swift" \\
  || miss "missing critical file: Sources/Reusable/UIView+Reusable.swift"
test -f "Sources/Reusable/Nib.swift" \\
  && ok "Sources/Reusable/Nib.swift" \\
  || miss "missing critical file: Sources/Reusable/Nib.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 1002 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~972d)"
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/AliSoftware/Reusable"
  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).

Reusable is a Swift mixin library that eliminates String-based reuseIdentifier management for UITableViewCells, UICollectionViewCells, UIViewControllers, and custom UIViews. It provides type-safe, compile-checked APIs to register and dequeue reusable UI components from XIB files and storyboards without runtime string errors. Simple flat structure: source code in root-level Swift files (not shown in detail but referenced in podspec), Example/ directory contains a CocoaPods-based demo app with iOS and tvOS targets (Example/Pods directories), CI config in .circleci/config.yml, and linting setup in .swiftlint.yml and Example/.swiftlint.yml.

iOS/tvOS developers building UIKit applications who want to eliminate boilerplate reuseIdentifier string literals and gain compiler-verified cell/view registration and dequeuing. Particularly valuable for teams managing large collections of custom cells.

Production-ready and actively maintained. The project supports Swift 3–5, has CI/CD via CircleCI (visible in .circleci/config.yml), publishes to CocoaPods/Carthage/SPM, and the library is approximately 35KB of Swift. However, repo activity is moderate—last visible structure suggests ongoing maintenance but not rapid iteration.

Low risk for core usage. Single-maintainer project (AliSoftware), but the library is narrow-scoped and stable. No external production dependencies visible (cocoapod/carthage metadata is dependency-free). Main risk: tight coupling to UIKit means it will eventually age out as SwiftUI adoption increases, though current UIKit projects are safe.

No specific recent commits or PRs visible in provided data. The CHANGELOG.md exists but content not shown. The repo appears in maintenance mode rather than active feature development, with focus on compatibility across Swift versions (3, 4, 5) and multiple distribution channels (SPM, Carthage, CocoaPods).

Clone and examine the Example app:

git clone https://github.com/AliSoftware/Reusable.git
cd Reusable/Example
pod install
open Reusable.xcworkspace

Or integrate into your project via SPM, Carthage, or CocoaPods per the README sections.

Daily commands: This is a library, not an app. To run the demo: cd Example && pod install && open Reusable.xcworkspace then build the ReusableDemo iOS or tvOS scheme. For library development, open the workspace root and run tests (test configuration likely in CI config).

• Sources/Reusable/Reusable.swift — Core protocol definitions and type-safe reuse identifier logic — foundational API that all extensions build upon
• Sources/Reusable/UITableViewCell+Reusable.swift — UITableViewCell integration showing how to dequeue cells safely by type — primary pattern used throughout the library
• Sources/Reusable/UICollectionViewCell+Reusable.swift — UICollectionViewCell integration demonstrating collection-specific reuse logic — parallels table view pattern
• Sources/Reusable/UIView+Reusable.swift — XIB loading mechanism via loadFromNib() — enables custom views to be instantiated from interface builder files
• Sources/Reusable/Nib.swift — Nib abstraction layer managing UINib instances — central utility for XIB file instantiation
• Example/ReusableDemo iOS/TableViewController.swift — Working example of table view cell reuse patterns — demonstrates real-world usage of the library
• Example/ReusableDemo iOS/CollectionViewController.swift — Working example of collection view cell and supplementary view reuse — shows advanced use cases

• Reusable protocol (Swift protocol with default implementation) — Core marker protocol defining reuseIdentifier computed property; enables generic extension methods
  • Failure mode: If type does not conform, compiler prevents registration/dequeue; if name does not match XIB, load

Add a new UITableViewCell subclass

1. Create a new Swift file extending UITableViewCell and conform to Reusable protocol (Example/ReusableDemo iOS/TableViewCells/MyXIBTextCell.swift)
2. Optionally create a XIB file with matching name; if used, also conform to NibLoadable (Example/ReusableDemo iOS/TableViewCells/MyXIBTextCell.xib)
3. In UITableViewController, call tableView.register(_:forCellReuseIdentifier:) with your cell type (Example/ReusableDemo iOS/TableViewController.swift)
4. Dequeue using tableView.dequeueReusableCell(ofType:for:) — no casting required (Example/ReusableDemo iOS/TableViewController.swift)

Add a new UICollectionViewCell and supplementary view

1. Create cell class conforming to Reusable; optionally NibLoadable if using XIB (Example/ReusableDemo iOS/CollectionViewCells/MyColorSquareCell.swift)
2. Create supplementary view (e.g., header) conforming to Reusable and NibLoadable (Example/ReusableDemo iOS/CollectionViewCells/CollectionHeaderView.swift)
3. Register cell and supplementary views in collectionView using type-safe register methods (Example/ReusableDemo iOS/CollectionViewController.swift)
4. Dequeue using collectionView.dequeueReusableCell(ofType:for:) and dequeueReusableSupplementaryView (Example/ReusableDemo iOS/CollectionViewController.swift)

Load a custom UIView from XIB

1. Create UIView subclass conforming to Reusable and NibLoadable (Example/ReusableDemo iOS/CustomViews/MyCustomWidget.swift)
2. Design the view layout in a XIB file matching the class name (Example/ReusableDemo iOS/CustomViews/MyCustomWidget.xib)
3. Instantiate the view anywhere using MyCustomWidget.loadFromNib() — returns properly initialized instance (Example/ReusableDemo iOS/CustomViews/MyCustomWidget.swift)

Instantiate a UIViewController from Storyboard safely

1. Create UIViewController subclass conforming to Reusable (Example/ReusableDemo iOS/Storyboards/InfoViewController.swift)
2. In storyboard, set controller Storyboard ID to match class name (Example/ReusableDemo iOS/Storyboards/InfoViewController.storyboard)
3. Load using UIStoryboard(name:bundle:).instantiateViewController(ofType:) with no string literal (Example/ReusableDemo iOS/Storyboards/InfoViewController.swift)

• Swift Protocols & Generics — Enable compile-time type safety for reuse identifiers without runtime string manipulation; allows default implementations to derive identifier from class name
• UIKit Extensions — Extend UITableView, UICollectionView, and cell types with convenience methods that enforce Reusable protocol conformance at the call site
• UINib abstraction — Manage XIB file loading with caching and error handling; decouple view instantiation from raw UINib complexity

• Class name as reuseIdentifier default

  • Why: Simplifies common case where XIB or storyboard element ID matches class name; reduces boilerplate
  • Consequence: Requires naming convention discipline; identifier is implicit and harder to debug if mismatched

• Protocol-based approach instead of base classes

  • Why: Allows cells and views to inherit from any UIKit parent; supports existing hierarchies without breaking changes
  • Consequence: No shared initialization logic; each type must conform independently

• XIB name must match class name (NibLoadable default)

  • Why: Eliminates need to hardcode XIB file names; convention over configuration
  • Consequence: Forces file naming consistency; custom names require manual Nib() override

• Does not handle view controller navigation or presentation logic
• Does not provide data binding or reactive updates
• Does not manage view controller lifecycle callbacks beyond instantiation
• Does not support custom reuseIdentifier generation strategies without protocol override

No hidden environment variables or service dependencies. Key constraint: library is UIKit-only and will not work with SwiftUI projects without significant refactoring. The .swiftlint.yml and Example/.swiftlint.yml have slight configuration drift—ensure consistency when modifying linting rules. CocoaPods gem dependencies (seen in Example/Podfile) may require Ruby 2.x compatibility.

• Protocol-based mixins — Reusable uses Swift protocol extensions to inject type-safe registration/dequeue methods into UIKit classes without subclassing, a powerful pattern for cross-cutting concerns
• Generic type safety via Self types — The library leverages Self-returning generics to ensure reuseIdentifier matches the actual cell/view type, eliminating String errors at compile time
• XIB-based view composition — Reusable simplifies loading custom UIViews from Interface Builder XIB files via loadFromNib(), reducing boilerplate for reusable view components
• Reuseidentifier pattern in UIKit — UITableView and UICollectionView recycle cells using String identifiers for memory efficiency; Reusable wraps this pattern to prevent typos and crashes
• Storyboard segue instantiation — Reusable provides type-safe alternatives to manually looking up view controllers by String storyboard IDs, reducing navigation crashes
• Swift type reflection and metadata — The library uses String(describing:) and type introspection to derive reuseIdentifiers automatically from class names, avoiding manual string duplication

• realm/realm-swift — Popular ORM that shares the goal of reducing boilerplate and String-based identifiers, relevant for data-heavy list/collection views
• pointfreeco/swift-dependencies — Modern Swift dependency injection, complementary to Reusable for wiring cell/view dependencies without String coupling
• Alamofire/Alamofire — Widely-used networking library often paired with Reusable cells in list/collection view data flows
• SnapKit/SnapKit — Auto-layout DSL frequently used in Reusable cells to avoid XIB files or Interface Builder friction
• SwiftyJSON/SwiftyJSON — JSON parsing often needed in conjunction with Reusable cells for populating view data from network responses

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 (SPM) support with Package.swift manifest

The repo currently supports CocoaPods (Podfile exists) but lacks Swift Package Manager support, which is now the standard for modern Swift projects. This would allow developers using SPM to adopt Reusable without CocoaPods, increasing accessibility and aligning with current Swift ecosystem practices.

• [ ] Create Package.swift manifest at root with proper version and platform declarations
• [ ] Define library targets for iOS and tvOS platforms (already split in Pods/Target Support Files)
• [ ] Ensure Sources/ directory structure matches SPM conventions and reference existing source files
• [ ] Test local integration with swift build and add SPM verification to .circleci/config.yml

Migrate from CircleCI to GitHub Actions with Swift testing workflow

The repo uses CircleCI (.circleci/config.yml exists) but GitHub Actions is now the standard for GitHub-hosted projects. This modernizes the CI/CD pipeline, reduces external dependencies, and provides better integration with GitHub's native tooling. The current CircleCI config appears minimal and could be better specified.

• [ ] Create .github/workflows/swift-tests.yml with matrix testing for iOS and tvOS targets
• [ ] Add SwiftLint validation step (repo already has .swiftlint.yml configuration)
• [ ] Include Swift version matrix (3, 4, 5) as documented in README badges
• [ ] Archive and document the .circleci/config.yml for reference, then remove the directory

Add comprehensive unit tests for core Reusable protocols in Tests/ directory

The repo lacks visible test coverage for its core type-safe reuse mechanisms (Reusable protocol, NibLoadable, etc.). Given this is a library focused on UITableViewCell/UICollectionViewCell registration and XIB loading, robust tests would catch regressions and validate the core functionality works across iOS and tvOS.

• [ ] Create Tests/ directory structure with separate test targets for iOS and tvOS (mirroring Example/Pods structure)
• [ ] Write unit tests for Reusable protocol conformance, reuseIdentifier generation, and type-safe cell registration
• [ ] Add tests for NibLoadable and loadFromNib() functionality with mock XIB scenarios
• [ ] Integrate test execution into .circleci/config.yml (or new GitHub Actions workflow from PR #2)

• Add unit tests for XIB loading edge cases (e.g., missing XIB file, malformed XIB structure). Tests likely missing or incomplete—check Example/Tests or root Tests/ directory.
• Expand README with SwiftUI compatibility notes or migration guide, since UIKit adoption is declining and users may land here asking about SwiftUI integration.
• Document and add examples for loading custom views with multiple XIB files or complex view hierarchies—common real-world scenario not visible in Example/ structure shown.

The Reusable library is a well-structured Swift utility library with generally good security posture. The main concern is the committed Pods directory which inflates the repository and deviates from standard dependency management practices. No hardcoded credentials, SQL injection risks, XSS vulnerabilities, or infrastructure misconfigurations were detected. The library itself is a UI utility mixin without network access, database interactions, or sensitive data handling, limiting inherent attack surface. Recommendations focus on build hygiene, policy documentation, and keeping dependencies current.

• Medium · Pods Directory Checked Into Version Control — Example/Pods/. The entire Example/Pods directory is present in the repository. This includes compiled dependencies and generated files that should typically be excluded from version control. This increases repository size, can lead to merge conflicts, and makes it harder to track actual code changes. Fix: Add 'Pods/' to .gitignore and use CocoaPods pod install workflow. Users should run 'pod install' to fetch dependencies rather than having them committed.
• Low · Missing SECURITY.md or Security Policy — Repository root. No security policy file (SECURITY.md) is present in the repository. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file documenting how to report security vulnerabilities responsibly, including contact information and expected response times.
• Low · CircleCI Configuration Exposed — .circleci/config.yml. The CircleCI configuration file (.circleci/config.yml) is present in version control. While this is standard practice, ensure no secrets, API keys, or credentials are hardcoded in CI/CD configuration. Fix: Verify that all sensitive values (API keys, tokens, credentials) are stored as environment variables in CircleCI project settings, not in the config file itself.
• Low · Outdated Swift Language Versions — README.md, .podspec. README indicates support for Swift 3, 4, and 5. Swift 3 and 4 are significantly outdated (released in 2016-2017) and may have unpatched security vulnerabilities. Current stable versions should be prioritized. Fix: Update minimum Swift version requirement to Swift 5.5 or later. Drop support for Swift 3 and 4 in new releases to encourage users to update.

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.