Kivy: A Python UI Framework for Desktop, Mobile and Embedded Targets

What Kivy actually replaces

The framework targets a specific gap: writing a Python interface once and running it on a desktop, a phone and a single-board computer without rewriting the drawing layer. The README states that Kivy is built on OpenGL ES 2.0 and that all widgets are built with multitouch support. That second detail matters more than it sounds. Most Python GUI toolkits inherit a mouse-and-keyboard event model and treat touch as a synthetic click. Kivy's widgets are written for multiple simultaneous touch points from the start, which is why gesture-heavy interfaces, drawing surfaces and kiosk panels are the applications where it fits naturally.

The intended audience, per the project description, is developers building GUI apps across desktop, mobile and embedded platforms, including Raspberry Pi OS. If your application is a data-entry form for internal Windows users, Kivy is a heavier answer than the problem. If your application needs to run on a tablet and a Raspberry Pi from one repository, the calculus changes.

The graphics pipeline and the KV language

Kivy is written in Python and Cython, with the Cython layer wrapping the OpenGL ES 2.0 calls. Widgets are drawn rather than delegated to a platform toolkit, so a button in Kivy is geometry and a texture, not a Windows or Cocoa control. That is the source of both the portability and the visual uniformity: the app looks the same everywhere, and it looks like Kivy.

Layout and bindings are usually expressed in KV, the declarative language that ships with the framework. The repository keeps a dedicated examples/kv/ directory, and the style is a rule per widget class with properties and event handlers. KV is optional in the sense that you can build the same tree in Python, but the binding syntax is where the framework saves the most code, because property changes propagate to the widgets that reference them without manual wiring.

The sibling projects listed in the README fill in the platform gaps: Plyer for a platform-independent API to hardware features, PyJNIus for Java classes over JNI on Android, Pyobjus for Objective-C classes on iOS, and Audiostream for direct microphone and speaker access. None of these are part of the core install, and each carries its own platform constraints.

Installing Kivy and running a first window

The README points to https://www.kivy.org/docs for installation instructions, tutorials and the API reference, and notes that a PDF version of the documentation exists. It does not reproduce the commands. What the repository does show is the build system: pyproject.toml requires setuptools, wheel, packaging and cython between 0.29.1 and 3.2.0, and declares requires-python as >=3.11. The Makefile defines a build target that installs the package in editable mode.

The project is distributed on PyPI, and the related searches around Kivy include the pip install path. The command below installs the released package into the active interpreter:

python -m pip install kivy

If you are working from a clone rather than a release, the Makefile's build target is the documented route:

make build

That target runs pip install -e . with the build options the Makefile assembles. Expect a Cython compile step, which is why a source build takes noticeably longer than a wheel install. Once either route finishes, the repository ships an examples folder that is the quickest way to confirm the install before you write your own application.

Shipping to Android and iOS is a separate toolchain

This is the part that surprises people. Kivy itself does not produce an APK. The README lists Buildozer as a development tool for turning Python applications into binary packages, Python for Android as the tool that packages Python apps into Android binaries, and Kivy iOS as a toolchain that compiles the necessary libraries and manages Xcode project creation. Those are separate repositories with separate release cycles.

On Windows, pyproject.toml pulls in kivy_deps packages for gstreamer, sdl3 and glew, both the runtime and the _dev variants, as build requirements. That is a real dependency surface, and it is the reason a Kivy install on Windows can fail for reasons that have nothing to do with your code. The Makefile also carries an ios target with a hardcoded path to iPhoneOS platform tools and a Python 2.7 hostpython reference, which is a reminder that parts of the build tooling age at a different rate than the framework.

If your target is Android, budget time for the packaging step before you commit to the framework. The framework install is a pip command; the mobile build is a project.

Where Kivy is the wrong tool

Kivy draws its own widgets, so it does not give you native controls. A macOS or Windows application built with Kivy will not pick up the system menu bar, the native file dialog styling, or the accessibility behaviour that users of those platforms expect from a desktop app. If your requirement is a native-feeling desktop application, a toolkit that wraps the platform's own widgets is a better starting point.

The packaging chain is the second limitation. Because Android and iOS output depends on Buildozer, Python for Android and Kivy iOS rather than on the core repository, a Kivy mobile project inherits the maintenance state and platform compatibility of all of them. An upgrade to a new Python version can move the framework forward while leaving the mobile toolchain behind, and the pyproject.toml floor of Python 3.11 means older interpreters are simply out.

The third is the rendering model itself. Everything goes through OpenGL ES 2.0, which is excellent for animation and custom drawing and unnecessary overhead for a form with twelve text fields. Reaching for Kivy because it is written in Python, when the interface is conventional, trades a solved problem for a new one.

Kivy compared with a widgets-first Python toolkit

The clearest alternative in the Python ecosystem is a toolkit that binds to the platform's native widget set instead of drawing its own. The difference is architectural, not cosmetic. A native-binding toolkit delegates rendering and input to the operating system, so your application inherits system theming, native dialogs and platform accessibility for free, and the binary stays small because the drawing code is already on the machine. Its cost is that the same interface behaves and looks differently on each platform, and that touch input is usually an afterthought.

Kivy inverts both properties. You get one consistent rendering path and first-class multitouch, and you pay for it with a non-native look, a larger runtime, and a mobile packaging pipeline that lives outside the core repository. Neither approach is better in the abstract. A tool that must run identically on a Raspberry Pi panel and an Android tablet is a Kivy problem. A tool that must look like it belongs on the user's desktop is not.

Licence, releases and what upgrades cost

Kivy is released under the MIT License, and pyproject.toml carries license = "MIT" with the LICENSE file listed in license-files. MIT is permissive, so the framework itself does not impose source-disclosure obligations on your application. Two bundled assets are under different terms and are worth checking if you redistribute them: the README states that the Roboto and Roboto Mono fonts are distributed under the Apache License 2.0, and that the DejaVuSans font used for the virtual keyboard has its own licence. The README also states that the current UI design was adapted from Moblintouch theme SVGs under LGPLv2.1. That is a note about attribution and redistribution, not legal advice; read the LICENSE file and the linked font licences before shipping.

On releases, the repository shows 2.3.1 dated 2024-12-26, 2.3.0 dated 2024-01-05 and 2.2.1 dated 2023-06-17. The last push to the default branch was on 2026-09-18, so the codebase is moving between releases even when tagged versions are months apart. Upgrading across minor versions means rebuilding the Cython extensions, which the Makefile's build target handles, and re-checking the kivy_deps versions pinned in pyproject.toml on Windows. If you pin Kivy in a requirements file, pin the kivy_deps packages alongside it.

Editorial conclusion

Adopt Kivy when you want one Python codebase for desktop and mobile, and when your interface is custom-drawn rather than native-looking. Do not adopt it for a conventional desktop form with native menus and OS widgets, or if you cannot take on the mobile packaging toolchain. Before committing, install the released package with python -m pip install kivy in the Python version you actually target, confirm that a window opens from the examples folder, and then test a Buildozer build for your Android target, because that step, not the framework itself, is where projects usually stall.

Frequently asked questions

Official sources

1. kivy/kivy on GitHub
2. License: MIT
3. Project website
4. README
5. Releases