IQKeyboardManager: drop-in keyboard avoidance for UIKit apps

The text field problem IQKeyboardManager removes

On iOS, the system keyboard slides up over the lower part of the screen. Any UITextField or UITextView sitting there is covered, and the user cannot see what they are typing. The usual fix is manual: register for keyboard notifications, read the keyboard frame, compute the overlap, adjust the view or scroll view content inset, and reverse all of it on dismissal. Every screen repeats that work, and every edge case (rotation, hardware keyboard, split view) adds branches.

IQKeyboardManager targets that repetition. The README describes it as a library that prevents the keyboard from covering UITextField and UITextView "without needing you to write any code or make any additional setup". The audience is UIKit app developers, and the feature list names UIScrollView, UITableView and UICollectionView as handled containers. It is not a SwiftUI library, and the README does not claim SwiftUI support.

How the codeless avoidance works and what the subspecs split

The mechanism is runtime observation rather than a subclass or a protocol. Because the library works with standard UIKit components, the README lists "No More Subclasses" and "Works with standard UIKit components" as features: you keep using plain UITextField and UITextView, and the library reacts to the keyboard and to the active first responder.

The 8.x line moved to a modular architecture. Core is always included and covers basic keyboard distance management. Appearance, IQKeyboardReturnManager, IQKeyboardToolbarManager, IQTextView and Resign are optional subspecs, and the README states that all subspecs are included by default. IQKeyboardToolbarManager is the one that adds the Previous, Next and Done buttons. IQTextView is a UITextView with placeholder support, which UIKit does not provide natively. If you only need the distance handling, pulling in the rest is dead code in your binary.

Control is class-level. The README lists "Class-level enable/disable control" and a configurable keyboard distance, which is how you turn the behaviour off for a screen where it interferes.

Installing IQKeyboardManager with CocoaPods and enabling it

The README's first installation path is CocoaPods. Add the pod to your Podfile, then run pod install. The default line pulls in every subspec, including the toolbar:

pod 'IQKeyboardManagerSwift'

To pin a version, the README shows the version appended to the pod name, and points at the Swift support table for choosing it:

pod 'IQKeyboardManagerSwift', '8.0.0'

If you want only the toolbar subspec, the README gives this example, which implies you can list subspecs individually rather than taking the whole pod:

# Include toolbar example
pod 'IQKeyboardManagerSwift/IQKeyboardToolbarManager'

Carthage is the second documented path: add the line for IQKeyboardManager or IQKeyboardManagerSwift to your Cartfile. A Package.swift file sits at the repository root, so Swift Package Manager is a third route, though the README excerpt does not spell out the SPM product name.

After installation, the README's claim is that enabling is the whole setup. The related search phrase "Value of type IQKeyboardManager has no member enable" points at the part the README does not show: the exact call site. Treat the enable step as the first thing to confirm against the current release notes before you build.

Where IQKeyboardManager is the wrong dependency

The README carries a warning that is stronger than most library disclaimers. It tells anyone building an SDK, library or framework to implement their own solution instead, and says adding IQKeyboardManager as a dependency of a third-party library "could block adoption by other developers for their projects as well (who are not using IQKeyboardManager and have implemented their custom solution)". That is a distribution problem, not a technical one: a host app that already manages insets will fight a library that moves views on its own.

The same warning assigns conflict handling to the app developer. If IQKeyboardManager collides with another third-party library, the README says it is the developer's responsibility to enable or disable it when presenting or dismissing that library's UI. Nothing in the library detects the conflict for you.

There is also a version floor to respect. The README's table puts IQKeyboardManagerSwift at a minimum of iOS 13.0 and Xcode 13, and the Swift support table maps Swift 5.9, 5.8 and 5.7 to Xcode 16 and IQKeyboardManagerSwift 7.0.0 or later. On an older toolchain, the current release is not the one you want.

IQKeyboardManager compared with KeyboardKit and hand-rolled observers

KeyboardKit appears in the related searches as the alternative people weigh against this library, and the two take opposite positions on scope. IQKeyboardManager stays inside UIKit and does one job: keep the focused text input visible. KeyboardKit is a keyboard framework, aimed at building custom keyboard extensions and their behaviour, which is a different problem from moving a text field in your own app. If your requirement is a custom keyboard, IQKeyboardManager does not address it.

The other alternative is the code you would write yourself: keyboard notifications, frame math, inset changes. That approach costs more lines and more tests, but it gives you exact control over which screens move and by how much, and it carries no dependency for a host app to inherit. IQKeyboardManager's trade is the reverse: less code in your app, less control over the specific screen where the automatic behaviour is not what you want.

Maintenance, licence and the Objective-C split

The repository is not archived, and the last push was on 2026-05-25, the same day release 8.0.3 was published. Release 8.0.2 is titled "Objective-C library moved to separate repo, iOS 26 compatibility", and the README opens with a pointer to hackiftekhar/IQKeyboardManagerObjC. If you maintain an Objective-C codebase, the Swift repository is no longer where that source lives, and the related search phrase "iqkeyboardmanager objective c" now resolves to a different repository.

Upgrade cost is mostly the subspec decision. Because all subspecs ship by default, a version bump can add behaviour you did not ask for, and the README's modular section is the place to check what changed. The Swift and Xcode table is the other gate: a jump in minimum Xcode can block an upgrade on a team that has not moved toolchains yet.

The licence is MIT, per the repository and the LICENSE.md badge. MIT is permissive, so the practical obligation is keeping the copyright notice and licence text with the distributed code. That is a general property of the licence, not legal advice for your distribution model.

Editorial conclusion

Adopt IQKeyboardManager in an app target where the team wants keyboard avoidance without maintaining its own observer code, and pin the CocoaPods subspecs to the features you actually use. Do not ship it inside an SDK or a third-party library, because the README states that doing so can block adoption by developers who already handle text fields themselves. Before upgrading, check the Swift and Xcode table in the README, confirm the Core subspec alone still compiles, and test any screen where a third-party UI is presented while the keyboard is up.

Frequently asked questions

Official sources

1. hackiftekhar/IQKeyboardManager on GitHub
2. Issues
3. License: MIT
4. README
5. Releases