Swiftcord: a native SwiftUI Discord client still shipping by waitlist

A public repository that contains no Swift source

The first thing to know about SwiftcordApp/Swiftcord is that the repository is not what a repository usually is. Its default branch is v2, and the entire tree on that branch is four entries: .gitignore, README.md, a docs directory and a docs-res directory. The latter two hold the documentation and the images the README links to. There is no Sources directory, no Package.swift, no Xcode project, and no licence file. The repository has 2,699 stars and 103 forks, which is a level of interest you would associate with an installable application rather than a code library.

That absence is deliberate, and the README states it in the section headed Open Source: Swiftcord is under heavy development and is not currently accepting external contributions, and source code will be made available following public release. A note underneath points legacy code seekers at the `main` branch, describing it as archived.

So there are two codebases referenced and neither is present on the branch you land on. The old SwiftUI client that had GitHub releases lives on `main`, which the README calls archived, and the v2 rewrite on the default branch has no code yet. If you arrived to read the implementation, that is the disappointment, and it is worth knowing before you clone anything.

What the v2 README claims for the rewrite

The v2 README is short and entirely promotional. It calls the app the 100% native SwiftUI macOS Discord client, now with Liquid Glass, and describes two things: that it looks and feels like a natural part of the machine because it uses system controls while rendering messages, rich text and embeds the way you expect, and that it is fast because it was rebuilt from the ground up with performance at its core, launching instantly and staying light on the system.

It also states the distribution model plainly. Swiftcord v2 is in prerelease and will be released in phases, and joining the waitlist at swiftcord.app gets you an email with a code to install it once a spot opens. Follow along on X or Discord for updates, and there is a community server linked from the README.

The Liquid Glass reference is the detail that dates this branch. That is the visual language Apple introduced for its own interfaces in a later macOS generation, which tells you this rewrite targets current hardware and current OS versions rather than trying to support older Macs. Combined with the empty tree, the picture is consistent: a rewrite in progress, not yet public, being released gradually to a list.

What the v1 releases say, and why v1 is finished

The release history documents the older client, and its final entry is blunt. Version 0.7.1, tagged Bug Terminator and published on 2023-11-09, opens with a warning that Swiftcord v1 is deprecated and no longer functional, directing readers to swiftcord.app for whatever comes next. The same block adds a second problem: builds will also fail to launch because of an expired signing certificate.

That is worth pausing on, because it means there is no working download on the releases page. The notes for each release carry a standing instruction that the build is unsigned, and to open it the first time you right click the application and choose Open to get past the macOS warning. An expired certificate removes even that workaround for anyone who has not already downloaded a build.

The substantive work in those releases does show what the client was capable of. Version 0.7.0 added channel permissions support, so visibility and message send rights were respected, rendered usernames properly after Discord removed discriminators, showed account creation and server join dates, and rendered the author and thumbnail fields of embeds. Version 0.6.1, from May 2023, brought unread dots per channel, multiline message input, folder animations, a Ventura-styled settings panel and smoother scrolling through message history. That is a competent feature list for a third-party client.

DiscordKit did the protocol work underneath

Both v1 release notes credit DiscordKit, the separate library that handles the Discord gateway and API, which tells you where the difficult part of a Discord client actually lives. The v0.7.0 notes say DiscordKit was updated to work with the latest gateway capabilities set, which allowed more information to be pre-cached, so faster rendering came from a library upgrade rather than from new client code.

The v0.7.1 login failure was also fixed upstream rather than locally. The note credits the fix to DiscordKit upstream by a named contributor, which is a reasonable division of labour: SwiftUI handles the interface, DiscordKit handles authentication, gateway events and the REST calls. It also means a Discord-side change can break the client without any Swiftcord code changing at all, which is the structural weakness of every third-party Discord client.

One smaller contributor is named directly in the v0.7.0 notes, credited with a username copy button and with sticker packs, along with a separate fix to password dialog labels. The v0.6.1 notes credit a Ventura-style settings overhaul and a fix for a bug where messages could be sent twice, the kind of defect that makes a chat client unusable quickly.

How to judge this against other macOS Discord clients

The honest comparison is not between this and another SwiftUI rewrite, because there are few serious ones, but between waiting for access and installing something today. Official alternatives are the browser client and Discord's own desktop application, both of which are maintained by Discord and therefore immune to the kind of upstream breakage described above. Community clients built as layers on top of the official application, which patch it rather than reimplementing the protocol, are the other option, and they update when Discord ships changes.

Swiftcord's argument against both is performance and native feel. The v2 README's claim is that a SwiftUI application using system controls should launch instantly, move between conversations smoothly and stay light on the system, which is a fair thing to want from a chat client people keep open all day. Whether the rewrite delivers it is not something the repository can show you, since there is no build and no code.

The signals to watch are all outside the source. Whether the waitlist opens, whether the email codes start arriving, and whether a public release is followed by an actual licence and a commit history. The repository is not archived and the last push was on 2026-06-20, so the project is still being worked on, but the last published binary is nearly three years old and its own author has marked it unusable.

Editorial conclusion

Swiftcord is a closed beta with a public repository attached, and knowing which half you are looking at saves a lot of confusion. The default branch is v2 and contains only README.md plus docs and docs-res directories, so there is no Swift source to read, no licence file, and no way to build it from what is published. The v2 README sells a rewritten client with Liquid Glass styling that is handed out in phases through an email waitlist. The GitHub releases tell the older story: v0.7.1 in November 2023 was the last build, and its own notes declare v1 deprecated and no longer functional, with builds that fail to launch on an expired signing certificate. Judge it as a product being tested in private rather than a library, and put a community client such as Vencord or an official desktop app next to it if you need something you can install today.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SwiftcordApp/Swiftcord on GitHub