badoo/Chatto: a Swift chat UI framework for iOS, and how to install it

What Chatto actually does, and who it is for

Chatto is a Swift framework for building chat applications, and the README describes it as lightweight, extensible and performant. That description is about the presentation layer. Nothing in the README mentions a server, a transport, message storage, delivery receipts or push notifications. If you arrive expecting a messaging product, you have the wrong repository.

The audience is narrower and more concrete: iOS engineers who already have messages coming from somewhere, and who now need to render them. A chat transcript is a hard list view problem. Rows have wildly different heights, new messages arrive at the bottom while the user is reading at the top, older messages load when the user scrolls up, and the whole thing has to stay smooth while the keyboard animates. Chatto is the piece that handles that list.

The framework ships as two modules. Chatto holds the core, and ChattoAdditions is the companion framework that the README says includes cells for messages and an extensible input component. You can take Chatto alone and write your own cells, or take both and get text bubbles, photo bubbles and an input bar. That split is the main design decision worth understanding before you start: the core does not know what a bubble looks like.

The mechanism: background layout, diffing and two-way pagination

The README lists the features rather than explaining them, but the list is specific enough to read as an architecture sketch. First, calculation of collection view changes and layout happens in the background. That means the expensive part, working out which rows changed and how tall each one is, is not done on the main thread while the user is scrolling.

Second, the framework supports pagination in both directions with autoloading. Older messages load when you reach the top, newer ones when you reach the bottom, and the framework triggers the loads rather than making you detect the scroll position yourself. Third, the README mentions message count contention for fast pagination and rotation with thousands of messages. That is the case that breaks naive chat implementations: a device rotation forces a full relayout, and a naive implementation stalls while it recomputes every row.

On top of the list, Chatto handles accessory view revealing by swiping from the right, and interactive keyboard dismissal, where dragging the list pulls the keyboard down with it. ChattoAdditions then supplies the visual layer: text bubbles, photo bubbles, and an input bar the README calls extensible. The data flow is one directional in the sense that matters. You give the framework a collection of items and a way to build cells for them, and it decides what changed, when to ask for more, and how to animate the result. The README does not document the exact protocol names, so treat the wiki as the source for those.

Installing Chatto with CocoaPods, Carthage or Swift Package Manager

The README documents three installation routes. CocoaPods is the one with version pins, and the pins matter because they are tied to Swift versions rather than to Chatto features. For Swift 5 the README gives 4.1.0; Swift 4.2 maps to 3.4.0, Swift 4 to 3.3.1, Swift 3 to 3.2.0 and Swift 2.x to 2.1.0. Start by making sure use_frameworks! is in your Podfile, then add the pods:

# Swift 5
pod 'Chatto', '= 4.1.0'
pod 'ChattoAdditions', '= 4.1.0' # if you want to use the cells or the input component

Drop the ChattoAdditions line if you only want the core and plan to write your own cells. The README also offers a bleeding edge option that tracks the master branch instead of a tag:

pod 'Chatto', :git => 'https://github.com/badoo/Chatto', :branch => 'master'
pod 'ChattoAdditions', :git => 'https://github.com/badoo/Chatto', :branch => 'master'

Then run pod install. After that you should see both pods resolved in your workspace, and the version line should read 4.1.0 rather than a range. If you use Carthage instead, the README says to add Chatto to your Cartfile:

github "badoo/Chatto"

The repository also contains a Package.swift at the top level, so Swift Package Manager is present in the layout even though the README does not walk through it. The third route is manual: clone, add as a submodule or download the archive, drag the Chatto or ChattoAdditions project into your workspace, and add them to Embedded binaries. Whichever route you take, the first real use is the same. Build a screen that hosts the chat collection view, feed it your message items, and let ChattoAdditions render the bubbles. The README does not include that first-use code, and points to the wiki instead, so budget time for the wiki before you estimate the work.

Where Chatto stops being the right tool

The clearest limitation is scope. Chatto renders messages. It does not send them, store them, order them or reconcile them with a server. If your problem is that messages arrive out of order after a reconnect, Chatto will not help, because that problem lives below the layer it occupies.

The second limitation is platform. This is a Swift framework built around collection view behaviour on iOS. The README's installation instructions are CocoaPods, Carthage and Xcode workspace integration, and the repository layout is an Xcode workspace with an app target. There is no Android, web or server component to reach for. If your product needs a shared chat experience across platforms, Chatto covers one of them.

The third is the release cadence. The newest release listed is 4.1.0 from 2021-05-21, and the README's version table stops at Swift 5. The repository's last push was on 2026-08-19, so work is still landing on master, but the tagged releases are old and the pins are by Swift version rather than by date. That combination is worth weighing: you may get fixes on master that are not in any tag, and taking master means accepting whatever is on the branch. The README does not document a support policy or a deprecation path, and it does not describe how to roll back a version, so treat upgrades as something you test rather than something you schedule.

Chatto compared with building the list yourself or using a full messaging SDK

The realistic alternative is not another chat UI library. It is either writing the collection view logic yourself, or adopting a hosted messaging SDK that includes its own UI.

Writing it yourself is more work than it sounds, but the work is concentrated in a few places: computing layout off the main thread, diffing the item set when messages change, and handling pagination at both ends without stuttering. Those are exactly the three things the README lists as Chatto's features, which tells you where the author expected the pain to be. If your transcript is short and never paginates, the framework is more machinery than you need, and a plain table view with fixed row heights will be simpler to reason about.

The hosted SDK route differs in kind rather than degree. A messaging SDK owns the connection, the message store and the delivery state, and hands you a view. Chatto owns none of that and hands you a list. The trade is control against integration surface: with Chatto you keep your own backend and your own data model, and you write the glue. With a full SDK you write less glue but you inherit its data model. The README gives no indication that Chatto intends to move down the stack, and the two-module split, core plus optional cells, is consistent with staying at the view layer.

Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-08-19. That is recent enough that the branch is live, but the release history tells a different story: 4.1.0 landed on 2021-05-21, 4.0.0 on 2020-09-21 and 3.6.0 on 2020-04-24. Commits and tags have diverged, and the README's own bleeding edge section is the acknowledgment of that, offering the master branch for people who want changes that are not in a release.

For upgrade cost, the practical unit is the Swift version, not the Chatto version. The README's table maps each Chatto release to a Swift release, so a toolchain upgrade is what forces a Chatto upgrade, and the pin in your Podfile is what decides whether that upgrade happens quietly. Pin exactly, as the README's examples do with the = operator, and the decision stays yours. Use the master branch and you have opted out of pinned upgrades entirely.

The licence is MIT, stated in the README and present as a LICENSE file at the repository root. MIT is permissive: it allows use, modification and redistribution, and it requires that the copyright notice and permission notice be preserved. That is the general shape of the licence, not advice about your situation. If you vendor the source into a closed product, the obligation to keep the notice is the part to check with whoever handles your legal review, along with the AUTHORS file at the root if you need to know who holds copyright.

Editorial conclusion

Adopt Chatto if you are building an iOS chat screen in Swift and want the collection view diffing, pagination and input bar handled for you, and you are willing to read the wiki because the README only points there. Do not adopt it if you need a messaging backend, a cross-platform client, or a project with a release cadence you can plan upgrades around: the newest release listed is 4.1.0 from 2021-05-21. Before committing, verify the Swift version you need against the podspec pins, check that Package.swift matches your toolchain, and read the wiki page for the version you install.

Frequently asked questions

Official sources

1. badoo/Chatto on GitHub
2. Issues
3. License: MIT
4. README
5. Releases