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/xmartlabs/Eureka 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

• 35+ active contributors
• Distributed ownership (top contributor 46% of recent commits)
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y 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 xmartlabs/Eureka repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/xmartlabs/Eureka.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "xmartlabs/Eureka(\\.git)?\\b" \\
  && ok "origin remote is xmartlabs/Eureka" \\
  || miss "origin remote is not xmartlabs/Eureka (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 "Eureka.podspec" \\
  && ok "Eureka.podspec" \\
  || miss "missing critical file: Eureka.podspec"
test -f "Eureka.xcodeproj/project.pbxproj" \\
  && ok "Eureka.xcodeproj/project.pbxproj" \\
  || miss "missing critical file: Eureka.xcodeproj/project.pbxproj"
test -f "Eureka.playground/Contents.swift" \\
  && ok "Eureka.playground/Contents.swift" \\
  || miss "missing critical file: Eureka.playground/Contents.swift"
test -f "Example/Example/AppDelegate.swift" \\
  && ok "Example/Example/AppDelegate.swift" \\
  || miss "missing critical file: Example/Example/AppDelegate.swift"
test -f "CHANGELOG.md" \\
  && ok "CHANGELOG.md" \\
  || miss "missing critical file: CHANGELOG.md"

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

Eureka is a Swift framework that provides declarative form-building for iOS using a fluent DSL syntax (Form +++ Section <<< Row). It eliminates UITableView boilerplate by wrapping form layouts, validation, and cell configuration into composable row types, allowing developers to define complex multi-section forms in 20 lines of code instead of 200. Monolithic single-framework structure: Sources/ contains all Swift form row types and cells, with Examples/ as a runnable demo app. No internal packages or modules—architecture is horizontal (TextRow, PhoneRow, DateRow, etc. all at same level) with shared base classes and protocols (likely Row<T> generic base). Xcode workspace integrates both Eureka.xcodeproj (the framework) and Example.xcodeproj (the demo).

iOS developers building data entry screens, surveys, settings panels, or admin interfaces who want form logic without managing UITableViewDataSource/UITableViewDelegate implementations and custom cell code. Specifically those using Swift 5.0+ on Xcode 11+.

Mature and actively maintained. The repo shows Swift compatibility badges, Travis CI integration in .github/workflows/ci.yml, CocoaPods/Carthage distributions via Eureka.podspec, and a comprehensive Example project with multiple demo GIFs. CHANGELOG.md exists indicating version history tracking. Last activity appears recent based on the structured CI pipeline.

Low risk for most use cases—it's a focused UI library with no external dependencies (631KB of pure Swift code in Sources/). The main risk is iOS version coupling (requires iOS support tied to Swift 5.0+), and any breaking form structural changes would cascade through dependent apps. Single-maintainer model (xmartlabs) means feature prioritization depends on their roadmap.

Actively maintained with CI/CD via GitHub Actions (.github/workflows/ci.yml). Migration guide (Documentation/Eureka 2.0 Migration Guide.md) and Chinese localization (Documentation/README_CN.md) suggest recent releases. Bug and feature request templates (.github/ISSUE_TEMPLATE/) are configured, indicating active triage. Specific recent work is not visible in the file list, but the structured CI setup implies continuous validation.

Clone the repo with git clone https://github.com/xmartlabs/Eureka.git, open Eureka.xcworkspace in Xcode (not the .xcodeproj), and run the Example scheme. To use in your project: pod 'Eureka' (CocoaPods, see Eureka.podspec) or github "xmartlabs/Eureka" (Carthage).

Daily commands: Open Eureka.xcworkspace (not .xcodeproj), select Example scheme, and press Cmd+R or Product > Run in Xcode. The Example app demonstrates form creation, validation, and dynamic row visibility.

• Eureka.podspec — Defines the library version, dependencies, and platform requirements; essential for understanding release versions and compatibility.
• Eureka.xcodeproj/project.pbxproj — Core Xcode project configuration; required to understand build targets, schemes, and framework dependencies.
• Eureka.playground/Contents.swift — Interactive playground demonstrating Eureka's primary form-building APIs and patterns; best entry point for understanding the framework's design.
• Example/Example/AppDelegate.swift — Example application entry point; shows how to integrate Eureka into a real iOS app.
• CHANGELOG.md — Documents all breaking changes, migrations, and feature additions across versions; critical for understanding evolution and compatibility issues.
• Documentation/Eureka 2.0 Migration Guide.md — Major version migration guide; essential for understanding architectural decisions and deprecated patterns.
• .github/workflows/ci.yml — CI/CD pipeline definition; shows build, test, and deployment processes used by the project.

Add a Custom Row Type

1. Create a new row class that extends Row<T> or a specific row type (e.g., FieldRow, PickerRow) in your project (Example/Example/Controllers/CustomCellsViewController.swift)
2. Define a custom Cell class conforming to CellType and override the setup() method to configure the cell's appearance and behavior (Example/Example/Controllers/CustomCellsViewController.swift)
3. Register the custom row/cell pair in your form's section by instantiating it and configuring validation, placeholders, and callbacks (Example/Example/Controllers/RowsExample.swift)
4. Add the row to a Form section and test with the Example app to verify behavior (Example/Example/AppDelegate.swift)

Build a Multi-Section Form with Validation

1. Create a FormViewController subclass and initialize a Form instance in viewDidLoad() (Example/Example/Controllers/RowsExample.swift)
2. Define multiple Section objects and add them to the form with descriptive headers and footers (Example/Example/Controllers/RowsExample.swift)
3. Add row types (TextRow, EmailRow, SwitchRow, etc.) to each section with validation rules and cell configuration (Example/Example/Controllers/FieldRowCustomizationController.swift)
4. Attach tableView to form and implement callbacks to handle form value changes and submission (Example/Example/Controllers/RowsExample.swift)

Create Conditional Row Visibility with Hidden/Disabled Logic

1. Define rows with unique identifiers (tag property) in your form sections (Example/Example/Controllers/HiddenRowsExample.swift)
2. Use the hidden property with a closure that evaluates form conditions; update when other row values change (Example/Example/Controllers/HiddenRowsExample.swift)
3. Use the disabled property similarly to conditionally prevent user interaction without hiding rows (Example/Example/Controllers/DisabledRowsExample.swift)
4. Test visibility and enabled state changes by modifying related row values in the form (Example/Example/Controllers/HiddenRowsExample.swift)

Implement Multi-Valued Sections for Arrays

1. Use MultivaluedSection with add/remove button rows to allow dynamic array row addition (Example/Example/Controllers/MultivaluedExamples.swift)
2. Add row prototypes (e.g., TextRow, EmailRow) to the MultivaluedSection that will be cloned for new entries (Example/Example/Controllers/MultivaluedExamples.swift)
3. Bind the section's values property to your model's array property for automatic synchronization (Example/Example/Controllers/MultivaluedExamples.swift)
4. Access the form's values dictionary at form submission to extract the multi-valued array results (Example/Example/Controllers/MultivaluedExamples.swift)

• Swift 5 — Modern, type-safe language native to iOS development with strong compile-time error checking and concise syntax.
• UIKit + TableView — Mature, performant foundation for building responsive form UIs; TableView provides efficient cell reuse for large forms.
• CocoaPods + Carthage — Industry-standard dependency managers; broad ecosystem compatibility and version pinning for reproducible builds.
• XCTest — Native Apple testing framework integrated with Xcode for unit and integration testing of form logic.

• UIKit-based (not SwiftUI)

  • Why: Eureka is a mature framework predating SwiftUI; provides battle-tested abstractions for complex form logic.
  • Consequence: Not optimized for SwiftUI apps; developers must use UIViewControllerRepresentable bridges or maintain dual codebases.

• DSL-based form definition (chaining API)

  • Why: Enables declarative, readable form construction without boilerplate; reduces code needed for complex forms.
  • Consequence: Steep learning curve for developers unfamiliar with functional chaining patterns; harder to debug when chaining is nested deeply.

• Direct TableView integration

  • Why: Tight coupling to UITableView enables fine-grained control over cell recycling, section management, and animations.
  • Consequence: Less flexible for custom table view behaviors; harder to integrate with views other than UITableView.

• Cell-driven validation and visibility logic

  • Why: Validation and conditional visibility live close to the UI, reducing state synchronization complexity.
  • Consequence: Business logic can become entangled with UI code; harder to test validation independently of UIKit.

• Not a backend service or API abstraction layer; purely client-side form building.
• Does not provide real-time synchronization or offline-first form data persistence.
• Not a form data validation library in isolation; validation is tightly integrated with row definitions.
• Does not support non-UIKit rendering (e.g., SwiftUI native, web, cross-platform).
• Not a accessibility-first framework; accessibility is supported but not a primary design goal.
• Does not manage authentication, user sessions, or secure credential storage.

No external package manager lock files visible (Podfile.lock / Cartfile.resolved not in file list)—contributors must run pod install after cloning if using CocoaPods locally. The .xcworkspace is required (not .xcodeproj) due to dependency management—opening the raw .xcodeproj will fail. Xcode version constraint (11+) is strict; older versions will not build. The Example and framework projects are separate .xcodeproj files within a shared workspace—editing framework files and testing requires building through the workspace, not the Example app directly.

• Fluent Builder DSL — Eureka's core syntax (form +++ section <<< row) is a fluent DSL using operator overloading—understanding how +++ and <<< operators chain objects is key to reading and extending the framework
• Generic Row<T> Type System — All rows inherit from Row<T> where T is the value type (String, Date, Int, etc.)—understanding Swift generics and associated types is essential for creating custom row types
• Protocol-Oriented Row Definition — Rows conform to protocols (RowType, BaseRow) rather than strict inheritance chains—this allows composition of behaviors like validation, visibility, and callbacks without deep hierarchies
• Closure-Based Callbacks — Form logic relies on trailing closure syntax (row.onChange { ... }) rather than delegates—this requires understanding Swift closure capture, @escaping, and weak self patterns to avoid memory leaks
• UITableView Abstraction Layer — Eureka wraps UITableViewDataSource/UITableViewDelegate behind Row and Section objects—understanding the underlying UITableView lifecycle (reloadData, reloadRows) helps debug cell rendering issues
• Declarative Form Validation Rules — Validation is expressed as composable Rule objects added to rows (.add(rule)) rather than imperative validation logic—this enables reusable, testable validation chains
• Dynamic Row Visibility via Conditions — Rows can be hidden/shown based on conditions of other rows—this requires understanding Eureka's observable pattern (likely KVO or custom observers) to trigger form restructuring without full reload

• xmartlabs/XLForm — The original Objective-C predecessor to Eureka—same team, same philosophy, shows the form-building approach that inspired the Swift port
• ReactiveCocoa/ReactiveCocoa — Reactive framework often paired with Eureka for binding form state changes to business logic without manual delegate callbacks
• SwiftyJSON/SwiftyJSON — Commonly used with Eureka to serialize/deserialize form row values to/from JSON payloads in API calls
• realm/realm-swift — Frequently integrated with Eureka to persist form data directly to Realm databases and hydrate forms from stored models
• nicklockwood/SwiftFormat — Ecosystem companion for maintaining Swift style consistency across custom row implementations and extensions

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 SPM (Swift Package Manager) support and CI workflow

The repo has Eureka.podspec for CocoaPods and Carthage support (badges in README), but no Package.swift file for Swift Package Manager. SPM is now the preferred dependency manager in modern Swift development. This would involve creating a Package.swift manifest and adding a GitHub Actions workflow to test SPM builds alongside the existing CocoaPods/Carthage tests in .github/workflows/ci.yml.

• [ ] Create Package.swift in root directory with proper product/target definitions
• [ ] Update .github/workflows/ci.yml to add SPM build and test matrix
• [ ] Update README.md to add SPM installation instructions
• [ ] Test that Example.xcodeproj can resolve Eureka via SPM
• [ ] Add SPM badge to README alongside existing CocoaPods/Carthage badges

Add comprehensive unit tests for core Row and Section classes

The repo has Example project and playgrounds but no visible Sources/Tests directory in the file structure. For a form builder library, core functionality like Row validation, Section visibility toggling, and form state management should have dedicated unit tests. This would improve code reliability and make it safer for contributors to refactor.

• [ ] Create Tests/ directory structure (if not present) with test targets
• [ ] Add XCTestCase subclasses for core Row types (TextRow, SwitchRow, DateRow, etc.)
• [ ] Add tests for Section behavior (hide/show, enable/disable, visibility conditions)
• [ ] Add tests for FormViewController state management and validation
• [ ] Update .github/workflows/ci.yml to run test suite and report coverage

Update CI workflow to test multiple Swift/iOS versions and minimum deployment targets

The .github/workflows/ci.yml likely tests against one Swift/iOS version, but the README mentions Swift 5 compatibility. Testing against multiple versions (Swift 5.x, 5.9, 6.0 if available) and iOS deployment targets would catch regressions early and clarify compatibility guarantees for users.

• [ ] Review current .github/workflows/ci.yml to identify tested versions
• [ ] Expand CI matrix to test against Swift 5.5, 5.8, 5.9 and iOS 12-17
• [ ] Add Xcode version matrix corresponding to Swift versions
• [ ] Document minimum supported Swift and iOS versions in README.md and CONTRIBUTING.md
• [ ] Add CI status badge for multiple configurations to README

• Add unit tests for validation rule types (RuleType subclasses like MinLengthRule, MaxLengthRule)—Tests/ directory exists but likely has gaps for all validation logic paths.
• Expand Documentation/README_CN.md parity with English README—translate missing sections (Validations, Custom rows, Row catalog examples) to match the main README's completeness.
• Create playground examples in Eureka.playground/Contents.swift for 3-5 common form patterns (login form, user profile, multi-section survey)—currently minimal, but playground is configured and ideal for interactive learning.

The Eureka iOS form builder codebase demonstrates a generally secure posture. As a UI library with no apparent backend connectivity or complex data processing, injection risks are minimal. No hardcoded credentials, environment files, or exposed secrets were identified in the file structure. The main areas of concern are: (1) use of deprecated CI/CD infrastructure (Travis CI), (2) minor HTTP/HTTPS inconsistency in documentation, and (3) inability to verify dependency security without accessing the podspec content. The library itself is a pure Swift UI framework, which inherently reduces the attack surface. Developers integrating this library should ensure they review their own usage patterns and validate any custom code added on top of Eureka.

• Low · Outdated CI/CD Configuration — .github/workflows/ci.yml, README.md. The repository uses Travis CI which has been deprecated. The badge and CI configuration reference an outdated service that is no longer actively maintained. Fix: Migrate to GitHub Actions or another actively maintained CI/CD platform. Update the CI configuration and remove Travis CI references.
• Low · HTTP URL in Documentation Badge — README snippet. The README contains an HTTP URL (http://img.shields.io/...) instead of HTTPS for a badge source. While this is a documentation badge, it's good practice to use HTTPS for all external resources. Fix: Update the badge URL from http:// to https://img.shields.io/ to ensure secure resource loading.
• Low · No Dependency Pinning Information Available — Eureka.podspec. The Eureka.podspec file is present but its content was not provided for analysis. Without visibility into dependency versions, it's unclear if dependencies are pinned to specific secure versions. Fix: Review the podspec to ensure all dependencies are pinned to specific versions or version ranges that exclude known vulnerable versions. Regularly audit and update dependencies.

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.