Kivy Overview
Kivy is a Python library for building multi-touch applications that run on desktop, Android, and iOS from a single codebase. Its distinguishing bet is that the UI is written in a declarative language (KV) rather than built imperatively in Python - you describe the widgets and their layout, and Kivy instantiates them - while a property-and-event system keeps the behavior reactive. The result is a tool that is unusually compact for touch-first apps: a working multi-screen app is often a hundred lines of KV and a few event handlers. This tutorial builds from the first window to packaging, and the mental model to carry throughout is one sentence: widgets are objects with properties, layout is a tree, and behavior is events bound to property changes.
What Kivy Gives You
| Layer | What it is | Chapters |
|---|---|---|
| Core widgets | Button, Label, Image, TextInput, Slider, and the rest | core-widgets |
| Layouts | BoxLayout, GridLayout, FloatLayout, StackLayout - the tree that arranges widgets | layouts |
| Events | on_press, on_text, touch handling - how the app reacts | event-system |
| Properties | reactive state: a value change propagates to bound widgets | properties-binding |
| Canvas | direct 2D drawing: lines, rectangles, instructions | canvas-graphics |
| Screens | ScreenManager and Screen for multi-page apps | screens-navigation |
| Animation | Animation, LoopAnimation, transitions | animation |
Everything in Kivy derives from Widget: it has a position, a size, a canvas to draw on, and it participates in the layout and event systems. Buttons are widgets, labels are widgets, and the layouts that arrange them are widgets - the uniformity is the point, and it is what makes the KV language able to describe the whole UI in one notation.
Why Kivy (and What It Is Not)
Kivy is the right tool when the app is touch-first - a tablet kiosk, a game, a media controller, a data-entry device - and when one codebase must reach phones and desktops. It is not the right tool for a conventional desktop form app where native-looking widgets and a standard platform feel matter; for that, the Qt- and GTK-based frameworks in the companion tutorials are the better fit. Kivy's UI is custom-drawn (it renders its own widgets, so they look the same on every platform), which is a feature for a brand-consistent touch app and a cost when you want the OS look. The honest comparison: Kivy trades native appearance for cross-platform touch and a declarative, rapid UI style.
Tutorial Roadmap
- Setup and the first app: the window, the
Appclass, and the KV file that describes the UI. - The KV language in depth - widgets, rules, the id property, and how Python and KV interoperate.
- Core widgets and the layouts that arrange them - the two vocabularies of every Kivy UI.
- The event system and property binding - the reactive core that makes the UI respond.
- Animation, screens and navigation - building a real multi-page app.
- The Canvas and custom widgets - drawing and extending the toolkit.
- Practical app concerns: data-driven UIs, networking, file storage, threading, and media.
- Packaging, the Kivy Garden ecosystem, and the design rules that keep it maintainable.
Conventions
Examples are runnable Kivy 2.x apps with no dependencies beyond Kivy itself; each is a complete main.py you can run with python main.py. KV snippets are shown in language-kv blocks. The running example across the middle chapters is a small recipe manager - a list, a detail view, and an add form - which gives the layout, event, and screen chapters a shared shape to build on. Names follow Kivy's own: widgets are CapWords, properties and ids use snake_case, and the KV rule blocks are where the UI lives.
Summary
Kivy builds multi-touch apps for desktop and mobile from one Python codebase, with the UI declared in the KV language rather than constructed in code. The model that makes the rest of the tutorial coherent: everything is a Widget, layout is a tree of container widgets, state is properties that propagate to bound widgets, and behavior is events - touch, button press, text change - handled by methods you attach. Choose Kivy for touch-first, cross-platform UIs where a consistent custom look is an asset; choose a native toolkit when the platform appearance is the requirement. The next chapter gets the first window running, and the pattern you see there - an App subclass plus a KV file - is the skeleton every later example reuses.