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

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "hackiftekhar/IQKeyboardManager(\\.git)?\\b" \\
  && ok "origin remote is hackiftekhar/IQKeyboardManager" \\
  || miss "origin remote is not hackiftekhar/IQKeyboardManager (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/IQKeyboardManagerSwiftExample/AppDelegate.swift" \\
  && ok "Example/IQKeyboardManagerSwiftExample/AppDelegate.swift" \\
  || miss "missing critical file: Example/IQKeyboardManagerSwiftExample/AppDelegate.swift"
test -f "Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/Main.storyboard" \\
  && ok "Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/Main.storyboard" \\
  || miss "missing critical file: Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/Main.storyboard"
test -f "Example/IQKeyboardManagerSwiftExample/Cell/TextFieldTableViewCell.swift" \\
  && ok "Example/IQKeyboardManagerSwiftExample/Cell/TextFieldTableViewCell.swift" \\
  || miss "missing critical file: Example/IQKeyboardManagerSwiftExample/Cell/TextFieldTableViewCell.swift"
test -f "Documentation/MIGRATION GUIDE 8.0 TO 7.0.md" \\
  && ok "Documentation/MIGRATION GUIDE 8.0 TO 7.0.md" \\
  || miss "missing critical file: Documentation/MIGRATION GUIDE 8.0 TO 7.0.md"
test -f "Example/IQKeyboardManagerSwiftExample/Extension/UITableView+Extension.swift" \\
  && ok "Example/IQKeyboardManagerSwiftExample/Extension/UITableView+Extension.swift" \\
  || miss "missing critical file: Example/IQKeyboardManagerSwiftExample/Extension/UITableView+Extension.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 105 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~75d)"
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/hackiftekhar/IQKeyboardManager"
  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).

IQKeyboardManager is a codeless drop-in library for iOS that automatically prevents the keyboard from covering UITextField/UITextView elements by adjusting view hierarchy and scroll positions in real-time. It requires zero configuration—just add the framework to your project and it handles keyboard avoidance across UIScrollView, UITableView, and UICollectionView without subclassing or manual intervention. Single-package library with modular subspecs: a Core manager (always included) handles keyboard avoidance logic, with optional subspecs for IQKeyboardToolbarManager (Previous/Next/Done buttons in Example/IQKeyboardManagerSwiftExample/), IQKeyboardReturnManager, Appearance configuration, and IQTextView placeholder support. The Example folder contains a full runnable iOS app demonstrating all features.

iOS developers (Swift and Objective-C) building production apps who want to eliminate keyboard occlusion bugs without writing boilerplate code or manually managing scroll view insets, gesture recognizers, and view repositioning logic.

Highly mature and production-ready. The repo shows 8 major migration guides (v1.0→v8.0), indicating years of active development and API stability efforts. It has a Travis CI pipeline, CocoaPods distribution, and a comprehensive example app. However, the last visible commit details are not provided in the data, so recency cannot be confirmed from the snapshot.

Low risk overall. The codebase is primarily Swift (304KB) with minimal dependencies suggested by the modular subspecs architecture. Single-maintainer repos pose coordination risk, but the long migration guide history and established distribution channels suggest sustainable maintenance. Breaking changes are documented in Documentation/MIGRATION GUIDE files, which is a good sign of intentional versioning.

The repo is in active maintenance phase with focus on Swift modernization and modular architecture. Recent changes include subspecs refactoring to allow selective feature inclusion (Core, Appearance, IQKeyboardReturnManager, etc.), GitHub workflow setup for CI/CD, and migration guides for each major version bump.

git clone https://github.com/hackiftekhar/IQKeyboardManager.git
cd IQKeyboardManager
cd Example
pod install
open IQKeyboardManagerSwiftExample.xcworkspace

Daily commands:

cd Example
pod install
open IQKeyboardManagerSwiftExample.xcworkspace
# Then Cmd+R in Xcode to build and run on simulator or device

• Example/IQKeyboardManagerSwiftExample/AppDelegate.swift — Application entry point demonstrating IQKeyboardManager initialization and setup across the entire app.
• Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/Main.storyboard — Core UI layout defining the primary navigation and UITextField/UITextView placements that trigger keyboard management.
• Example/IQKeyboardManagerSwiftExample/Cell/TextFieldTableViewCell.swift — Demonstrates how UITextField is integrated in reusable cells and how IQKeyboardManager handles scrolling context.
• Documentation/MIGRATION GUIDE 8.0 TO 7.0.md — Latest migration guide explaining major API changes and behavioral differences contributors must understand.
• Example/IQKeyboardManagerSwiftExample/Extension/UITableView+Extension.swift — Extends UITableView to support keyboard-aware scrolling and positioning—core pattern used throughout.
• Example/.swiftlint.yml — Defines code style rules enforced across the example project; necessary for PR compliance.
• .github/pull_request_template.md — Contribution guidelines and PR structure expected for all pull requests.

Add a New Screen with Text Input

1. Create a new storyboard file (e.g., NewFeature.storyboard) in Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/ (Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/Main.storyboard)
2. Define a UIViewController with UITextField/UITextView and embed in a UIScrollView or UITableView (Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/General.storyboard)
3. Create a corresponding Swift ViewController file following the pattern in the project (Example/IQKeyboardManagerSwiftExample/AppDelegate.swift)
4. Register the view controller in AppDelegate.swift or navigation if using custom routing (Example/IQKeyboardManagerSwiftExample/AppDelegate.swift)

Add a New Configurable Setting

1. Add a new SwitchTableViewCell or OptionTableViewCell row to Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/Settings.storyboard (Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/Settings.storyboard)
2. Create a new cell subclass following SwitchTableViewCell.swift pattern to bind the setting (Example/IQKeyboardManagerSwiftExample/Cell/SwitchTableViewCell.swift)
3. Update AppDelegate.swift to apply the setting at initialization time (Example/IQKeyboardManagerSwiftExample/AppDelegate.swift)
4. Add corresponding test cases in Storyboard/Base.lproj/TestCases.storyboard (Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/TestCases.storyboard)

Add Support for a New Localization

1. Create a new .lproj folder (e.g., fr.lproj) in Example/IQKeyboardManagerSwiftExample/Resources/ (Example/IQKeyboardManagerSwiftExample/Resources/ar.lproj/InfoPlist.strings)
2. Add localized InfoPlist.strings file following the pattern in ar.lproj (Example/IQKeyboardManagerSwiftExample/Resources/ar.lproj/InfoPlist.strings)
3. Add corresponding .strings files for each storyboard in the new .lproj folder (Example/IQKeyboardManagerSwiftExample/Storyboard/ar.lproj/General.strings)

Add a New Reusable Cell Type

1. Create a new Swift file in Example/IQKeyboardManagerSwiftExample/Cell/ following naming convention (e.g., CustomInputTableViewCell.swift) (Example/IQKeyboardManagerSwiftExample/Cell/TextFieldTableViewCell.swift)
2. Subclass UITableViewCell and add UITextField/UITextView outlets (Example/IQKeyboardManagerSwiftExample/Cell/TextFieldTableViewCell.swift)
3. Add the cell prototype to the target storyboard and set the custom class and identifier (Example/IQKeyboardManagerSwiftExample/Storyboard/Base.lproj/General.storyboard)
4. Register and use the cell in the appropriate table view controller (Example/IQKeyboardManagerSwiftExample/Extension/UITableView+Extension.swift)

• Swift — Modern, type-safe iOS development language; primary language for the IQKeyboardManagerSwift variant.
• UIKit — Native iOS framework required for UITextField, UITextView, UIScrollView, and keyboard event handling.
• Storyboards — Visual interface builder for rapid prototyping and layout definition without code-first UI.
• Cocoa Touch / Foundation — Core iOS frameworks providing keyboard notifications, view hierarchies, and system integration.

• Codeless, drop-in initialization—no explicit setup required

  • Why: Reduces friction for developers and prevents common integration mistakes.
  • Consequence: Library uses class initialization and swizzling, which reduces visibility and can conflict with other libraries doing similar runtime manipulation.

• Automatic UIScrollView adjustment without manual frame management

  • Why: Provides universal keyboard handling across all UITextField/UITextView instances.
  • Consequence: May adjust scroll frames unexpectedly if custom keyboard handling is already in place; requires careful version migration.

• Support for both Storyboard and programmatic UI

  • Why: Accommodates diverse development styles and legacy codebases.
  • Consequence: Adds complexity to event handling and view detection logic to support both patterns.

• ---

  • Why: undefined
  • Consequence: undefined

Subspec selection: If using CocoaPods with subspecs (e.g., pod 'IQKeyboardManagerSwift/IQKeyboardToolbarManager'), only that subspec's features are available—omitting Core would break basic functionality. SwiftLint config: Example/.swiftlint.yml enforces style rules; PRs may fail linting if not followed. Bridging header: Example/IQKeyboardManagerSwiftExample/Resources/IQKeyboardManger-Swift-Bridging-Header.h exists, suggesting mixed Swift/Objective-C code—be careful with symbol conflicts. Multiple Xcode schemes: Three schemes exist (.xcscheme files); ensure you're building the right target (IQKeyboardManagerSwift vs. Example vs. Extension).

• UIKeyboardWillShow / UIKeyboardWillHide Notifications — IQKeyboardManager's core mechanic: it listens for these UIKit notifications to compute keyboard frame and automatically adjust view hierarchy and contentInset values in real-time
• UIResponder Chain & First Responder — The library must track which UITextField/UITextView became first responder to know which view needs to be scrolled into visibility; understanding responder chain is essential for debugging keyboard avoidance failures
• View Hierarchy & Content Inset Adjustment — IQKeyboardManager manipulates UIScrollView.contentInset and UIView.frame properties to make room for the keyboard; understanding view coordinate systems and scroll view geometry is critical for contributing to core logic
• CocoaPods Subspecs — This library uses subspecs to allow developers to include only needed features (Core, Toolbar, ReturnManager, etc.); understanding subspec syntax in Podspec is necessary for modifying the modular architecture
• Safe Area & Layout Guides — Modern iOS keyboard avoidance must account for Safe Area insets (notches, home indicator) and UILayoutGuide; IQKeyboardManager likely uses these to compute correct adjustment values across iPhone models
• UITextView Placeholder Simulation — The optional IQTextView subspec adds placeholder text support (a native UITextView gap); understanding how to layer CATextLayer or shadow text atop UITextView is needed for this feature
• Keyboard Toolbar (InputAccessoryView) — The IQKeyboardToolbarManager subspec adds Previous/Next/Done buttons above the keyboard; this uses UITextInputAssistantItem or UIToolbar as inputAccessoryView, a UIKit pattern often overlooked by junior developers

• ReactiveX/RxSwift — Common pairing for reactive keyboard event handling and UITextField observation patterns in modern iOS projects
• realm/realm-swift — Complementary database library often used alongside IQKeyboardManager in data-driven iOS apps with forms
• snapkit/snapkit — SnapKit layout DSL frequently combined with IQKeyboardManager to programmatically manage view constraints alongside keyboard avoidance
• hackiftekhar/IQKeyboardManagerObjC — Original Objective-C version of this library; referenced in README as the legacy codebase for projects still on ObjC
• SwiftyJSON/SwiftyJSON — Common utility for parsing form submission responses in apps using IQKeyboardManager for input handling

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 support with Package.swift

The repo currently supports CocoaPods and Carthage (evidenced by Cartfile/Cartfile.resolved) but lacks SPM support, which is increasingly the standard for Swift packages. This would enable modern dependency management and align with Apple's recommended approach. No Package.swift file exists in the root.

• [ ] Create Package.swift in root directory with proper Swift version targeting and platform specifications
• [ ] Define the library target pointing to the source files in the IQKeyboardManagerSwift directory
• [ ] Add example target dependency configuration for the Example app
• [ ] Test package resolution with swift package resolve and verify builds work
• [ ] Update README with SPM installation instructions alongside existing CocoaPods/Carthage docs

Create GitHub Actions CI workflow to replace Travis CI

The repo uses outdated Travis CI (.travis.yml present), which has deprecated free tier support. Modern GitHub Actions would provide integrated CI/CD directly in GitHub, better visibility, and faster builds. No .github/workflows directory exists for GitHub Actions.

• [ ] Create .github/workflows/ci.yml with matrix strategy for iOS SDK versions (14.0, 15.0, 16.0, latest)
• [ ] Add build and test steps for both Example app and example extension schemes referenced in xcschemes
• [ ] Add SwiftLint validation step (Example/.swiftlint.yml already exists)
• [ ] Configure matrix to test against multiple Swift versions and iOS deployment targets
• [ ] Remove or deprecate .travis.yml after workflow is verified working

Add comprehensive unit test suite for core functionality

Despite 8 major migration guides (1.0 through 8.0) indicating significant feature evolution, the repo appears to lack dedicated unit tests. The Example app has cells and extensions but no Tests directory. Core keyboard management logic needs test coverage for regressions, especially given the complexity of keyboard handling across iOS versions.

• [ ] Create Tests/ directory with IQKeyboardManagerTests.swift targeting keyboard show/hide scenarios
• [ ] Write tests for UITextField/UITextView detection and scrolling behavior
• [ ] Add regression tests for known edge cases mentioned in migration guides (if documented in issues)
• [ ] Test configuration options (enable/disable functionality, custom settings) in OptionTableViewCell patterns
• [ ] Integrate tests into GitHub Actions workflow created in PR #2 and configure code coverage reporting

• Add unit tests for Example/IQKeyboardManagerSwiftExample/Cell/TextFieldTableViewCell.swift and ImageSwitchTableViewCell.swift to verify keyboard avoidance in different cell configurations; currently no test directory visible in the file list
• Document the modular subspecs architecture with concrete code examples in the README: show before/after Podfile snippets for including only Core vs. Core+IQKeyboardToolbarManager, since the README mentions subspecs but the Example/ folder includes everything
• Create a migration guide or FAQ section explaining how to upgrade from Objective-C IQKeyboardManager (moved to hackiftekhar/IQKeyboardManagerObjC) to the Swift version, including API mapping and behavioral differences

The IQKeyboardManager repository demonstrates reasonable security practices with a defined vulnerability disclosure policy and active GitHub presence (suggesting regular updates). However, there are areas for improvement: the security policy is incomplete, the CI/CD infrastructure appears outdated (Travis CI), no visible dependency vulnerability scanning was detected, and there's minimal evidence of automated security tooling. The codebase itself appears to be a UI utility library with low inherent injection risks (no database or web service calls evident). The main security posture relies on the maintainers' responsiveness to vulnerability reports and keeping dependencies current. Recommend: completing SECURITY.md, migrating to GitHub Actions with integrated security scanning, and implementing automated dependency checking.

• Medium · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears to be truncated or incomplete. The policy section ends abruptly mid-sentence after 'issue a new release prior to any public exposure; this helps protect the project's users, and provides them with a chance to upgrade and/or update in order to protect their applications.' This incomplete documentation could confuse reporters about the full vulnerability disclosure policy. Fix: Complete the SECURITY.md file with the full vulnerability disclosure policy, including: timeline for patch releases, deprecated version support windows, and acknowledgment procedures.
• Low · Legacy Build System Configuration — .travis.yml. The repository contains .travis.yml configuration for Travis CI, which has been deprecated and is no longer recommended. This may indicate outdated CI/CD infrastructure that could miss modern security scanning tools and automated dependency updates. Fix: Migrate to modern CI/CD platforms such as GitHub Actions (already partially adopted based on .github directory) and ensure it includes: automated dependency scanning, SAST tools, and regular security updates.
• Low · No Visible Dependency Lock File Analysis — Cartfile, Cartfile.resolved, Package.swift (if present). The 'Dependencies/Package file content' section is empty, making it impossible to analyze for vulnerable dependencies. For a Swift/iOS library, there should be clear dependency management via CocoaPods, SPM, or Carthage (evidenced by Cartfile presence). Fix: Provide dependency lock files for analysis. Ensure regular dependency updates and use tools like Dependabot or similar to automatically check for vulnerable dependencies. Consider using GitHub's built-in vulnerability scanning.
• Low · Bridging Header Exposure — Example/IQKeyboardManagerSwiftExample/Resources/IQKeyboardManger-Swift-Bridging-Header.h. Presence of 'IQKeyboardManger-Swift-Bridging-Header.h' in example project could expose implementation details. While this is in the example application (lower risk), it's a best practice to minimize bridging header scope. Fix: Limit bridging header content to only necessary Objective-C imports. Ensure it doesn't expose internal APIs or implementation details that shouldn't be public.

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.