InputBarAccessoryView: a UIKit input bar with autocomplete and attachments

What the component gives you

InputBarAccessoryView is a simple and easily customizable InputAccessoryView for making powerful input bars with autocomplete and attachments. It is a UIKit component, and the primary language in the repository metadata is Swift.

The feature list is a checklist of the things a chat input bar has to do, and each line is a piece of work you would otherwise write yourself.

There is autocomplete text with an @mention, a #hashtag, or any other prefix you choose, so the trigger character is not hard-coded. There is a self-sizing `UITextView` with an optional fixed height, and it can be replaced with any other view. There is image paste support. There is autocomplete attributed text highlighting, so the matched part of the suggestion is styled rather than being plain text. There are reactive components that respond to given events. There are top, bottom, left and right `InputStackView` objects that act as toolbars to place buttons. There is a drop-in attachment view for file and photo management. And there is plugin support for your own `InputPlugin` types.

The last two lines of the list are about fit rather than function: it is compatible with all iPhones and iPads, and it has RTL support.

The requirements are iOS 14.0 or newer and Swift 6. The README also records where the older support lines stopped: the latest iOS 13 release is v6.5.1, the latest iOS 12 release is v5.5.0, the latest iOS 11 release is v5.1.0, the latest Swift 5.0 release is v5.1.0, and the latest Swift 4.2 release is v4.2.2. CocoaPods and RxExtensions were removed in 6.0.0.

The project is MIT licensed, the default branch is master, and the last push was on 2026-09-07. The recent releases are 7.0.6 from 2026-04-07, 7.0.5 from 2026-03-25 and 7.0.4 from 2025-12-04.

The layout is four stack views around a text view

The layout section is where the component's real work is documented, and it explains the constraint design.

The layout of the `InputBarAccessoryView` is made of four `InputStackView` objects and an `InputTextView`. The padding of the subviews can be adjusted by changing the `padding` and `textViewPadding` properties, and the constraints are updated automatically.

The important detail is how the side stacks are anchored. Each of the `InputStackView` objects to the left and right of the `InputTextView` is anchored by a width constraint, so the text view always fills the space in between, and the component provides methods that can easily be called to hide all the buttons to the right or to the left of the text view by setting the width constraint constant to 0. The bottom and top stack views are not height constrained and rely on their `intrinsicContentSize` instead.

Those two methods are the API:

func setLeftStackViewWidthConstant(to newValue: CGFloat, animated: Bool)

func setRightStackViewWidthConstant(to newValue: CGFloat, animated: Bool)

So hiding a whole column of buttons is a call that animates a width constraint to zero, rather than a call that removes views and rebuilds the hierarchy. For a chat bar where the send button appears only when there is text, and the attachment button disappears when a photo is attached, that is the difference between an animation and a layout jump.

The asymmetry between the side stacks and the top and bottom stacks is also deliberate. A side stack has a fixed width because it competes with the text view for horizontal space, whereas a top or bottom bar sizes itself from its content, so a row of buttons of varying width lays out naturally without the caller computing anything.

The reactive hooks, and what they are for

Each `InputBarButtonItem` has properties that hold actions executed during various hooks, such as the button being touched and the text view text changing. The README's point is that with a few lines of code the items can be easily resized and animated, similarly to the Facebook Messenger app.

The hook list is the API surface:

// MARK: - Hooks
    
public typealias InputBarButtonItemAction = ((InputBarButtonItem) -> Void)    
    
private var onTouchUpInsideAction: InputBarButtonItemAction?
private var onKeyboardEditingBeginsAction: InputBarButtonItemAction?
private var onKeyboardEditingEndsAction: InputBarButtonItemAction?
private var onKeyboardSwipeGestureAction: ((InputBarButtonItem, UISwipeGestureRecognizer) -> Void)?
private var onTextViewDidChangeAction: ((InputBarButtonItem, InputTextView) -> Void)?
private var onSelectedAction: InputBarButtonItemAction?
private var onDeselectedAction: InputBarButtonItemAction?
private var onEnabledAction: InputBarButtonItemAction?
private var onDisabledAction: InputBarButtonItemAction?

The set of hooks is a clue to the problems this component solves. `onKeyboardEditingBegins` and `onKeyboardEditingEnds` are the events a chat bar needs to animate itself around the keyboard, and `onKeyboardSwipeGesture` is the one for the interactive dismissal of the keyboard, where the bar has to follow a drag rather than a discrete change. `onTextViewDidChange` is where you decide whether the send button is enabled, and `onEnabled` and `onDisabled` are the paired events for animating a button in and out.

The `onSelected` and `onDeselected` pair, and the `onEnabled` and `onDisabled` pair, are the same pattern: the component tells you when a state changed so that you can animate, rather than exposing the state and hoping you react to it.

The release history, and the two breaking changes

The Latest Releases section is a short changelog with the two major versions highlighted, and it reads like a list of problems that were hard.

7.0.0 has two breaking changes. It drops iOS 13 support, and it moves to Swift 6 with full support for Swift concurrency.

6.0.0 also has two. It drops iOS 12 support, and it drops CocoaPods support and the RxSwift extension, which was available only via CocoaPods. It also notes that the KeyboardManager will not update the position of the inputAccessoryView from the interactive dismiss panGesture when the keyboard is floating, and that the documentation was updated.

Between them, the minor releases are mostly layout fixes, and they are specific in a way that tells you about the component's difficulty. 6.4.0 fixed bottom gap calculations for embedded controllers. 6.3.0 fixed the gap between the keyboard and the input bar when used on a pagesheet or formsheet on iPad, and fixed a crash after adding an image attachment. 6.5.0 bumped the Swift version to 5.10 and moved layout changes onto the main thread.

That last one is worth noting in the context of the 7.0 concurrency move. A component that manipulates constraints from a background thread and a component that does it on the main thread are different components, and 6.5.0 was the step towards the Swift 6 model that 7.0.0 completes.

Two smaller entries show the shape of the component. 6.2.0 removed `canBecomeFirstResponder` on `InputTextView` to fix `UITextViewDelegate` methods not being called. And 6.1.0 added `additionalInputViewBottomConstraintConstant` to the KeyboardManager, as a way to provide an additional bottom constraint constant offset for the inputAccessoryView, with an example implementation in an `AdditionalBottomSpaceExampleViewController`.

The full history is in the `CHANGELOG.md`.

Autocomplete, plugins and the attachment view

Three of the features are worth describing in terms of what they let you build, because they are the reason to adopt the component rather than write an input bar.

The autocomplete is prefix-driven, with @mention and #hashtag given as the examples and any other prefix supported. It comes with attributed text highlighting, so the suggestion list and the text in the field can be styled to match. The `MessageViewController` project by GitHawk is listed under Featured In specifically for the autocomplete highlighting algorithm, which suggests that the highlighting is the part worth stealing if you are not adopting the whole component.

The plugin support is the extension point. The feature list names your own `InputPlugin` types, so a text bar plugin, a mention plugin and an attachment plugin are separate objects that the bar composes, rather than a single class with a flag per behaviour.

The attachment view is described as a drop-in for file and photo management, and it is the piece that makes the difference between a bar that can send text and a bar that can send a photo. It is also where the 6.3.0 crash after adding an image attachment lived, so it is the part of the component with the most edge cases.

Image paste support sits alongside it, which is a separate capability from attaching: the user copies an image and pastes it into the field.

The `Example` directory in the repository is a full application, and the README says to see it for how to make the iMessage, Slack, Facebook and GitHawk style input bars, with the documentation in `GETTING_STARTED.md`.

Who uses it, and the SPM version you would actually get

The Featured In section asks you to add your app to the list by making a pull request, and names two projects.

MessageKit, which the note says was renamed to MessageInputBar, is listed first. And MessageViewController by the GitHawk app, listed for the autocomplete highlighting algorithm. Both are listed by name, which is the strongest evidence the README offers that the component works outside a demo.

The installation instructions are for Swift Package Manager, and the README explains that SPM is a tool for automating the distribution of Swift code and is integrated into the `swift` compiler. Adding the package as a dependency is a line in the `dependencies` array of your `Package.swift`:

dependencies: [
    .package(url: "https://github.com/nathantannar4/InputBarAccessoryView.git", .upToNextMajor(from: "6.0.0"))
]

There is a detail in that snippet worth catching. The constraint is `.upToNextMajor(from: "6.0.0")`, so it resolves to the newest 6.x release, while the current published release is 7.0.6. A project that copies the README snippet verbatim gets the 6.x line, not the 7.x line, which means the Swift 6 concurrency work and the iOS 13 drop do not apply to it.

The alternative is to add the package through the Xcode SPM editor using the URL `https://github.com/nathantannar4/InputBarAccessoryView.git`, where the version can be chosen interactively.

The repository root has a `Package.swift`, a `Sources/` directory, the `Example/` application with its own Xcode project, the `GETTING_STARTED.md` document, a `CHANGELOG.md`, a `docs/` directory, a `Screenshots/` directory with the preview animation and the six example screenshots, and a `GitHubActions/` directory for continuous integration.

Where InputBarAccessoryView is the wrong choice

The first wrong case is a SwiftUI project. The component is UIKit, the API is `UITextView`, `UIView` constraints and `InputStackView` objects, and the reactive hooks are UIKit delegate events. Adopting it in a SwiftUI app means wrapping it in a representable and losing most of the customisation, since the layout is built on Auto Layout constraints between UIKit views rather than on SwiftUI's layout system.

The second is a team on iOS 13. The 7.0 release dropped that support, so a project pinned to 13 has to stay on the 6.x line, and the SPM snippet in the README happens to point at exactly that line.

The third is a project that only needs a plain input bar. If you want a text field above the keyboard with a send button and no autocomplete, this component brings a plugin system, an attachment view, a keyboard manager and a set of layout constraints for a feature set you will not use.

The fourth is a team that needs the app to work on Android as well. The component is iOS only, and the topics list the platform as uikit, so a cross-platform chat interface means a second implementation.

The fifth is an organisation that needs a maintained support commitment. The last push was on 2026-09-07 and the newest release is 7.0.6 from 2026-04-07, and the fixes in the changelog are layout fixes on iPad formsheets, which is the kind of component that needs a maintainer who tests on real devices.

For an iOS chat interface with autocomplete, though, the combination of a self-sizing text view, a keyboard-tracking input bar and a mention plugin is a lot of well-tested behaviour to get for free.

Editorial conclusion

InputBarAccessoryView suits a UIKit team building a chat interface that needs mention and hashtag autocomplete, image pasting, a custom attachment tray and a keyboard-tracking input bar, and that would rather adopt a battle-tested component than write the constraint maths. It does not suit a SwiftUI project, since the whole component is UIKit based, and it does not suit a team still on iOS 13, because the 7.0 release dropped that support. Before adopting it, read the `GETTING_STARTED.md` document and the example project, and note that the Swift Package Manager snippet in the README still pins the dependency from 6.0.0 while the current release is 7.0.6, so the version you resolve will be older than the code the README describes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nathantannar4/InputBarAccessoryView on GitHub
4. README
5. Releases