BeeWare Toga: a Python GUI toolkit that draws with the platform's own widgets
A Python native, OS native GUI toolkit.
At a glance
- What is it?
- Toga is a BSD-3-Clause Python toolkit that maps one widget API onto Cocoa, GTK, WinForms, Android, iOS and the browser. It is a good fit when you want native controls and a BeeWare packaging path, and a poor fit when you need a widget the backends have not implemented yet.
- Who is it for?
- Adopt Toga if you are writing a new Python desktop or mobile app that should use the platform's own controls, and you are willing to check the platform documentation for each backend you target. Do not adopt it if you need a widget that only one backend implements, or if you need a stable cross-version API right now.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 27, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Toga is and who it is for
Toga describes itself as "A Python native, OS native GUI toolkit." The two halves matter. The API is Python, and the widgets are the ones the operating system already ships, so a Toga window on macOS is made of Cocoa controls, and on Windows it is made of WinForms controls. Toga does not paint its own buttons.
The audience is Python developers who want a desktop or mobile application rather than a web page in a window. The repository is part of the BeeWare suite, and the README points at BeeWare's membership page and Discord for community support. If you are already using BeeWare's Briefcase to package Python apps, Toga is the layer that draws the interface.
The project is not archived, and the last push to the default branch was on 2026-09-21. Releases are frequent enough to be worth tracking: v0.5.4 on 2026-05-06, v0.5.5 on 2026-07-02, and v0.5.6 on 2026-07-08. The version numbers tell you something the README does not: this is a 0.5 series, so the API is still moving between releases.
One API, many backends: how the repository is laid out
The top-level directory listing is the clearest explanation of the architecture. Alongside core/, toga/, travertino/ and docs/ sit cocoa/, gtk/, winforms/, android/, iOS/, qt/, textual/, web/ and dummy/. Each of those names is a backend: a package that translates the shared Toga API into the native toolkit of one platform.
core/ holds the API surface that application code imports. travertino/ is a separate layout package, which is why sizing and packing behaviour is defined in its own repository directory rather than inside core. dummy/ is a backend used for testing, and testbed/ is the test harness that exercises widgets across backends. The presence of a dummy backend is a design signal: Toga expects backend authors to implement the same interface, and it tests that expectation.
The practical consequence for you is that the API you write against is only as complete as the backend you run on. A widget can exist in core/ and in cocoa/ while being absent from winforms/. The README does not enumerate those gaps. It sends you to the platform documentation for the requirements and prerequisites of each backend, which is the only place the per-platform state is described.
Installing Toga and running the demo
The README's quickstart is deliberately short. It installs a demo package rather than the toolkit itself and then launches it, which gives you a window full of sample widgets without writing any code:
$ pip install toga-demo
$ toga-demoIf the install succeeds and the command runs, a GUI window appears with sample widgets. That is the fastest way to find out whether your machine has the native prerequisites Toga needs, because a missing system library usually shows up as an import error at this point rather than later in your own code.
The README's minimum requirements section does not list versions. It states that each backend has specific requirements and pre-requisites and links to the platform documentation at toga.beeware.org. Read that page for your target platform before you build anything, because the prerequisites differ per backend.
The repository also contains a demo/ directory with its own pyproject.toml and a demo/toga_demo/ package, and an examples/ directory. Those are in the source tree rather than on PyPI, so they are reference material for reading, not an install target.
What the documentation does not settle
The README is a signpost, not a specification. It gives the quickstart, points to Read the Docs for everything else, and lists community channels. It does not document the widget set, the layout rules, or the differences between backends. Anyone evaluating Toga from the README alone will overestimate how uniform the experience is.
The 0.5 version series is the other thing to weigh. Three releases landed between May and July 2026, and the API can change across them. The repository carries a changes/ directory, which is where release notes live, and that is the file to read before upgrading a shipped application. The README does not discuss upgrade or deprecation policy.
There is also a real cost to the native-widget approach. Because the controls come from the platform, Toga cannot smooth over differences the way a toolkit that draws its own widgets can. A layout that looks right on GTK may need adjustment on Cocoa. That is inherent to the design, not a bug, but it is the trade you accept.
When Toga is the wrong choice
Toga is the wrong tool if your application depends on a widget that only one backend implements. Nothing in the README or the repository layout guarantees parity across cocoa/, gtk/, winforms/, android/, iOS/, qt/, textual/ and web/. The directory names describe intent, not completeness. Check the platform documentation for your backend and confirm the specific widgets you need are supported there.
It is also a poor fit if you need a frozen, stable API today. A 0.5 series with releases weeks apart is a moving target, and the changes/ directory exists precisely because behaviour shifts between versions. If your project cannot absorb that, a toolkit that has stopped changing is a better match.
Finally, Toga is not a general-purpose rendering layer. If you want pixel-identical output on every platform, or you are building something that is really a web application, the native-widget model works against you. The toolkit's whole premise is that the platform's controls are the right controls.
Toga next to Kivy
The most common comparison question is Kivy versus BeeWare. The difference is architectural. Kivy draws its own widgets, so the same rendering code runs everywhere and the appearance is consistent across platforms. Toga delegates to the platform, so the appearance and behaviour follow the host operating system, and the toolkit has to maintain a separate backend for each one.
That trade runs in both directions. Kivy gives you one visual result and one set of widgets to learn; Toga gives you controls that behave the way users of that platform expect, including accessibility and input conventions that come from the native toolkit. Toga's cost is the backend matrix you can see in the repository root, and the risk that a widget you want has not been implemented on your target yet.
BeeWare also supplies Briefcase for packaging, which is why the two names appear together in search. If you want to ship a Python app as a native bundle, the BeeWare path covers packaging as well as the interface. Kivy has its own packaging story and a different widget vocabulary.
Licence, maintenance and what an upgrade costs
Toga is BSD-3-Clause, and the LICENSE file sits at the repository root. That is a permissive licence, which in practice means you can use Toga in closed-source applications as long as you keep the copyright notice and licence text. This is a description of the licence identifier, not legal advice; read LICENSE and your own organisation's policy before you rely on it.
Maintenance is visible in the repository rather than asserted in the README. The last push to main was on 2026-09-21, and the most recent tagged release is v0.5.6 from 2026-07-08. The project is not archived. That combination supports calling it maintained, but it also means you should expect to move with the 0.5 series.
The upgrade cost is concentrated in two places. First, the changes/ directory, which is where you find out what moved between v0.5.4, v0.5.5 and v0.5.6 before you bump a dependency. Second, the backend packages: because each platform has its own implementation, an upgrade can affect one target and not another, so testing on a single platform is not evidence that the others still work. The README does not document rollback, so pin your Toga version in your own dependency file if you need a known-good state.
Editorial conclusion
Adopt Toga if you are writing a new Python desktop or mobile app that should use the platform's own controls, and you are willing to check the platform documentation for each backend you target. Do not adopt it if you need a widget that only one backend implements, or if you need a stable cross-version API right now. Before committing, install toga-demo on every platform you plan to ship, then read the platform reference for that backend to confirm the widgets you need are listed.
Frequently asked questions
Which is better, Kivy or BeeWare?
They solve the problem differently. Kivy draws its own widgets, so the same rendering code runs everywhere and looks the same. Toga uses the platform's native controls, which means appearance and behaviour follow the host OS and the project maintains a separate backend for each platform. The right answer depends on whether you want consistent rendering or native controls.
How do I try Toga without writing any code?
The README's quickstart installs the demo package with pip install toga-demo and then runs the toga-demo command. That pops up a GUI window with some sample widgets.
Which platforms does Toga support?
The repository contains backend directories for cocoa, gtk, winforms, android, iOS, qt, textual and web, plus a dummy backend used for testing. The README says each backend has specific requirements and pre-requisites, and points to the platform documentation at toga.beeware.org for the details.
Where do I find what changed between Toga releases?
The repository has a changes/ directory at the top level, which is where release notes are kept. The README does not describe an upgrade or deprecation policy, so that directory is the place to check before moving between versions such as v0.5.4, v0.5.5 and v0.5.6.
What licence does Toga use?
Toga is BSD-3-Clause, and the LICENSE file is at the repository root. The README's badge also identifies the project as BSD-3-Clause.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/beeware-toga)