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/yoavlt/LiquidFloatingActionButton 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

• 14 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 4y ago
• ⚠ Concentrated ownership — top contributor handles 75% of recent commits

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

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "yoavlt/LiquidFloatingActionButton(\\.git)?\\b" \\
  && ok "origin remote is yoavlt/LiquidFloatingActionButton" \\
  || miss "origin remote is not yoavlt/LiquidFloatingActionButton (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 "Example/LiquidFloatingActionButton/ViewController.swift" \\
  && ok "Example/LiquidFloatingActionButton/ViewController.swift" \\
  || miss "missing critical file: Example/LiquidFloatingActionButton/ViewController.swift"
test -f "Example/Podfile" \\
  && ok "Example/Podfile" \\
  || miss "missing critical file: Example/Podfile"
test -f "Example/LiquidFloatingActionButton.xcworkspace/contents.xcworkspacedata" \\
  && ok "Example/LiquidFloatingActionButton.xcworkspace/contents.xcworkspacedata" \\
  || miss "missing critical file: Example/LiquidFloatingActionButton.xcworkspace/contents.xcworkspacedata"
test -f ".swift-version" \\
  && ok ".swift-version" \\
  || miss "missing critical file: .swift-version"
test -f ".travis.yml" \\
  && ok ".travis.yml" \\
  || miss "missing critical file: .travis.yml"

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

LiquidFloatingActionButton is a Swift library that implements Material Design's Floating Action Button (FAB) with animated liquid morphing effects during state transitions. It uses custom Core Animation and Bezier path drawing to create the 'liquid' visual effect when the FAB opens/closes, inspired by the Material In a Liquid State design pattern. Simple, focused library structure: core animation logic lives in the main Swift files (not shown in truncated list but inferred from README), Example/ contains a fully runnable Xcode project demonstrating dataSource/delegate usage with ViewController.swift, Pods/ handles CocoaPods dependency management, and Demo/ stores GIF assets. No monorepo; single cohesive component.

iOS developers building Material Design-compliant apps who want visually polished, animated FABs with liquid state transitions. Used by developers who prioritize Material Design aesthetics and need a drop-in FAB component with delegation-based customization (similar to UITableView's dataSource/delegate pattern).

Moderately mature and stable. The project supports Swift 5.0, has CI via Travis CI, is distributed through CocoaPods and Carthage, and appears actively maintained with Objective-C compatibility. However, no explicit test files are visible in the file structure, and the commit recency is unknown from the provided data—treat it as production-ready but with light testing coverage.

Low-to-moderate risk. Single-language dependency on Swift limits cross-platform reuse. The repo has minimal explicit test coverage (no Test target visible in file list), relies on a single maintainer (yoavlt), and lacks visible version pinning constraints for dependencies. SnapKit is the primary dependency (visible in Pods/); ensure compatibility with your deployment target (iOS 8.0+ based on xcscheme).

Unable to determine from provided data. Check GitHub's activity tab for recent commits, PRs, and issues. The repo description and README suggest stable, feature-complete state (liquid animation, customization, Objective-C compatibility all marked as complete).

git clone https://github.com/yoavlt/LiquidFloatingActionButton.git
cd LiquidFloatingActionButton/Example
pod install
open LiquidFloatingActionButton.xcworkspace
# Open in Xcode and run on simulator/device

Daily commands: Open Example/LiquidFloatingActionButton.xcworkspace (not .xcodeproj—CocoaPods dependency), select the LiquidFloatingActionButton-Example scheme, and run on iOS Simulator or device. The Example/ViewController.swift demonstrates dataSource/delegate setup with sample icons (ic_art, ic_brush, ic_cloud, ic_place, ic_system from Images.xcassets).

• Example/LiquidFloatingActionButton/ViewController.swift — Primary example implementation showing how to instantiate and configure the LiquidFloatingActionButton component with animations
• Example/Podfile — Dependency manifest defining SnapKit constraint library requirement for the example project
• Example/LiquidFloatingActionButton.xcworkspace/contents.xcworkspacedata — Workspace configuration integrating the main library pod with the example app
• .swift-version — Specifies Swift language version compatibility required for building and contributing to this library
• .travis.yml — CI/CD pipeline configuration defining automated testing and build verification on every commit
• Example/LiquidFloatingActionButton/Images.xcassets — Asset catalog containing all icon and image resources used in the UI component and example application

• LiquidFloatingActionButton (UIView, CABasicAnimation, UITapGestureRecognizer, SnapKit) — Main component encapsulating the FAB view, liquid state animations, gesture handling, and action callbacks
  • Failure mode: Animation glitches if bezier curve calculations are incorrect; poor performance on older devices if animation frame rate drops
• ViewController (UIViewController, SnapKit, LiquidFloatingActionButton) — Manages button lifecycle, instantiation, constraint setup, and routes tap actions to application logic
  • Failure mode: Crashes if constraints are over-constrained or conflicting; leaked memory if button reference not released
• SnapKit Constraint System (NSLayoutConstraint, UIView Extensions) — Provides declarative API for defining autolayout constraints on button position and size
  • Failure mode: Invalid constraints cause layout exceptions; circular dependencies prevent view rendering
• Core Animation Render Pipeline (CABasicAnimation, CADisplayLink, Metal/OpenGL) — Renders keyframe animations for smooth liquid morphing shape transitions and position changes
  • Failure mode: Dropped frames if animation complexity exceeds GPU capacity; visual tearing if animation timing is inaccurate

• User Touch Input → UITapGestureRecognizer — Touch event detected on FAB view triggers gesture recognizer callback
• UITapGestureRecognizer → ViewController Action Handler — Gesture recognizer delegates tap event to registered action closure or target-action pair
• ViewController Action Handler → LiquidFloatingActionButton Animator — Action handler triggers button animation sequence (liquid morphing, position change)
• LiquidFloatingActionButton Animator → Core Animation Engine — Button creates CABasicAnimation objects with bezier curves and timing functions
• Core Animation Engine → GPU Render Pipeline — Animation frames rendered by GPU at display refresh rate (60 or 120 FPS)
• SnapKit Constraint Builder → NSLayoutConstraint System — Constraint declarations compiled to NSLayoutConstraint objects installed on view hierarchy
• NSLayoutConstraint System → UIView Frame Geometry — Constraint solver calculates view frames and positions applied during layout pass

Add a new action button to the floating menu

1. Create a new image asset in Images.xcassets with the icon for your new action (Example/LiquidFloatingActionButton/Images.xcassets)
2. In ViewController.swift, instantiate a new LiquidFloatingActionButton with the new icon image and define its action handler (Example/LiquidFloatingActionButton/ViewController.swift)
3. Configure button position and animation properties using SnapKit constraints and liquid state settings (Example/LiquidFloatingActionButton/ViewController.swift)

Customize button animation and appearance

1. Modify the LiquidFloatingActionButton configuration in ViewController.swift to adjust animation duration, color, and liquid wave parameters (Example/LiquidFloatingActionButton/ViewController.swift)
2. Use SnapKit constraint chains to reposition the button relative to superview or sibling views (Example/Pods/SnapKit/Source/ConstraintMaker.swift)

Add support for a new Swift version

1. Update .swift-version file to specify the new Swift language version (.swift-version)
2. Update .travis.yml to test against the new Swift version in CI/CD pipeline (.travis.yml)
3. Verify compatibility by running the example project build with updated Xcode toolchain (Example/LiquidFloatingActionButton.xcodeproj/project.pbxproj)

• Swift — Primary language for iOS library development; provides type safety and modern language features
• SnapKit — Declarative autolayout constraint DSL simplifies responsive UI layout across device sizes
• Core Animation (CABasicAnimation) — Provides efficient, hardware-accelerated graphics rendering for smooth liquid morphing animations
• UIView — Foundation iOS view hierarchy component enabling gesture recognition and view manipulation
• CocoaPods — Standard iOS dependency management system ensuring reliable version control and distribution

• Liquid state morphing via Core Animation rather than custom drawing

  • Why: Balances visual fidelity with performance by using GPU-accelerated animations
  • Consequence: Requires careful bezier curve configuration; limited to predefined animation patterns

• Single FAB component with programmatic configuration over SwiftUI declarative approach

  • Why: Maintains compatibility with older iOS versions (8.3+) and UIKit-based codebases
  • Consequence: Less ergonomic than modern SwiftUI but reaches broader audience; requires manual state management

• SnapKit for constraints rather than frame-based positioning

  • Why: Enables responsive design across device orientations and sizes with minimal code
  • Consequence: Additional dependency; slight runtime overhead from constraint solving

• Does not provide SwiftUI support or modern async/await patterns
• Does not handle multi-touch gesture recognition or complex gesture chains
• Does not include built-in persistence or state serialization
• Does not provide accessibility features beyond standard UIView defaults
• Not designed for tvOS, watchOS, or macOS deployment

No obvious hidden traps, but note: (1) Must open .xcworkspace (not .xcodeproj) in Example/ to resolve CocoaPods dependencies—opening the raw project will fail to find SnapKit. (2) Minimum iOS deployment target is 8.0 (per xcscheme); can cause issues if you target older iOS versions. (3) No explicit tests in Example/ or visible test bundle—verify custom modifications with manual testing. (4) SnapKit version is pinned in Podfile.lock; updating SnapKit may require constraint rewrite in animation code.

• Core Animation (CABasicAnimation, CAShapeLayer) — The liquid morphing effect is built using CABasicAnimation to animate path shapes and opacity; understanding CA is essential to modify or extend animation behavior
• Bezier Curves & UIBezierPath — The liquid state is rendered via dynamic Bezier paths that morph during state transitions; critical for understanding how the visual effect is generated
• Delegation Pattern (DataSource + Delegate) — The component uses UITableView-style dual-protocol design (dataSource for populating cells, delegate for action callbacks); fundamental to customizing the FAB's behavior
• Material Design Floating Action Button (FAB) — This library implements the Material Design FAB spec with custom liquid animations; understanding Material Design principles helps you use the component correctly
• CADisplayLink & Timing Functions — Smooth liquid animation timing likely uses CADisplayLink or easing functions; knowledge of animation timing helps debug or adjust animation speed/smoothness
• UIView Geometry & Hit Testing — FAB needs to track touch and morphing bounds as it animates; understanding view hierarchy and hit test order prevents input issues

• yoavlt/LiquidLoader — Same author's spinner loader component also in liquid state—shares animation patterns and design language with this FAB library
• Ramotion/roulette — Alternative Material Design FAB implementation for iOS with custom animations; different animation style but same use case
• goktugyil/CozyLoadingActivity — iOS loading animation library using similar Core Animation + Bezier path approach for fluid morphing effects
• material-components/material-components-ios — Official Material Design components for iOS; includes MDCFloatingButton as the canonical alternative with broader ecosystem support
• SnapKit/SnapKit — Dependency used in this project for Auto Layout DSL—understand its syntax if modifying frame/constraint logic in the FAB

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.

Migrate from Travis CI to GitHub Actions and add Swift Package Manager support

The repo uses .travis.yml for CI, which is outdated. GitHub Actions is now the standard for GitHub repos. Additionally, there's no SPM support despite the project being pure Swift. This would modernize the build pipeline and enable Swift Package Manager users to easily integrate the library.

• [ ] Create .github/workflows/swift.yml with matrix testing for iOS 12.0+ versions
• [ ] Add Package.swift manifest at the root with proper targets and dependencies
• [ ] Remove .travis.yml and update README to reference GitHub Actions badge
• [ ] Test SPM integration locally using swift build and verify Xcode can resolve via Package Dependency

Add unit and snapshot tests for LiquidFloatingActionButton animations

The repo has no visible test files despite containing animation-heavy UI code. Snapshot tests would ensure the liquid animation behavior remains consistent across versions, and unit tests would verify gesture handling and state transitions. This is critical for a visual library.

• [ ] Create Example/LiquidFloatingActionButtonTests/ directory with XCTest targets
• [ ] Add snapshot tests using FBSnapshotTestCase to verify rendered liquid states at key animation frames
• [ ] Add unit tests for LiquidFloatingActionButton gesture recognizers and button state transitions
• [ ] Integrate snapshot tests into GitHub Actions workflow to catch visual regressions

Add comprehensive API documentation and inline code comments for animation logic

The LiquidFloatingActionButton likely contains complex animation and geometry calculations (based on the 'liquid state' concept), but there's no visible documentation or inline comments explaining how the liquid morphing works. This creates a barrier for contributors trying to understand or modify the animation behavior.

• [ ] Add DocC documentation comments to the main LiquidFloatingActionButton class and public methods
• [ ] Add inline comments explaining the liquid animation algorithm in the rendering/CALayer code
• [ ] Create Documentation/ANIMATION.md explaining the physics/math behind the liquid state morphing
• [ ] Update README with API reference section linking to generated documentation

• Add unit tests for LiquidFloatingCell and LiquidFloatingActionButton state transitions: Create a Tests/ target in the Xcode project and write XCTest cases covering initialization, dataSource calls, animation completion, and delegate callbacks—currently no test files are visible.
• Document customization examples in README: Add code snippets showing how to create custom LiquidFloatingCell subclasses (e.g., with different colors, sizes, or shapes) and demonstrate using LiquidFloatingActionButtonDelegate to respond to taps—current README only shows basic setup.
• Create SwiftUI wrapper component (LiquidFloatingActionButtonView): Build a SwiftUI struct that wraps the UIKit LiquidFloatingActionButton and exposes dataSource/delegate as SwiftUI bindings—would modernize the library for iOS 13+ without breaking UIKit users.

The LiquidFloatingActionButton project is a UI library with a relatively low security risk profile, as it primarily contains UI component code without backend services, databases, or network requests that would introduce common vulnerabilities like SQLi or XSS. However, the codebase shows signs of age with outdated dependencies (SnapKit version not specified), legacy iOS deployment targets, and potential issues with dependency version management. The primary security concerns are around keeping dependencies updated and ensuring reproducible builds with pinned versions. No hardcoded secrets, injection risks, or Docker/infrastructure misconfigurations were identified in the provided file structure.

• Medium · Outdated Dependency: SnapKit — Example/Podfile, Example/Pods/SnapKit. The codebase includes SnapKit as a dependency via CocoaPods. The file structure shows this is an older project (based on .swift-version and iOS8.0 support). SnapKit versions from several years ago may contain known vulnerabilities or security issues that have been patched in newer releases. Fix: Update SnapKit to the latest stable version. Review the SnapKit changelog for security fixes and update the Podfile and run 'pod update' to resolve dependencies.
• Low · Missing Dependency Version Pinning — Example/Podfile. The Podfile structure suggests dependencies may not be strictly version-pinned. Without explicit version constraints, CocoaPods may resolve to different versions across installations, potentially introducing inconsistent or vulnerable versions. Fix: Pin specific versions or use version ranges for all dependencies in the Podfile (e.g., 'pod "SnapKit", "~> 4.2.0"') to ensure reproducible builds.
• Low · CI Configuration Exposure — .travis.yml. The .travis.yml file is present in the repository. Travis CI configuration files may inadvertently expose sensitive information such as API keys, tokens, or other credentials if not properly managed. Fix: Ensure .travis.yml does not contain any hardcoded secrets. Use encrypted environment variables for sensitive data. Review the file and consider using Travis CI's secret management features.
• Low · Outdated Project Configuration — .swift-version, Example/LiquidFloatingActionButton.xcodeproj. The project targets iOS 8.0 and has a .swift-version file, indicating this is a legacy project. Modern security practices, compiler warnings, and vulnerability fixes in newer Swift/Xcode versions are not being utilized. Fix: Modernize the project by updating the minimum iOS deployment target to a currently supported version (iOS 12.0+), update Swift version, and address any compiler warnings.

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.