Telegram Desktop: six packaged platforms, a Docker Linux build, two crash reporters

A C++ Qt application that speaks MTProto, with no library to import

The repository holds the complete source code for the official Telegram desktop client, built on the Telegram API and the MTProto secure protocol. That first line is the whole scope, and it settles one common reason to look at the project: there is no reusable library here, no server component, and no documented way to point this client at a different backend. If the goal is embedding messaging into a product of your own, this tree answers nothing.

The interface layer is Qt 6, with Qt 5.15 listed beside it and described as slightly patched. Two Qt majors in one dependency list is the shape of a codebase old enough to carry a fallback path, and it is the first sign that the project spans operating systems whose own support windows do not line up.

The rest of the dependency list serves the same purpose, which is keeping a native client running on a machine the user already owns. Breakpad and Crashpad handle crashes. WebRTC is present for real-time media, and FFmpeg with the Opus codec sit in the tree alongside it. Hunspell is a spell checker for the text interface, and two fonts are vendored for the interface itself, Open Sans and Vazirmatn.

Which of those is wired into any given build is not explained by the project documentation, and for a reader deciding whether to compile this, that is the first gap worth knowing about.

The build section is three links, and the Linux one is a container

Build instructions come as three links: a Windows document covering 32-bit and 64-bit, a macOS document, and a GNU/Linux document described as using Docker. There is no package line, no configure step and no compiler version in the readme itself, so a first-time builder is sent to those documents to find out what the build requires.

The split inverts a familiar expectation. Linux is the platform with a reproducible environment provided, and the two desktop platforms are documented procedures you follow on hardware you configure yourself. Contributors get the lowest-friction route on the platform with the least local variety.

The tools underneath show up in the third-party list rather than in the instructions. CMake, Ninja and GYP all appear, alongside Google Breakpad and Google Crashpad. GYP predates most current tooling, and having it listed next to CMake and Ninja suggests parts of the tree are still assembled by different means rather than having been moved onto CMake in one pass.

For a team planning a source build, budget the Docker path first and treat the two desktop documents as unknown-cost work until they have been read.

GPLv3 with an OpenSSL exception is the clause to read before redistributing

The licence line reads GPLv3 with an OpenSSL exception, with the licence file linked from the readme. The exception has an obvious cause: OpenSSL 3.2.1 is under the Apache License 2.0, and the two do not combine on their own. Its practical effect is that the copyleft obligation covers your modifications while the cryptographic library keeps its own terms.

The dependency list is the inventory that matters when you redistribute a build, and it mixes licensing regimes freely. The copyleft entries include Qt 6 and Qt 5.15 under LGPL, along with FFmpeg, OpenAL Soft, Hunspell and zlib. Most of the rest are permissive, from Range-v3 under the Boost licence and Ada under Apache 2.0 down to LZMA SDK 9.20 with liblzma in the public domain. Two font licences sit in the list as well, Open Sans under Apache 2.0 and Vazirmatn under the SIL Open Font License 1.1.

None of this is a legal opinion. What it does tell an engineer is that a licence scan of this tree returns a long tail rather than one clean answer, and that the component-to-licence mapping is written down in a single place, which is more than most projects of this size offer.

Two Google crash reporters in one dependency list, and no documented switch

Google Breakpad and Google Crashpad are both named among the third-party libraries. Breakpad is the older project and Crashpad its replacement, and carrying both in one tree is what happens when a codebase has to keep build systems and platforms that predate the switch. Whether that means one pipeline or two is not stated anywhere in the project documentation.

That silence lands badly on a managed workstation. Crash handling is one of the first things a security review asks about, and the readme offers no configuration key, no environment variable and no documented way to disable either reporter. A reviewer who needs an answer has to read the CMake tree and the build scripts instead of the project's own docs, and the LEGAL file at the repository root is listed without being summarised anywhere.

The same gap shows up around the rest of the outbound surface. No update-check toggle, no usage reporting switch and no statement of what a build sends where appears in the readme. Absence of documentation is not evidence of misbehaviour, and nothing here claims the binary misbehaves. It does mean the answer is not where a reviewer looks first, so that question belongs in your own audit rather than in a support channel.

Windows 7 is the floor: portable archives, a snap, a Flathub package, three frozen builds

The supported systems list holds six targets: 64-bit Windows 7 and above, 32-bit Windows 7 and above with a portable variant for each, macOS 10.13 and above, a static 64-bit Linux build, a Snap package and a Flatpak. Linux gets three answers, and they differ in packaging approach rather than in features.

Below that sits an old system versions section that is the most useful part of the readme for anyone deploying. Three versions are named as the last that supported something, each with its own download. Version 4.9.9 is the last for macOS 10.12 and for a static Linux build against a glibc older than 2.28. Version 2.4.4 is the last for two older macOS releases and for a 32-bit Linux static build. Version 1.8.15 is the last for Windows XP and Vista and for four macOS releases, with a portable variant.

The consequence for a reader is blunt. A machine on Windows XP or macOS 10.12 is not getting a slower client, it is getting a client that stopped receiving code changes years ago, and the readme does not promise security fixes for those archives the way a current platform gets them. Nothing on the page states how long those binaries are kept online either, so treat each link as something that can disappear.

Choosing between Snap and Flatpak is a policy decision about the workstation rather than a technical one. An image joined to a Flathub policy gets the Flathub build, and a desktop built around snapd gets the snap. Running both on one machine is where two confinement systems start competing for the same application data and update path.

The default branch is dev, and the tree now carries agent instruction files

The default branch is dev rather than a release branch, and the recent tags are v7.2.10 on 2026-09-27, v7.2.9 on 2026-09-17 and v7.2.8 on 2026-09-10. The last push was on 2026-09-29. That cadence is what a client application with a real release pipeline looks like, and it has a practical effect: building from the default branch gets you the development line, not something you can compare against a shipped binary.

The root shows the shape of a large, long-lived C++ project. A CMakeLists.txt at the top, Telegram/ for the client itself, lib/ for the dependencies, plus cmake/, tools/, tasks/, docs/, snap/ and a changelog.txt. A .gitmodules file means a fresh clone is incomplete until its submodules are pulled, and a .clang-tidy file sits alongside it for static analysis.

More interesting are the entries that are not code. AGENTS.md, CLAUDE.md, GROK.md and REVIEW.md sit in the root, together with directories named .agents/, .claude/ and .grok/, and a .devcontainer.json. Instruction files aimed at coding agents and a review policy document now live in the same tree as the build, and the readme credits a commercial GitHub Actions runner provider for the CI infrastructure. Nothing in the documentation explains how those files are meant to be used, so for a contributor they are the least explained part of an otherwise well signposted repository.

Where the native client is the wrong answer

A browser-based Telegram client and this native application solve the same problem by different means. The browser path runs against the same Telegram API and MTProto servers but keeps nothing as a native process on the workstation, which removes the install, the update and the crash-reporting question in one move. The native path gives you a real desktop window and system-level integration, and asks you to manage a native process in exchange.

One thing does not change between those options. The protocol is named rather than described, so this is a client for one service and cannot be pointed at a self-hosted server, and the readme makes no claim that it can. A team that needs a self-hosted or custom-protocol messenger should stop reading this readme and look at a different project.

The same rule holds for the platform cases. If the target is Windows XP, a 32-bit Linux box, or a distribution whose glibc is older than 2.28, the decision has already been made for you in the frozen version list, and no amount of work on the current tree changes it.

Editorial conclusion

Take a packaged build if you need Telegram on a desktop now: three releases landed in September 2026 and the last push to the dev branch was 2026-09-29, so the current line is not where the risk sits. Do not start a source build expecting a short job, because the Linux instructions are Docker based, the Windows and macOS procedures live in separate documents, and a fresh clone is missing its submodules until they are pulled. Before putting this client on a locked-down workstation, find in the CMake tree which of Google Breakpad or Google Crashpad is compiled in, since the project publishes no switch for either.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes