pythonnative 0.54.0

Build native Android and iOS apps in Python.

Documentation · Getting Started · Examples · Contributing

Overview

PythonNative is a cross-platform toolkit for building native Android and iOS apps in Python. It provides a declarative, React-like component model with hooks and automatic reconciliation on top of a shared C++ renderer core that iOS, Android, the browser preview, and headless tests all run. Write function components with use_state, use_effect, and friends, just like React, and let PythonNative handle creating and updating native views.

Features

• Declarative components and hooks: Describe native UI with Python functions, immutable elements, and typed styles. State, effects, context, and suspense boundaries follow one logical application tree across screens, overlays, and mounted list rows. State updates batch automatically, effect errors reach the nearest error boundary, and event callbacks receive typed records instead of dicts.
• React Native's core surface: Pressable, ScrollView, Text, TextInput, Image, Modal, FlatList, and SectionList carry the props a React Native developer expects (disabled state and ripples, content insets and snapping, ellipsize modes and pressable spans, controlled selection and key events, sticky headers and inverted lists), plus typed imperative handles on ref.current and the full accessibility prop set.
• Native widgets and layout: Swift and Kotlin component managers own UIKit and Android widgets. The renderer core validates commits, lays out with Yoga off the UI thread using platform measurements for text and intrinsic sizes, and skips mounting layout-only wrappers.
• Standard asyncio: Components, effects, event handlers, and tasks run on a dedicated Python application thread. Native UI threads handle widgets, scrolling, animation frames, and worklets. Component-owned tasks are canceled on unmount.
• Incremental reconciliation: State changes update affected component subtrees. Versioned bridge commits validate operations and acknowledge revisions; events and controlled text inputs carry identities that prevent stale updates.
• Typed, Pythonic authoring: Components return pn.Node and their signatures are their props, so a strict type checker verifies element trees and conditional children. Screens are components whose parameters are their route params (nav.push(ItemScreen(id=42))), navigators are module-level values with deep links derived from each screen's path, one Theme dataclass styles the app and its navigators, StyleSheet namespaces give styles typed names, and pn.Store holds app state with selector-based re-renders. pn lint checks the rules of hooks and that worklets compile.
• Native lists and navigation: UIKit collection views and Android recycler views recycle cells for fixed or variable row sizes, grids, sections, and horizontal lists. Native navigation containers present logical screen roots at every nesting level while providers and component state remain in the shared Python tree; navigators take screen options, groups, tab-bar styles, and a navigation ref usable outside components.
• Motion: Interaction logic runs on the UI thread as worklets, ordinary type-checked Python functions marked @pn.worklet that the renderer core compiles and runs, so a drag keeps tracking and a release decides where to settle while Python is busy. Shared values, with_timing, with_spring, and with_decay animations (awaitable from Python), and animated styles drive paint and layout properties; scroll events and gesture callbacks take worklets; entering=, exiting=, and layout= animate views as the tree changes, including native list rows; and shared_tag= flies an element between stack screens. BottomSheet, Swipeable, and a drawer that follows the finger are built on it. Gestures activate with Gesture Handler-style offsets and composition.
• Assets and graphics: Drop images, fonts, and SVGs under app/assets/ and reference them by path. Density variants, bundled fonts, a vector Icon set, Svg drawing, gradients, and blur render natively on both platforms and in the browser preview.
• Device APIs: Python facades expose storage, permissions, keyboard, dimensions and pixel ratio, device info, localization, accessibility settings, haptics, and other native services in every app, with a Python fallback for headless tests. Test permissions and platform behavior on your deployment targets.
• First-party capabilities: Video, audio, camera, maps, location, notifications, push, pickers, sensors, biometrics, background tasks, and in-app purchases ship in the package and compile into your app only when you list them: [plugins] use = ["camera", "maps"] in pythonnative.toml, then from pythonnative.camera import CameraView. An app that doesn't list one contains none of its code, and calling it raises plugin_not_enabled. Simulators can't prove everything here: camera capture on iOS, remote push, and purchases need real hardware or store credentials.
• Networking: pn.fetch handles JSON, multipart uploads, streamed responses, and upload progress, and pn.WebSocket is a pure-Python RFC 6455 client used as an async context manager and iterator, so it behaves the same on device, in tests, and in the preview.
• Native extension SDK: Python dataclasses and protocols define contracts; define_component returns a typed element factory and pn codegen generates props and module adapters for Swift and Kotlin. Plugins package native sources and resources, change Info.plist, entitlements, the privacy manifest, the Android manifest, and Gradle through a declarative manifest, and observe app lifecycle events. Builds verify matching contracts at startup.
• Testing library: pythonnative.testing renders components headlessly with Testing Library-style queries (get_by_role, get_by_placeholder_text, within, find_by_*), a virtual clock for timers, and a pytest plugin that resets the runtime between tests.
• PythonNative Go: a prebuilt dev client, published with each release, runs any project without native code, so the project itself is never compiled. i / a in pn start open it on the iOS Simulator (which still needs Xcode installed) or an Android emulator, and a phone with Go installed opens the project by scanning the QR code pn start prints. Go isn't in the app stores: Android phones install the APK, and iPhones need Go built and signed with your Apple team. Go carries every first-party capability except push. Projects that use push or add other native code run in their own debug build, which pn run rebuilds only when something native changes.
• DevTools and debugging: pn start serves DevTools, with a component tree showing props and hooks (and editable state), a console with a REPL inside the running app, problems with component stacks and source excerpts, network requests, and live performance with trace capture. VS Code attaches debugpy breakpoints to Python on the preview, a simulator, or a phone. On device, a dev menu (shake or Cmd+D) offers reload, an element inspector, and a performance monitor, and errors show a screen with the component stack and your source.
• Development tools: Fast Refresh preserves compatible component state, pn lint checks the rules of hooks, and pn init scaffolds tests, type checking, debugger settings, and CI.
• Browser preview: pn preview runs your Python application against DOM widgets mounted by the same renderer core, compiled to WebAssembly. It supports iteration on application logic and UI; fonts, platform controls, and device APIs require mobile testing.
• App packaging and dependency locks: pn run and pn build stage bundled app templates, native libraries, and Python sources. Target-specific wheel locks record dependency versions and hashes for mobile builds. Binary dependencies need compatible mobile wheels; pn deps reports target resolution.
• Store release: pn build stops a release that a store would reject (no icon, no signing, a missing usage string) and validates the artifacts, pn run --release runs the release configuration on a simulator or emulator, pn submit uploads to App Store Connect and Google Play with credentials from the environment, and pn links prints the files a site hosts for universal links and app links. CI builds and runs release artifacts and tests pn submit against fakes, but no real store submission has been verified yet, so treat your first upload as the first true test.
• Production failure handling: pn.set_error_handler receives every uncaught error with its phase, which is where a crash reporter attaches. In a release build, a render error no boundary catches shows a fallback screen with a retry button, which pn.set_error_fallback replaces, and a failed mount remounts the screen once before falling back.

Quick Start

Installation

Requires Python 3.13 or newer.

pip install pythonnative

Usage

import pythonnative as pn


@pn.component
def App() -> pn.Node:
    count, set_count = pn.use_state(0)
    return pn.Column(
        pn.Text(f"Count: {count}", style=pn.style(font_size=24, bold=True)),
        pn.Button(
            "Tap me",
            on_press=lambda: set_count(count + 1),
        ),
        style=pn.style(gap=12, padding=16),
    )

Develop

pn init my-app && cd my-app
pn start            # dev server: scan the QR code, or press i (iOS), a (Android), w (browser), j (DevTools)
pn run ios          # the project's own debug build, for projects that add native code
pn build ios        # standalone release artifacts
pn submit ios       # upload the latest release build

Documentation

Visit pythonnative.com for the full documentation, including getting started guides, platform-specific instructions for Android and iOS, API reference, and working examples.

Contributing

Contributions are welcome. Please see CONTRIBUTING.md for setup instructions, coding standards, and guidelines for submitting pull requests.

License

MIT