Why the official Slack app feels heavy
Slack's official desktop application is built on Electron, a framework that packages a full Chromium browser alongside the application code. That design choice makes cross-platform development straightforward for the team shipping it, but it comes with a predictable cost for the person running it: memory consumption that can climb well past 1 GB, a startup time measured in seconds, and a CPU that wakes up even when you are not actively using the app.
On a MacBook with limited RAM shared between the OS, development tools, a browser, and a handful of other utilities, that overhead is felt. On a Windows machine where you might already be running a heavy IDE, it compounds further. The official app works, but it asks for more than a messaging client arguably needs.
What "native" actually means here
The word "native" gets used loosely in software marketing, so it is worth being precise. msga is native in the sense that matters most for performance: it is compiled C++ code using the Qt6 framework — the same toolkit that powers Telegram Desktop — and it renders its own interface using the platform's graphics stack. There is no embedded web engine, no Node.js runtime, and no Chromium process tree running in the background.
That is a fundamentally different architecture from a web wrapper, which is another category of "lightweight" Slack clients that simply load app.slack.com inside a stripped-down browser window. A web wrapper reduces the memory footprint somewhat, but the page itself still runs full JavaScript and the rendering is still handled by a browser engine. msga does not take that shortcut.
Performance characteristics on macOS and Windows
Because msga is a compiled native application, its resource profile is in a different class from the official client. At idle it uses a fraction of the memory — roughly in the range of tens of megabytes rather than hundreds — and CPU usage sits near zero when you are not actively receiving or sending messages. Startup is fast enough that the window appears in under a second on typical hardware.
On macOS this matters in a specific way: the operating system can more aggressively swap Electron apps to disk when memory pressure rises, which introduces latency when you switch back to Slack after working in another app for a while. A lean native client stays resident without competing for the same pressure budget. On Windows the story is similar, particularly on machines where background processes already consume a meaningful share of available memory.
None of these are invented benchmark numbers — they follow directly from the architectural difference between a compiled C++ application and one that runs a browser engine to display its UI.
Current state and honest limitations
msga is open source under the GPL-3.0 license and is actively developed, but it is not a complete replacement for every Slack feature today. The project is candid about this on its GitHub page: some features are still on the roadmap, and users who depend on Slack Huddles, certain workflow integrations, or specific administrative views may find gaps.
What the application does cover is the core of what most people spend their time in: reading and sending messages, browsing channels and direct messages, and following threads. For individual contributors who live primarily in text-based communication, that coverage is often sufficient.
It is also worth noting that msga connects to Slack's APIs rather than scraping a web interface, which means it is not inherently more fragile than other third-party clients. API changes can still affect it, as they can any client, but there is no dependency on Slack's web page structure staying constant.
Installing msga on macOS and Windows
msga is available for macOS, Windows, and Linux. You can find the latest release and installation instructions at the download page or directly in the GitHub repository.
On macOS, the application follows a standard distribution model consistent with Qt6-based apps. On Windows, the compiled binary runs without requiring a separate runtime environment beyond what Qt packages with the build. For both platforms, the project's README covers the exact steps for either running a pre-built release or compiling from source if you prefer to build it yourself.
Building from source is a reasonable option for developers: the codebase is C++/Qt6, which is a well-understood stack, and the GPL-3.0 license means you can inspect, modify, and redistribute the code freely.
Who this is for
msga is a good fit for a specific kind of user: someone who works on macOS or Windows, uses Slack as a primary communication tool, and has decided that the resource cost of the official Electron client is not acceptable given their hardware or workflow. Developers running multiple memory-intensive tools simultaneously are the most obvious audience, but the same logic applies to anyone on older hardware or a machine with constrained RAM.
It is not the right choice for teams that require every Slack feature to be available on day one, or for users who rely heavily on Slack's newer real-time collaboration features. For those cases, the official client remains the complete option.
For everyone else, msga offers a meaningful trade: you give up some feature completeness at the edges, and in return you get a messaging client that behaves like a small, well-behaved desktop application rather than a background browser session.