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/Orderella/PopupDialog 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

• 14 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Single-maintainer risk — top contributor 82% of recent commits
• ⚠ Non-standard license (Other) — review terms

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

What it runs against: a local clone of Orderella/PopupDialog — 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 Orderella/PopupDialog | Confirms the artifact applies here, not a fork | | 2 | License is still Other | 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 ≤ 853 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Orderella/PopupDialog(\\.git)?\\b" \\
  && ok "origin remote is Orderella/PopupDialog" \\
  || miss "origin remote is not Orderella/PopupDialog (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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 "PopupDialog.podspec" \\
  && ok "PopupDialog.podspec" \\
  || miss "missing critical file: PopupDialog.podspec"
test -f "Package.swift" \\
  && ok "Package.swift" \\
  || miss "missing critical file: Package.swift"
test -f "PopupDialog/PopupDialog.swift" \\
  && ok "PopupDialog/PopupDialog.swift" \\
  || miss "missing critical file: PopupDialog/PopupDialog.swift"
test -f "PopupDialog/PopupDialogViewController.swift" \\
  && ok "PopupDialog/PopupDialogViewController.swift" \\
  || miss "missing critical file: PopupDialog/PopupDialogViewController.swift"
test -f "PopupDialog/Transitions/PopupDialogTransitionAnimator.swift" \\
  && ok "PopupDialog/Transitions/PopupDialogTransitionAnimator.swift" \\
  || miss "missing critical file: PopupDialog/Transitions/PopupDialogTransitionAnimator.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 853 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~823d)"
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/Orderella/PopupDialog"
  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).

PopupDialog is a Swift library that provides a customizable, lightweight alternative to UIAlertController's alert style, enabling developers to display modal dialogs with animated transitions, custom view controllers, and extensive theming options. It replaces the native iOS alert with a more flexible popup that supports images, titles, messages, buttons, and arbitrary custom content. Single-package structure: core PopupDialog source lives in the root (likely Classes/ based on README reference), Example/ contains a Podfile-based demo app with DynamicBlurView and testing dependencies (Nimble, iOSSnapshotTestCase), and .swiftpm/xcode/ enables Swift Package Manager integration. Tests appear to be snapshot-based within Example/Pods.

iOS developers (primarily Swift, Objective-C compatible) building apps that need branded or custom-styled alert dialogs instead of the default UIAlertController appearance. Particularly useful for teams wanting consistent popup styling across their app without complex custom UIViewController management.

Production-ready and actively maintained: supports Swift 5, passes Hound code review (automated linting), has CI via Travis CI for both master and development branches, and bundles snapshot testing via iOSSnapshotTestCase (Example/Pods). The project maintains a CHANGELOG and explicit versioning (1.1.x released), indicating stable API. Last observable activity includes version management via CocoaPods and Carthage, suggesting ongoing use.

Low-risk overall, but minor concerns: single-maintainer appearance (Orderella org), dependency on DynamicBlurView for background blur effects (adds transitive complexity), and reliance on dated CI (Travis CI, .travis.yml rather than GitHub Actions). The library targets iOS 10.0+, which is now 8+ years old—may need modernization for newer iOS features.

Repository appears stable rather than actively evolving: the presence of .github/stale.yml suggests issue management, and CONTRIBUTING.md + CODE_OF_CONDUCT.md indicate open-source governance, but no specific open PRs or development branch activity is visible in the file list. Version 1.1 is current (Swift 5 compatible); V1.0.0 is the prior Swift 4.2 version.

Clone and install via CocoaPods: git clone https://github.com/Orderella/PopupDialog.git && cd Example && pod install && open Example.xcworkspace. Or use Carthage: carthage update --platform iOS then integrate the built framework into your Xcode project.

Daily commands: Navigate to Example/ and run pod install, then open Example.xcworkspace in Xcode and hit Run (⌘R). The example app demonstrates PopupDialog with various themes and configurations. No command-line dev server; this is a UIKit library tested via Xcode simulator.

• PopupDialog.podspec — Pod specification defining the library's name, version, dependencies, and Swift version requirements—essential for understanding integration points.
• Package.swift — Swift Package Manager manifest that declares the library structure, targets, and external dependencies like DynamicBlurView.
• PopupDialog/PopupDialog.swift — Core PopupDialog class implementing the main presentation logic, animations, and public API surface.
• PopupDialog/PopupDialogViewController.swift — UIViewController subclass managing the popup's view hierarchy, layout, and lifecycle during presentation/dismissal.
• PopupDialog/Transitions/PopupDialogTransitionAnimator.swift — Custom transition animator controlling modal presentation animations and timing—critical for visual behavior.
• Example/Podfile — Example project dependencies showing how to integrate PopupDialog and its optional dependencies like DynamicBlurView.

• PopupDialog (UIViewController, Notifications) — Public factory and configuration holder; orchestrates show()/dismiss() lifecycle and holds button callbacks
  • Failure mode: If initialization fails (invalid appearance), dialog silently fails to present; no error thrown
• PopupDialogViewController (UIViewController, UIStackView, Auto Layout) — Modal view hierarchy manager; owns the dialog container, button stack, and content layout
  • Failure mode: Layout ambiguity or missing constraints can cause runtime exceptions; safe area may clip content on notched devices
• PopupDialogTransitionAnimator (CABasicAnimation, UIViewControllerAnimatedTransitioning) — Drives enter/exit animations; interpolates scale, opacity, and position over 0.3–0.5 seconds
  • Failure mode: If animation duration exceeds system timeout (~5s), iOS cancels transition and leaves view in intermediate state

Add a New Custom Dialog Style

1. Create a new appearance preset by extending or subclassing Appearance.swift with custom colors, fonts, and corner radius (PopupDialog/Appearance.swift)
2. Apply the preset when instantiating PopupDialog: PopupDialog(title: ..., appearance: myAppearance) (PopupDialog/PopupDialog.swift)
3. Test the style by creating a dialog in the Example app's ViewController or adding a new example case (Example/PopupDialog_Example/ViewController.swift)

Add a Custom Button Type

1. Create a new button configuration object or extend DialogButton.swift with additional styling properties (PopupDialog/DialogButton.swift)
2. Register the button layout in PopupDialogViewController.swift during view setup or addButtons() method (PopupDialog/PopupDialogViewController.swift)
3. Add button action handler when creating the dialog: let button = DialogButton(title: ..., didTap: { ... }) (PopupDialog/PopupDialog.swift)

Implement a New Transition Animation

1. Create a new animator class conforming to UIViewControllerAnimatedTransitioning in PopupDialog/Transitions/ directory (PopupDialog/Transitions/PopupDialogTransitionAnimator.swift)
2. Override animateTransition(using:) with custom CABasicAnimation or UIView.animate() calls for enter/exit effects (PopupDialog/Transitions/PopupDialogTransitionAnimator.swift)
3. Register the animator in PopupDialogViewController.transitioningDelegate or as part of the presentation controller setup (PopupDialog/PopupDialogViewController.swift)

Add Optional Blur Backdrop Support

1. Ensure DynamicBlurView is installed as a dependency (already in Podfile and Package.swift) (Example/Podfile)
2. In Appearance.swift, add a blur style option (blurStyle, isBlurEnabled) and expose it via public properties (PopupDialog/Appearance.swift)
3. Update PresentationController.swift to conditionally render a DynamicBlurView overlay when blur is enabled (PopupDialog/PresentationController.swift)

• UIViewController + Custom Transitions — Provides deep integration with iOS native modal system, respecting safe areas, orientations, and accessibility without reinventing the wheel
• Swift 5 + SPM/CocoaPods — Modern language version supports async/concurrency patterns; dual package system maximizes adoption across legacy and modern projects
• DynamicBlurView (optional dependency) — Efficient blur effects on backdrop without replicating complex image processing; user can opt-in if performance is acceptable
• CABasicAnimation + UIView.animate() — Hardware-accelerated animations ensure smooth 60fps transitions even on lower-end devices

• Optional blur dependency rather than built-in

  • Why: Blur effects are expensive (CPU/GPU); making them optional reduces binary size and memory footprint for users who don't need them
  • Consequence: Users wanting blur must explicitly import DynamicBlurView; adds one more dependency to manage

• Single PopupDialog class vs. builder pattern

  • Why: Simpler API surface with fewer objects; constructor captures all configuration upfront
  • Consequence: Cannot progressively build dialogs; must know all properties before instantiation

• UIViewController-based presentation over view composition

  • Why: Inherits all UIViewController lifecycle benefits (rotation, keyboard avoidance, gesture exclusion zones)
  • Consequence: Heavier memory footprint than a pure UIView; less suitable for high-frequency reuse scenarios

• Interactive dismissal via gesture recognizers

  • Why: Matches iOS design patterns (swipe to dismiss sheets); users expect this behavior
  • Consequence: Must carefully manage gesture conflict with dialog content scrollviews; adds state complexity

• Does not support landscape-only or portrait-only constraints—respects device orientation fully
• Does not provide bottom-sheet or over-the-top presentation modes—alert/modal centered style only
• Does not handle keyboard presentation/dismissal automatically—parent app manages input views
• Does not include built-in form validation or data binding—buttons are callback-only

(1) DynamicBlurView dependency: the blur effect in the background requires this separate pod; if you want PopupDialog without blur, you may need to fork or configure appearance differently. (2) iOS 10.0+ minimum: App Store no longer accepts apps targeting iOS 10 (minimum is now 12.0+), so deployments targeting older iOS may face App Store rejection despite the library supporting it. (3) Snapshot testing brittleness: iOSSnapshotTestCase snapshots are pixel-perfect and break on simulator resolution or font changes; be aware when running tests on different machines. (4) Objective-C bridging: marked as Objective-C compatible but may require careful @objc annotations on API entry points; not explicitly documented. (5) TraitCollection changes (dark mode, dynamic type): library supports theming but dark mode appearance changes at runtime may not auto-update all PopupDialog instances.

• Modal view controller presentation with custom transitions — PopupDialog replaces UIAlertController by wrapping a custom view controller and applying UIViewControllerTransitioningDelegate animations; understanding iOS presentation controllers and CABasicAnimation timing is essential to modify popup behavior or debug animation issues

• SwiftEntryKit/SwiftEntryKit — Similar popup/alert overlay library with more animation presets and entry point management; direct competitor solving the same UIAlertController replacement problem
• material-components/material-components-ios — Google Material Design components for iOS, including dialog implementations; alternative approach using Material specs instead of native iOS aesthetic
• radianlab/StarWars.iOS — Example app using PopupDialog in practice; demonstrates real-world integration patterns and UI customization use cases
• Orderella/PopupDialog-DemoSwift5 — Likely the official demo/example repo from the same maintainer, focused on Swift 5 usage patterns and advanced theming
• jonkykong/SideMenu — Complementary navigation UI library from the iOS community; often paired with PopupDialog for complete custom UI replacement of native components

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 with Swift testing workflow

The repo currently uses .travis.yml for CI/CD, but GitHub Actions is now the standard for GitHub-hosted projects. This would modernize the CI setup, provide faster feedback, and leverage native GitHub integration. The repo has Example/ with Podfile and test dependencies (Nimble, iOSSnapshotTestCase) that should be tested on each commit.

• [ ] Create .github/workflows/swift-tests.yml with matrix testing for iOS 14+ and latest Swift versions
• [ ] Configure workflow to run pod install in Example/ and execute unit/snapshot tests using xcodebuild
• [ ] Add workflow step to verify SwiftLint compliance (Example/.swiftlint.yml exists)
• [ ] Update README.md badges to point to GitHub Actions instead of Travis CI
• [ ] Remove or archive .travis.yml with a deprecation note

Add comprehensive snapshot tests for PopupDialog UI rendering

The repo includes iOSSnapshotTestCase dependency in Example/Podfile.lock, indicating snapshot testing is already a dependency, but no snapshot test files are visible in the file structure. Given the visual nature of PopupDialog (with Assets/ containing GIFs and PNGs of different dialog states), snapshot tests would validate UI consistency across iOS versions and prevent visual regressions.

• [ ] Create Example/PopupDialogTests/SnapshotTests.swift with test cases for default, dark mode, and custom styled dialogs
• [ ] Test snapshot rendering with various content sizes (short/long text, with/without images)
• [ ] Add test cases for all dialog button configurations (single, multiple buttons)
• [ ] Generate and commit reference snapshots to the repository
• [ ] Document snapshot update procedure in CONTRIBUTING.md

Modernize Package.swift and create SPM-only CI workflow

The repo has .swiftpm/xcode/ structure indicating Swift Package Manager support, but the file structure shows Cartfile, Podfile, and .travis.yml suggesting the primary distribution is via CocoaPods/Carthage. Adding explicit SPM product definitions and a dedicated CI workflow would make PopupDialog easier to adopt for modern Swift projects that prefer SPM over CocoaPods.

• [ ] Review and update Package.swift to include explicit product definitions and proper dependency declarations
• [ ] Create .github/workflows/spm-build.yml to test building with swift build and swift test on macOS
• [ ] Add SPM installation instructions to README.md with copy-paste ready code snippet
• [ ] Ensure Example/ can be built via SPM (create Example/Package.swift if needed) or document SPM-only usage
• [ ] Test against minimum Swift version specified in Package.swift

• Add unit tests for PopupDialog appearance customization (fonts, colors, corner radius, shadow) under Example/Tests/; currently only snapshot tests exist, leaving customization logic untested for edge cases like nil values or extreme sizes
• Document the DynamicBlurView dependency and blur configuration in README.md with code example; README mentions blur is themeable but doesn't show how to disable blur or replace DynamicBlurView, causing friction for users who don't want background blur
• Add SPM dependency declaration example to README; .swiftpm/ folder exists but README only covers CocoaPods and Carthage, leaving SPM users without clear install instructions or the Package.swift manifest in the repo root

The PopupDialog repository shows a moderate security posture. Primary concerns include outdated dependency management practices without automated vulnerability scanning, vendored dependencies that may contain unpatched vulnerabilities, and lack of explicit security policies. The codebase itself appears to be a UI library with minimal injection or data handling risks. Recommendations focus on modernizing dependency management, implementing automated security scanning, and establishing clear security policies. No hardcoded credentials or obvious injection vulnerabilities were detected in the provided file structure.

• Medium · Dependency Management Using Outdated Package Managers — Cartfile, Cartfile.resolved, Example/Podfile, Example/Pods/. The project uses Carthage (Cartfile, Cartfile.resolved) and CocoaPods (Podfile, Podfile.lock) for dependency management. The Cartfile and Podfile are not version-locked in a way that prevents transitive dependency updates. Additionally, the Example/Pods directory contains vendored dependencies that may not be regularly audited or updated, potentially including vulnerable versions of DynamicBlurView, Nimble, and CwlCatchException. Fix: 1) Regularly audit and update all dependencies using pod outdated and carthage outdated. 2) Use exact version pinning in Podfile and Cartfile rather than loose constraints. 3) Implement automated dependency vulnerability scanning (e.g., CocoaPods-security, OWASP Dependency-Check). 4) Consider removing vendored pods from version control and using package managers instead.
• Medium · Potential Outdated Swift Version — .swiftpm/xcode/package.xcworkspace, README.md. The README indicates Swift 5 compatibility (general version badge), but the package.xcworkspace suggests Swift Package Manager support. No explicit Swift version constraints or minimum deployment target are visible in the provided files, which could lead to compatibility issues or missing security patches in older Swift runtimes. Fix: 1) Explicitly define minimum Swift version in Package.swift (e.g., swiftLanguageVersions: [.v5]). 2) Specify minimum iOS deployment target (recommend iOS 12.0 or higher). 3) Document minimum Swift compiler version required.
• Low · Exposed Test and Example Files in Repository — Example/ directory, Example/Pods/. The Example/ directory and test dependencies (Nimble, iOSSnapshotTestCase) are included in the repository. While not a direct security vulnerability, exposing test configurations and example implementations increases the attack surface by providing detailed insights into application structure and potential weaknesses. Fix: 1) Consider moving Example to a separate repository or branch. 2) Ensure no hardcoded credentials or API keys exist in example code or test files. 3) Implement pre-commit hooks to prevent accidental credential commits.
• Low · Missing Security Configuration Files — Repository root. While .hound.yml exists for code style checking, there is no evidence of security-focused configuration files such as SECURITY.md (security policy), security scanning configuration (e.g., .sonarcloud.yml, .dependabot.yml), or vulnerability disclosure policy. Fix: 1) Create SECURITY.md file documenting security policies and vulnerability reporting procedures. 2) Add .dependabot.yml or GitHub Security Advisories configuration for automated dependency monitoring. 3) Enable GitHub's branch protection rules requiring security checks before merging.
• Low · Travis CI Configuration Potentially Outdated — .travis.yml. The .travis.yml file references an older CI/CD system. Travis CI has transitioned to travis-ci.com, and the old .org service may lack current security updates and features. Fix: 1) Migrate to GitHub Actions (native to GitHub) or update to current Travis CI infrastructure. 2) Ensure CI/CD pipeline includes security scanning steps (SAST, dependency checks). 3) Use GitHub Actions secrets management for sensitive credentials.

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.