SwiftUI-Architectures: the same chat app written three ways

One app, three state models

The repository contains implementations of a simple chat client called QBChat, and each implementation uses SwiftUI while applying a different architecture. The three named in the README are Model-View, Redux, and ViewState MVVM.

That framing is what makes the repository worth reading. The point is not the chat app, which is deliberately simple, but that the same feature set is expressed three ways. A reader who has only ever written one of these styles gets a reference implementation of the other two without having to invent a chat protocol, a message model and a list of views in order to see the difference.

The repository layout matches the premise exactly. The top level holds LICENSE, README.md, a README/ directory that contains the architecture diagrams as images, and the three implementation directories: QBChat-ModelView, QBChat-Redux and QBChat-MVVM. There is no shared package, no common module and no build script that ties the three together, which means each is a self-contained project and each is read on its own terms.

The primary language is Swift, the licence is MIT with the terms in License.md at the root, and the project comes from QuickBird Studios. The README also points to a blog article on the QuickBird Studios site that explains each SwiftUI architecture example in more depth, and the contribution guidance asks for an issue before a pull request and invites contributions that add other SwiftUI architectures to the repository.

There are no GitHub releases, which for a teaching repository is unremarkable but does mean there is no tagged version to point a colleague at.

Model-View, and the abstraction SwiftUI does not give you

The README's description of the Model-View variant is short and pointed: the Model-View architecture does not enforce abstraction of business logic from Views similar to the MVC architecture pattern with UIKit.

That sentence is the most useful thing in the repository, because it names a trap that people fall into when they arrive from UIKit. The mental model most iOS developers carry is that a View Controller in MVC owns the logic and the View is a passive rendering target, so separating the two feels natural and the framework supports it because UIKit hands you view controllers and view objects as separate things. SwiftUI does not hand you that split. A SwiftUI view is a value type describing what should be on screen, and it is entirely normal for the same view type to contain state, formatting logic and the bindings that drive a view model, all in one declaration.

So in a Model-View implementation of QBChat, nothing stops the business logic from ending up inside the view. The architecture pattern named in the README is not enforced by the framework; it is a convention that the code has to hold on to by discipline alone. A reader comparing the three directories should look for exactly this: how much of the message handling and the formatting logic lives in the view type, and whether the state changes are reachable from one place or scattered across the view hierarchy.

This is also where the comparison has value as a teaching device. Model-View is the baseline, the version with the fewest moving parts, and it is the right answer for a chat screen whose state is small. The other two directories exist to show what changes when that stops being true.

Redux, where the global store does the work

The README describes the Redux variant by pointing at Redux itself: in Redux-like architectures a global state is used to ensure consistency across all Views being kept in Stores. View components can trigger Actions which are interpreted into state changes by a reducer.

That is the whole contract in three sentences, and it maps onto QBChat in a fairly obvious way. The messages, the connection status and the composer text all live in one store rather than in the view that happens to display them. A view does not mutate state directly; it triggers an action, the reducer interprets that action and produces the new state, and the views re-render from what the store now holds. The single store is what guarantees consistency across views, because there is only one copy of the truth.

The word global is doing the work, and it is the source of both the benefit and the cost. The benefit is that any view can read the same state and there is no question about which of two copies is current. The cost is that the whole app's state is now coupled through one reducer and one action vocabulary, so a chat client that grows into a larger product either grows a large action type or grows several stores and reintroduces the consistency question at a higher level.

For a reader studying the QBChat-Redux directory, the interesting questions are concrete. How many action types does the chat app need? Where does the reducer stop being a switch statement and start being a domain? And what does the view actually contain, given that the state has left the view? The diagrams in the README/ directory are the author's own account of these structures, so they are the fastest orientation before reading the Swift.

ViewState MVVM, and what the name is doing

The third variant is called ViewState MVVM, and the README describes it in contrast to Redux: it uses separate ViewModels for each View, if required, and instead of a global state and global actions it creates a separate ViewModel interface for each View containing a State and different Inputs.

The name is doing real work. This is not classic MVVM with one view model per screen and a repository underneath. It is a MVVM in which each view gets its own small view model, and that view model holds the state for that view plus the inputs that view can emit. The phrase if required matters, because it allows a trivial view to have no view model at all.

The contrast with Redux is the point of the design. Where Redux centralises, ViewState MVVM decentralises, and the price is that consistency across views is no longer guaranteed by the architecture. If two views display the same data, each has its own copy in its own state, and the code that keeps them in agreement is code you write.

For a chat client specifically, the interesting case is the notification of a new message arriving while the user is looking at a different screen. In the Redux variant, one store handles it and every view sees it. In the ViewState MVVM variant, the question becomes how a background event reaches a view model that is not currently on screen, and that question is where the architecture either earns its keep or starts to leak.

The QBChat-MVVM directory is where a reader can see that decision made rather than described. Comparing how each of the three directories handles the same incoming message is probably the single most productive thing to do with this repository.

A teaching repository, not a template

It is worth being explicit about what this repository does not give you, because the name SwiftUI-Architectures invites the assumption that it is a starting point for a project.

There is no build or installation section. The README says nothing about how to open the three directories, which Xcode or Swift Package Manager setup they expect, or what deployment target they need. There is no dependency manifest at the top level, no shared library, and no indication in the directory listing of a Package.swift file or an Xcode project file. The listing of the top level contains only LICENSE, the three implementation folders, README.md and README/.

There are also no tests, no CI configuration and no release artefacts. There is a LICENSE, a README and the code, which is a reasonable shape for a repository whose purpose is to be read.

The maintenance picture is consistent with that. The last push was on 2026-05-28, the project is not archived, and it publishes no GitHub releases. For a repository of reference implementations, a quiet history is not a defect. But it does mean you should read the code as an illustration of a pattern rather than depend on it as an upstream dependency, and it does mean the pinned versions of anything the three projects rely on are whatever was current when the examples were written.

The README also frames the comparison against a written argument rather than a claim of best practice. The three architectures are presented as three options with their trade-offs, and the linked blog article is where the reasoning is set out. That is a healthier framing than a repository that tells you which one to use, because the right answer depends on the size and shape of the app you are actually building.

Editorial conclusion

Use SwiftUI-Architectures when you are deciding how to structure a SwiftUI codebase and want a working example of three architectures side by side on the same problem, which is more useful than reading three separate articles about them. Do not adopt it as a project template, since the repository ships no build instructions, no dependency manifest, no test targets and no releases, and the last push was on 2026-05-28. Before you copy from it, open the three QBChat-ModelView, QBChat-Redux and QBChat-MVVM directories, pick the architecture whose state model matches how your own app will grow, and read the linked blog article, which the repository treats as the place where the reasoning behind the three implementations is written down.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. QuickBirdEng/SwiftUI-Architectures on GitHub
4. README