Textual: a native macOS IRC client where the UI is CSS, HTML and JavaScript

The interface is web technology, the client is native

Textual is a native macOS application for Internet Relay Chat, written in Objective-C, and it is not a wrapper around a web view in the ordinary sense. What makes it unusual is that the parts of the interface users think of as front end are expressed in CSS, HTML and JavaScript. Styles are written in CSS, markup in HTML, and behaviour in JavaScript, while the application itself is a native app.

Extension follows the same split. Plugins are written in Objective-C and Swift, and scripting goes further: the README names AppleScript and many other languages as available for automation. So the extension story is wider than a typical native Mac app, where Objective-C alone would be the ceiling.

The result is a client that looks and configures like a web application while being distributed, updated and integrated as a Mac app. That combination is the reason it has survived: the theming model that web developers already understand carries over directly.

main is a rewrite, and the README tells you not to build it

The first thing the README says is a warning, and it is unusually direct. The main branch is a work in progress toward Textual 8, under heavy development and substantial refactoring, and until Textual 8 ships it may contain serious bugs, incomplete features and breaking changes. The strongest line: it may not build at all. The instruction is not to use builds from this branch with settings or logs you care about.

The current release lives elsewhere. The README points to www.textualapp.com for the release build, and the Textual 7 source sits on the v7 branch. The repository publishes no GitHub releases, so there is no tag history to fall back on, and the website is the only distribution channel the documentation names.

There is no build command in the README to copy. The repository is a macOS project with a Textual.xcworkspace, Configurations/ and Packaging/ directories, and CONTRIBUTING.md is described as covering how to build and test Textual. Anyone wanting a development build should read that file, not guess at xcodebuild invocations.

Maintainership changed hands, and the work continues from a retired fork

The second README notice covers governance rather than code. Textual is under new maintainership: for most of its life it had a single full-time maintainer, who has since moved on to other ventures. The current maintainers have taken over and state that active development continues. Development picks up from Textwerk, a community fork of Textual that has now been retired, and many of the features and fixes made in Textwerk are expected to carry over into Textual 8.

That lineage matters for anyone with an existing setup. Work you may have found in Textwerk, whether a plugin or a fix, is being folded into the mainline, but the mapping is not documented as complete. The repository also lists sample projects, including a Swift Bot sample and a Preference Pane sample, which are the closest thing to a worked example of the plugin API.

The last push to the repository was on 2026-10-15, so the rewrite is moving. Whether it moves fast enough to deliver Textual 8 is not something the README answers.

A license with two copyright lines and an obligation you can actually check

Textual is distributed under the BSD 3-Clause License, and the README spells out the obligations rather than leaving them in the file. Both the inherited BSD 2-Clause terms from LimeChat and the BSD 3-Clause terms applied to Textual require that copyright notices be preserved in source and binary distributions. The README states that the names of the copyright holders may not be used to promote products derived from the software without prior written permission.

The attribution chain is visible in the README. LimeChat, under BSD 2-Clause, is copyright 2008-2010 Satoshi Nakagawa. Textual is copyright 2010-2020 Codeux Software, LLC and respective contributors, and 2026 Blendbyte GmbH and respective contributors. The project itself began as a fork of LimeChat in 2010.

Compliance is verifiable in the app rather than only in the source tree. The README notes that every notice is shown in the application under Help then Acknowledgements, built from Acknowledgements/Components.txt. If you redistribute Textual or embed it in something you ship, that file and the built Acknowledgements view are the artifacts to keep intact. GitHub classifies the repository license as a custom license, so the LICENSE file is the authoritative text rather than a detected SPDX identifier.

Third-party components carry their own obligations

The README lists the bundled or linked components with their licenses, and the list is worth reading before you redistribute the app. GRMustache is MIT, copyright 2014 Gwendal Roué. The Google Toolbox for Mac component GTMNSString+HTML is Apache 2.0, copyright 2006-2008 Google Inc. Reachability is BSD, copyright 2011 Tony Million. AutoHyperlinks Framework is BSD 3-Clause, copyright the Adium Team and Codeux Software, LLC. CocoaAsyncSocket, used as GCDAsyncSocket, is public domain, originally by Robbie Hanson and maintained by Deusty LLC. Colloquy's Chat Core is BSD-style, copyright 2000-2012 the Colloquy IRC Client. Sparkle, the update framework, is MIT, copyright 2006-2017 Andy Matuschak and contributors. gemoji, which supplies emoji names, is MIT, copyright 2019 GitHub, Inc.

The internal Cocoa Extensions framework additionally carries snippets from Apple, Dave Dribin, Satoshi Nakagawa and the Chromium developers, tracked in that framework's own ACKNOWLEDGEMENT.txt. Bundled styles ship their own copyright and license files, so a style you did not write has terms you have not read.

For a project that ships a signed, distributed Mac binary, that inventory is the difference between a clean audit and a question you cannot answer later.

Where to send what: discussions, issues, security and IRC

The README separates the channels clearly, which is worth knowing before filing anything. Questions and ideas go to GitHub Discussions. Bug reports go to GitHub Issues. Security issues follow SECURITY.md. There is also a chat channel, #textual on irc.libera.chat, which is the natural fit for an IRC client's own community.

Documentation is published separately at www.textualapp.com/docs rather than in the repository, so questions about using the client and questions about the code land in different places. That split also means the repository README is not a user manual, and there is nothing in it about connecting to a network, joining a channel or configuring a server.

Contributions have an explicit process. Pull requests are welcome, but because main is being refactored heavily ahead of Textual 8, large changes are likely to conflict with work in progress, so a discussion should be opened first for anything beyond a small fix. Fixes for Textual 7 belong on the v7 branch. CONTRIBUTING.md covers the build and test instructions, the contributor license grant and the project conventions.

The case against: a single-platform client mid-rewrite

The honest limitation is that Textual targets macOS and only macOS. There is no Linux or Windows build mentioned anywhere in the README, and the application icon, the Cocoa Extensions framework and the Xcode workspace all point to a Mac-only project. A team standardising on a cross-platform IRC client cannot use this as the common denominator.

The second limitation is timing. The branch you would naturally clone, main, is explicitly not ready, may not build, and contains breaking changes. The branch that is ready, v7, is where fixes land but where new development is not going. Anyone adopting this client is adopting a project in the gap between a stable release and an unfinished rewrite, with no release tags to pin against.

The third is the extension API. Plugins in Objective-C and Swift plus scripting in AppleScript is a wide surface, but the README does not document the plugin API itself, and it says Textwerk features are expected to carry over rather than confirming they have. Existing plugins should be checked against whatever ships in Textual 8 before they are treated as durable.

Editorial conclusion

Use the released Textual 7 build from www.textualapp.com if you want a usable IRC client today, and treat the repository main branch as a development artefact rather than a source to build from, since the README warns it may not build at all. Contributors fixing Textual 7 should target the v7 branch and open a discussion before anything larger than a fix. Before adopting the client in a long-lived setup, confirm that the plugin API you rely on still exists in Textual 8, because the rewrite pulls work forward from the retired Textwerk fork and the API surface is expected to move.

Frequently asked questions

Official sources

1. blendbyte/Textual on GitHub
2. Issues
3. Project website
4. README