stream-chat-swift: the official iOS SDK for Stream Chat

Three layers, and two of them are UI

The repository is the official iOS SDK for Stream Chat, a service for building chat and messaging applications, and it contains both a low-level client and a set of reusable UI components. The three layers are worth separating, because the choice between them is the first decision you make. The StreamChat SDK is the low-level client, it contains no UI components at all, and it is meant for the case where you want to build a fully custom interface. For most use cases the readme recommends the UI SDKs instead, and there are two of them. StreamChatUI is the UIKit library, it is in this repository, and it is the right one if your application has to support iOS 13 and above. StreamChatSwiftUI is the SwiftUI library, it needs iOS 14 and above, and it lives in a separate repository, with the readme noting that its design is new and pointing to the v5 documentation for details. The deployment targets are iOS 13 and up, built with Swift 6, and the package is Swift Package Manager compatible.

Four modules, and their sizes are on the label

The badges at the top of the readme list the shipped modules with their sizes, which is unusually honest for a vendor and directly useful when you are deciding what to include. StreamChat, the low-level client, is 7.08MB. StreamChatUI, the UIKit components, is 3.38MB. StreamChatCommonUI is 1.03MB and holds the pieces shared between the UI layers. StreamChatAI is 2.36MB, and it is the newest of the four, since the AI components section at the end of the readme is where the vendor is pushing its assistant story. A chat SDK is not a small dependency, and the readme's AI integrations link, a tutorial on wiring the UI components to large language models and agents, tells you where that module is heading. The other product lines sit next to it too, a Video SDK that integrates with the chat SDK and a Feeds iOS SDK, so the family is a platform rather than a single library, and the dependency decisions you make today are likely to interact with those.

Offline support and behaving like a platform citizen

The feature list is short and the first item is the one that changes an architecture. Offline support means you can browse channels and send messages while offline, which implies a local store, a queue and a reconciliation story, and it is the feature that stops a chat app from feeling broken on a train. The second item is about behaviour rather than capability. The UI elements are described as good platform citizens: they respect tintColor, layoutMargins, light and dark mode and dynamic font sizes, which sounds like a list of small things and is exactly the list of small things that make an embedded component set look foreign. On top of that the SDK uses Swift native language features so the API is type-safe, the UIKit and SwiftUI libraries follow native patterns and paradigms rather than inventing their own, and there is first-class support for Combine and for Structured Concurrency, with separate getting started guides for each. The SDK is fully open source, and the readme is proud of supporting older iOS versions, so your app can stay available to almost everyone.

Progressive disclosure, and open by default

The design principles section explains why the SDK is shaped the way it is. Progressive disclosure means the SDK can be used easily with very minimal knowledge of it, and as you become more familiar you can dig deeper and start customising it at every level. High customisability follows: every element is designed to be easy to modify, you can change the brand colour by setting tintColor, apply appearance changes using custom UI rules, or subclass existing elements and inject them everywhere in the system no matter how deep the logic hierarchy goes. Then there is the principle that tells you what to expect from the source code. Everything is open unless there is a strong reason for it not to be, which means you can modify almost every behaviour of the SDK to fit your needs, including the parts you would not expect to be reachable. For a team that has to match a design system exactly, or add a behaviour the vendor did not anticipate, that is the difference between an SDK you use and an SDK you fight.

Dependencies are hidden, and the Makefile shows the cost

The SDK tries to keep the list of external dependencies to a minimum, and starting with version 4.6.0 the dependencies are hidden inside the libraries rather than exposed to your project. That is a deliberate developer-experience decision with a visible consequence in the repository, because hiding a dependency means vendoring it and keeping it in step. The Makefile at the root is where that work is visible. There is a bootstrap target that runs a script, a generate target that runs Sourcery against a configuration file, and an update_dependencies target that bumps five libraries in sequence, with the versions pinned in the makefile: SwiftyGif at 5.4.2, DifferenceKit at 1.3.0, Splash at 0.16.0, MarkdownUI at 2.4.0 and NetworkImage at 6.0.1. Each has its own update rule, and the rules are not all the same, because MarkdownUI is special. Its Swift sources go into StreamChatAI while its cmark-gfm C sources go into a separate target, and the scripts remove public declarations and prefix the C symbols, which is the work needed to absorb a third-party library without exposing it. Objective-C projects can still integrate the SDKs, with customisation done by subclassing the Swift components and using them from Objective-C code.

The example apps are the documentation

The repository carries a lot of sample code, and the names make it clear that the samples are the intended learning path. The Examples directory holds an EdgeCases project, a Shared project, and four clones of applications people already know: MessengerClone, SlackClone, YouTubeClone and iMessageClone. Cloning a product you use is a good way to show what a chat SDK can do, and a Slack clone and an iMessage clone sit at opposite ends of what teams need, one being a dense multi-pane workspace and the other a single conversation list. There is also a DemoApp, a DemoAppPush, a DemoShare, a StreamChatSample, a Stream.playground for trying code in place, a Documentation.docc directory for Apple's documentation format, and a StreamChatUITestsApp with its own UI tests. The SwiftUI SDK, the AI integrations tutorial, the documentation site and the quick start guides are all linked from the readme, and the API key you need comes from registering for a trial.

The service behind the SDK is commercial

The SDK is open source and the service is not, and the boundary matters for a procurement conversation. Stream is free for most side and hobby projects, and the readme gives the exact thresholds: you can use Stream Chat for free if you have fewer than five team members and no more than $10,000 in monthly revenue. Above that, the service is a paid dependency even though the client code is free, and an app that ships with chat in it inherits that bill. On the code side, the licence is one GitHub cannot classify, so the LICENSE file is the thing to read, and the repository publishes on the develop branch by default with tagged releases such as 5.14.0 on 2026-10-15, 5.13.0 before it and 5.12.1 before that, with the last push on 2026-10-19. The development tooling in the tree is thorough, with SwiftLint, SwiftFormat, Danger for pull request review, lefthook for git hooks, fastlane for releases, SonarCloud for coverage, a privacy manifest and both an AGENTS.md and a CLAUDE.md for coding assistants.

Editorial conclusion

The SDK is the right choice if you are building a chat experience on iOS and want a battle tested message list, composer and channel logic rather than writing your own, and if you are prepared to use a hosted service rather than running your own chat backend. It is the wrong choice if your data must stay inside your own infrastructure, if the free tier thresholds do not fit you, or if you want a SwiftUI implementation in the same package, since that lives in a separate repository. Before you start, read the installation guide for the SPM setup, check the module sizes against your app budget, and decide early whether you need the AI components, since that module is the one growing fastest.

Frequently asked questions

Official sources

1. GetStream/stream-chat-swift on GitHub
2. Issues
3. Project website
4. README
5. Releases