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/EFPrefix/EFQRCode 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

• Last commit 2mo ago
• 5 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 92% 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 EFPrefix/EFQRCode repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/EFPrefix/EFQRCode.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "EFPrefix/EFQRCode(\\.git)?\\b" \\
  && ok "origin remote is EFPrefix/EFQRCode" \\
  || miss "origin remote is not EFPrefix/EFQRCode (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 "EFQRCode.podspec" \\
  && ok "EFQRCode.podspec" \\
  || miss "missing critical file: EFQRCode.podspec"
test -f "EFQRCode.xcodeproj/project.pbxproj" \\
  && ok "EFQRCode.xcodeproj/project.pbxproj" \\
  || miss "missing critical file: EFQRCode.xcodeproj/project.pbxproj"
test -f ".swift-version" \\
  && ok ".swift-version" \\
  || miss "missing critical file: .swift-version"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
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 98 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~68d)"
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/EFPrefix/EFQRCode"
  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).

EFQRCode is a pure-Swift library for generating and recognizing QR codes with advanced styling capabilities (watermarks, icons, custom patterns) built on CoreGraphics, CoreImage, and ImageIO. It provides a high-level API for creating stylized QR codes across iOS, macOS, watchOS, tvOS, and visionOS without external dependencies beyond Apple frameworks. Flat structure: Sources/ contains the core QR generation and recognition logic; Examples/ contains runnable demo apps per-platform (Examples/iOS/Generator/, Examples/macOS, etc.) showing different styling approaches; build config via EFQRCode.podspec, Cartfile, and xcodeproj with platform-specific schemes (EFQRCode iOS.xcscheme, macOS.xcscheme, tvOS.xcscheme, watchOS.xcscheme).

iOS/macOS/watchOS/tvOS/visionOS developers who need to generate branded or visually customized QR codes (not just plain ISO-standard ones) and recognize QR codes from images, inspired by desktop QR tools like qrcode and react-qrbtf.

Production-ready and actively maintained. The project has multi-platform support (5 OSes), is distributed via CocoaPods/Carthage/SPM, has demo apps on App Store and Mac App Store, includes comprehensive CI workflows (.github/workflows), and demonstrates rich example implementations in Examples/iOS/Generator/. Commit recency and issue handling suggest ongoing maintenance.

Low risk for a mature library: single-maintainer codebase (EFPrefix organization), but no breaking changes are visible in CHANGELOG.md structure and multi-version support is demonstrated via .swift-version pinning. Dependency footprint is minimal (only Apple system frameworks). Main risk is watch/visionOS platform support breadth may have limited real-world testing in niche environments.

The repository appears actively maintained with CI workflows for CocoaPods linting (cocoapods-lint.yml), documentation generation (docs.yml, documentation.yml), and standard CI (ci.yml). Example controllers show extensive feature coverage: BasicGeneratorController, BubbleGeneratorController, D25GeneratorController, DSJGeneratorController, ImageFillGeneratorController, etc., suggesting ongoing feature refinement and testing.

git clone https://github.com/EFPrefix/EFQRCode.git && cd EFQRCode && open EFQRCode.xcworkspace (use .xcworkspace not .xcodeproj to avoid dependency resolution issues). For SPM: add to Package.swift via .package(url: "https://github.com/EFPrefix/EFQRCode.git", from: "x.x.x").

Daily commands: Open EFQRCode.xcworkspace, select desired scheme (EFQRCode iOS, EFQRCode macOS, etc.), and run (⌘R). For command-line testing: xcodebuild -workspace EFQRCode.xcworkspace -scheme 'EFQRCode iOS' -destination 'platform=iOS Simulator,name=iPhone 14' build.

• EFQRCode.podspec — Pod specification defining the library's version, dependencies, and platform support—essential for understanding release versions and Swift compatibility requirements.
• EFQRCode.xcodeproj/project.pbxproj — Xcode project configuration for all four platform targets (iOS, macOS, watchOS, tvOS); contributor must understand multi-platform build setup.
• .swift-version — Specifies minimum Swift version required for the entire library; critical for development environment setup.
• .github/workflows/ci.yml — CI/CD pipeline configuration defining build and test matrix across platforms; shows automated quality gates all PRs must pass.
• CHANGELOG.md — Historical record of API changes, features, and breaking changes; essential reference for understanding library evolution and backwards compatibility.
• Examples/iOS/Generator — Example implementations demonstrating all major QR code generation features; primary reference for API usage patterns.

• QR Code Generator Core (Pure Swift, CoreGraphics for rendering) — Encodes input data into QR matrix, applies error correction, and handles stylization parameters
  • Failure mode: Fails silently if data is too large for QR version; generation returns nil for invalid inputs
• Image Rendering Engine — Converts QR matrix and styling options into CGImage or platform-native image format

Add a new QR code generation style variant

1. Create a new generator controller file in Examples/iOS/Generator/ following the naming pattern *GeneratorController.swift (Examples/iOS/Generator/BasicGeneratorController.swift)
2. Implement generation logic using the EFQRCode core API with custom styling parameters (Examples/iOS/Generator/BubbleGeneratorController.swift)
3. Add the new controller to the example app's navigation structure in MoreViewController.swift (Examples/iOS/MoreViewController.controller)
4. Test across all platform schemes (iOS, macOS, watchOS, tvOS) using the respective .xcscheme files (EFQRCode.xcodeproj/xcshareddata/xcschemes/EFQRCode iOS.xcscheme)

Support a new Apple platform (e.g., visionOS)

1. Add new platform target scheme in Xcode project at EFQRCode.xcodeproj/xcshareddata/xcschemes/ (EFQRCode.xcodeproj/xcshareddata/xcschemes/EFQRCode iOS.xcscheme)
2. Update EFQRCode.podspec to declare the new platform in the spec metadata (EFQRCode.podspec)
3. Create platform-specific build scheme following existing pattern (iOS, macOS, watchOS, tvOS) (EFQRCode.xcodeproj/project.pbxproj)
4. Add new platform matrix to CI workflow to validate builds on all supported platforms (.github/workflows/ci.yml)

Add QR code recognition feature example

1. Reference the existing QR recognition example implementation (Examples/iOS/RecognizerController.swift)
2. Create a new variant file following the pattern in Examples/iOS/Generator/ directory (Examples/iOS/Generator/BasicGeneratorController.swift)
3. Implement recognition logic using EFQRCode's built-in recognition API (Examples/iOS/RecognizerController.swift)
4. Update app navigation and example list to expose the new recognition example (Examples/iOS/MoreViewController.swift)

Publish a new library release

1. Update version and release notes in CHANGELOG.md with all changes since last release (CHANGELOG.md)
2. Update version number in EFQRCode.podspec to match semantic versioning (EFQRCode.podspec)
3. Verify CI pipeline passes for all platforms by reviewing automated checks (.github/workflows/ci.yml)
4. CocoaPods lint validation will automatically run via cocoapods-lint.yml workflow (.github/workflows/cocoapods-lint.yml)

• Pure Swift implementation — Cross-platform compatibility across iOS, macOS, watchOS, tvOS, and visionOS without Objective-C dependencies or external C libraries
• CocoaPods, Carthage, SPM support — Flexibility for developers to integrate using their preferred package manager; broad ecosystem adoption
• Multi-platform Xcode schemes — Single codebase compiled to all Apple platforms with platform-specific optimizations; simplified maintenance
• Example app-based documentation — Runnable examples are more discoverable and maintainable than static docs; developers can see actual usage patterns

• Pure Swift with no external C library dependencies

  • Why: Ensures pure Swift compilation, easier distribution, and no native library management complexity
  • Consequence: May sacrifice micro-optimizations available in C implementations; all QR encoding/rendering logic implemented in Swift

• Single codebase for 5 Apple platforms

  • Why: Reduces code duplication and maintenance burden; easier to keep feature parity across platforms
  • Consequence: Cannot leverage platform-specific APIs for optimization; must use lowest-common-denominator APIs

• Example-driven API design

  • Why: Provides clear, discoverable usage patterns and serves as living documentation
  • Consequence: Examples must be kept in sync with API changes; larger repository size with example assets

• Support for watermark/icon overlay features

  • Why: Addresses real-world use case of branded QR codes; differentiates from basic QR libraries
  • Consequence: Adds rendering complexity and potential performance impact for overlay operations

• Real-time camera streaming for QR recognition (static image recognition only)
• Custom QR version encoding (uses standard QR specification)
• Server-side rendering or cloud API (client-side Swift library only)
• Non-Apple platform support (Apple platforms exclusively)

1. Must use EFQRCode.xcworkspace, not .xcodeproj directly, for proper dependency resolution. 2. Platform-specific schemes required: 'EFQRCode iOS' vs 'EFQRCode macOS' etc.—selecting wrong scheme causes build failures. 3. visionOS support may be recent (post-WWDC 2023); some example controllers in Examples/iOS may not compile for visionOS without #available guards. 4. ImageIO integration for GIF/animated output likely has performance characteristics undocumented—test with large images before production use.

• QR Code Error Correction Levels (L, M, Q, H) — EFQRCode allows selecting error correction level when generating; higher levels allow more watermark/styling without data loss, critical for understanding tradeoffs between visual customization and scannability
• CoreGraphics Drawing Context & CGImage — EFQRCode's entire rendering pipeline uses CGContext and CGImage for pattern drawing; understanding coordinate systems, color spaces, and bitmap contexts is essential for customizing or debugging visual output
• CoreImage CIFilter Pipeline — QR recognition uses CIFilter-based image processing (likely CIDetector or similar); understanding filter chaining and performance characteristics is needed for optimizing recognition on constrained devices (watch, tvOS)
• Platform-Conditional Compilation (#if os()) — EFQRCode supports 5 OSes with different APIs (UIImage vs NSImage, SwiftUI vs AppKit); mastering #if os(iOS), #if os(watchOS), etc. is mandatory for multiplatform Swift development
• Builder Pattern & Fluent API Design — EFQRCode likely uses chainable configuration methods (e.g., qrCode.content(...).size(...).style(...)); this pattern is idiomatic in Swift for readable, flexible APIs without massive initializers
• SPM Package Resolution & Version Pinning — Library is distributed via SPM (Package.resolved visible); understanding semantic versioning, dependency graphs, and .swift-version pinning prevents integration headaches in downstream projects
• Cross-Platform Testing & CI/CD (GitHub Actions) — Project has .github/workflows/ for CocoaPods linting, doc generation, and platform-specific CI; learning how to test one codebase across 5 OSes is non-trivial and valuable for maintaining quality at scale

• sylnsfar/qrcode — Python QR library that inspired EFQRCode's stylization features (watermark, icon, pattern options)
• CPunisher/react-qrbtf — React QR tool also cited as inspiration; demonstrates same design patterns (modular pattern types, drag-and-drop styling) in different ecosystem
• yeahdongcn/RSBarcodes_Swift — Alternative Swift barcode/QR library; competitor with different API surface and feature set
• EFPrefix/EFMarkdown — Sibling library from same org (EFPrefix); likely shares build/test infrastructure and coding conventions worth studying
• apple/swift-coreimage-utilities — Apple's own CoreImage helper library; relevant for understanding platform-native image processing patterns used in EFQRCode's recognition module

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 comprehensive unit tests for EFQRCode core generation and recognition

The repo has multiple example controllers (BasicGeneratorController, BubbleGeneratorController, ImageGeneratorController, etc.) but no visible test suite in the file structure. Given the library supports 5 platforms (iOS, macOS, watchOS, tvOS, visionOS) with different QR code styles, adding unit tests would ensure cross-platform reliability and catch regressions when adding new features.

• [ ] Create Tests/ directory structure mirroring the source layout
• [ ] Add unit tests for core EFQRCode generation with various parameters (size, content length, error correction levels)
• [ ] Add tests for each style variant found in Examples/ (Bubble, D25, DSJ, Line, RandomRectangle, etc.)
• [ ] Add tests for EFQRCode recognition/scanning functionality
• [ ] Integrate tests into the existing ci.yml workflow to run on all supported platforms

Add GitHub Actions workflow for automatic API documentation generation and deployment

The repo has .jazzy.yaml configuration for documentation generation and a docs.yml workflow, but the documentation.yml workflow appears redundant. Additionally, there's no clear automated deployment of generated docs to GitHub Pages. This would improve discoverability and API reference accessibility for new users.

• [ ] Review and consolidate docs.yml and documentation.yml workflows in .github/workflows/
• [ ] Configure the workflow to generate docs using .jazzy.yaml and deploy to GitHub Pages branch
• [ ] Ensure the workflow runs on version tags and main branch pushes
• [ ] Add documentation badge to README.md linking to the deployed docs site
• [ ] Verify generated docs cover all public APIs across the 5 platform variants

Create platform-specific example documentation for each supported platform

The Examples/ folder has iOS examples extensively documented, but macOS, watchOS, and tvOS examples are missing from the visible file structure. This creates a barrier for developers targeting those platforms. Adding platform-specific README files and example projects would improve adoption.

• [ ] Create Examples/macOS/ directory with a basic macOS example application (similar structure to iOS examples)
• [ ] Create Examples/watchOS/ directory with a watchOS example application
• [ ] Create Examples/tvOS/ directory with a tvOS example application
• [ ] Add platform-specific setup guides in documentation for each platform
• [ ] Update Examples/Shared/ utilities if needed to support cross-platform code sharing
• [ ] Update main README.md with links to platform-specific examples

• Add missing unit tests for Examples/iOS/Generator/DSJGeneratorController.swift and Examples/iOS/Generator/D25GeneratorController.swift (likely no corresponding test files given test structure not in top 60 files), verifying pattern correctness and edge cases (empty QR, max data, etc.)
• Enhance documentation in .jazzy.yaml and add code comments to Examples/Shared/PointStyle.swift explaining the custom point rendering API used across all styling patterns—currently opaque to new contributors
• Add watchOS-specific example controller in Examples/ (only iOS examples detailed) demonstrating QR generation at small form factors and performance constraints; currently unclear if WKInterfaceImage or SwiftUI support exists

The EFQRCode repository demonstrates good security hygiene with proper use of modern Swift package management, CI/CD automation, and community governance files. However, there are opportunities for improvement in dependency management oversight, explicit security policies, and input validation documentation. No critical vulnerabilities or hardcoded secrets were identified from the file structure analysis. The project maintains standard security practices for a Swift-based library but should strengthen its security disclosure process and dependency auditing mechanisms.

• Medium · Missing dependency version pinning in Package.resolved — EFQRCode.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved, EFQRCode.xcworkspace/xcshareddata/swiftpm/Package.resolved. The repository uses Swift Package Manager with Package.resolved files, but without access to the actual dependency versions and sources, there's a risk of transitive dependency vulnerabilities. No explicit security audit trail is visible for dependency management. Fix: Regularly audit dependencies using swift package show-dependencies and swift package update. Consider implementing automated dependency scanning in CI/CD pipelines (e.g., using tools like Dependabot or Snyk).
• Low · No explicit security policy or disclosure process — .github/. While the repository has CONTRIBUTING.md and CODE_OF_CONDUCT.md files, there is no visible SECURITY.md or security policy file for responsible vulnerability disclosure. Fix: Create a .github/SECURITY.md file with clear instructions for reporting security vulnerabilities responsibly, including contact information and expected response times.
• Low · CI/CD configuration visibility — .github/workflows/. GitHub Actions workflows are configured (.github/workflows/) but the actual workflow content cannot be verified from the file structure alone. There could be potential issues with secret handling, artifact management, or insecure build practices. Fix: Review all CI/CD workflows for: 1) Proper secret management (no hardcoded credentials), 2) Least privilege permissions, 3) Verification of build artifacts, 4) Code signing practices for releases.
• Low · No apparent input validation documentation for QR code generation — Source code not provided for detailed analysis. As a QR code library that processes external data, there's no visible documentation about input validation, maximum payload sizes, or protections against malicious QR code content. Fix: Implement and document: 1) Input size limits, 2) Data type validation, 3) Protection against extremely complex QR codes, 4) Security guidelines for users processing untrusted QR codes.

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.