Highlights in this release:

• Flet docs are back on Docusaurus - fast dev server, working hot reload, unified website.
• Meet CrocoDocs, our new tool that bridges Python docstrings and Docusaurus.
• All 466 Flet examples migrated to standalone projects with rich metadata for Gallery and AI discovery.

How to upgrade​

If you use pip:

pip install 'flet[all]' --upgrade

If you use uv with pyproject.toml and want to upgrade everything:

uv sync --upgrade

If you want to upgrade only Flet packages:

uv sync --upgrade-package flet \
  --upgrade-package flet-cli \
  --upgrade-package flet-desktop \
  --upgrade-package flet-web

Goodbye, MkDocs! Hello, CrocoDocs!​

The Flet website has always been built on Docusaurus - it's fast, extensible, and has great MDX support. But we were authoring API docs manually, which caused synchronization issues with the source code and a lot of duplication: we'd write the same content in Python docstrings and then again in Docusaurus pages.

For Flet "v1", @ndonkoHenri made a huge push by moving all API docs into Python docstrings and configuring MkDocs + Material for MkDocs + mkdocstrings to serve Flet documentation. It was a great and timely decision to make docstrings the single source of truth.

And it worked, but with some quirks:

• Flet has a large codebase with many cross-references. The docs dev server took around 3 minutes to start.
• For some reason, hot reload was not working - which meant making a change, restarting, and waiting another 3 minutes to see the result!

Then, one day, we saw this warning in a build log and got a feeling that something was off:

Apparently, there is a whole story that has been developing for a few years. The short version: the MkDocs original author started working on MkDocs 2.0 which drops plugin support and is not compatible with MkDocs 1.x. The Material for MkDocs team started working on Zensical, a MkDocs rewrite in Rust that is backward-compatible but launched with many plugins still missing.

We decided to bring docs back to Docusaurus - but this time with a tool that keeps docstrings as the single source of truth.

Meet CrocoDocs​

CrocoDocs is our home-grown tool that transforms Flet API data into a form that Docusaurus can render. The idea is simple: extract API information from Python docstrings using Griffe, produce JSON data and MDX partials, and let Docusaurus render everything using custom MDX components and remark plugins.

The pipeline looks like this:

1. Extract - Griffe parses all Python packages and collects classes, functions, docstrings, and type annotations.
2. Transform - CrocoDocs builds an api-data.json with all API entries and a cross-reference map (xref_map) that resolves symbol names to documentation URLs.
3. Generate - MDX partials are produced for CLI docs, permissions, and the PyPI package index. Code examples are indexed from the examples directory.
4. Render - Docusaurus picks up the generated data and a custom remark plugin resolves cross-references into clickable links.

It's a modern Python project, managed with uv and configured entirely via pyproject.toml.

New cross-reference format​

We switched from mkdocstrings-python-xref format to reST-style roles in docstrings. This was a deliberate choice: reST roles are a well-known standard, and - crucially - they are navigable in VS Code and other editors that render docstring tooltips.

Before (mkdocstrings):

"""See [Page][flet.] and [Control.visible][flet.] for details."""

After (reST roles):

"""See :class:`~flet.Page` and :attr:`flet.Control.visible` for details."""

The supported roles are :class:, :attr:, :meth:, :func:, :mod:, :data:, and :obj:. The ~ prefix shortens the display name - :class:~flet.Page`` renders as just "Page" while still linking to the full path.

Here's what it looks like in VS Code - docstring links are rendered and navigable right in the tooltip:

Strict CI checks​

In addition to the broken-link checks that Docusaurus performs during build, we added a custom CI script with strict validation:

• Broken images - verifies that every <img src="..."> points to an existing file.
• Unresolved reST xrefs - catches any :class:, :attr:, :meth: markers that were not resolved to links.
• Missing code examples - flags <CodeExample> components that reference non-existent example files.
• Missing API entries - detects symbols referenced in docs but absent from api-data.json.

If any check fails, the build fails. No broken docs make it to production.

The results​

The migration from MkDocs to Docusaurus brought exactly what we hoped for:

• The generate phase and Docusaurus dev server start in a few seconds (down from ~3 minutes).
• Hot reload works. Change a page, save, see the update.
• A single unified website for the landing page and docs, with a modern design.
• Full-text search with Algolia.
• A tool we own and can evolve as Flet grows.

CrocoDocs is not yet available on PyPI, but if you'd like to adopt it for your Python project - let me know!

More info:

• PR: #6359

Examples migrated to projects​

Every Flet example is now a standalone project with its own pyproject.toml and rich metadata. Here's why we made this change:

Better discovery. Each project carries structured metadata - categories, description, keywords, a list of controls used, complexity level, and more. We need this data for building Gallery v2 (available on the website and as a Flet app) and for building the index for Flet MCP, so AI assistants can find the right example for you.

Easier to build and run. Previously, if you wanted to try an example, you'd copy it into your own project, figure out the dependencies, and wire things up. Now every example is a complete project you can clone and run directly with flet run.

Self-contained. Every project includes all its dependencies (flet_charts, flet_map, etc.), permissions, bundle IDs, and assets needed to successfully build and run on any platform.

What a project looks like​

Before - a flat Python file with no metadata:

sdk/python/examples/controls/
├── button_examples.py
├── canvas_examples.py
└── ...

After - a structured project directory:

sdk/python/examples/controls/
├── button/
│   ├── basic/
│   │   ├── main.py
│   │   └── pyproject.toml
│   ├── icons/
│   │   ├── main.py
│   │   └── pyproject.toml
│   └── styling/
│       ├── main.py
│       └── pyproject.toml
├── canvas/
│   ├── bezier_curves/
│   ├── brush/
│   └── ...

Each pyproject.toml includes Gallery and MCP metadata:

[project]
name = "button-basic"
version = "1.0.0"
description = "Basic enabled and disabled Button examples."
keywords = ["button", "material", "basic", "disabled"]
dependencies = ["flet"]

[tool.flet.gallery]
categories = ["Buttons/Button"]

[tool.flet.metadata]
title = "Basic button"
controls = ["SafeArea", "Column", "Button"]
layout_pattern = "inline-actions"
complexity = "basic"
features = ["enabled and disabled states"]

In total, 466 examples were migrated to this format.

More info:

• PR: #6355

Conclusion​

Flet 0.84.0 is about the ecosystem around the framework: better docs, better examples, better tooling. CrocoDocs gives us a documentation pipeline we can trust and evolve. Standalone example projects make every sample discoverable, runnable, and ready for AI-assisted workflows.

Try it and share feedback in GitHub Discussions or on Discord.

Happy Flet-ing!

Highlights in this release:

• Up to 6.7× faster control diffing for both imperative and declarative apps.
• Smarter .update() logic that eliminates redundant updates.
• Declarative field validation with Annotated types.
• Desktop binaries and build templates moved from PyPI to GitHub Releases - smaller installs, pinned versions.
• Better release traceability with milestones and pre-releases on GitHub.

How to upgrade​

If you use pip:

pip install 'flet[all]' --upgrade

If you use uv with pyproject.toml and want to upgrade everything:

uv sync --upgrade

If you want to upgrade only Flet packages:

uv sync --upgrade-package flet \
  --upgrade-package flet-cli \
  --upgrade-package flet-desktop \
  --upgrade-package flet-web

Faster control diffing​

Every time your app calls page.update() or rebuilds a declarative component, Flet computes a diff - the set of property changes to send to Flutter. In 0.83.0 we overhauled this mechanism for both programming styles, and the results are dramatic.

Imperative apps​

Before: every page.update() walked through all properties of every control and compared them to the previous snapshot - even properties you never touched. If your control has 20 properties and you changed one, Flet still compared all 20.

After: a new Prop descriptor tracks which properties were actually written since the last diff. When you set button.text = "Click me", only text is flagged as dirty. On the next page.update(), Flet sends only the dirty properties to Flutter and skips the rest. Think of it like only checking the light switches you actually flipped, instead of walking through every room in the house.

Declarative apps​

Before: when a component rebuilt, Flet compared every field of the new control tree against the old one - including nested value objects like Alignment, BorderRadius, and BoxDecoration. Since these objects were recreated on every build, they always looked "new" even when nothing changed.

After: ~150 data types now use a new @value decorator that makes them comparable by content rather than identity. Combined with a two-pass diff that first checks structural changes and then compares only fields that actually differ, the diff skips unchanged subtrees entirely.

Benchmarks​

Measured on Python 3.14.2, Apple Silicon:

• Frozen controls with 20 fields, 2 changed: 3.2–3.4× faster (100–300 controls).
• Mixed keyed/unkeyed lists: 1.9–2.0× faster.
• Non-frozen rebuilt lists: 2.9–4.5× faster.
• Sunflower demo (500 seeds): 6.7× faster.

More info:

• PR: #6296

Smarter .update() logic​

In previous versions, Flet automatically called page.update() at the end of every event handler. If your handler already called .update() explicitly - say, to show a spinner before starting work - the framework would fire a second, redundant update at the end. This double-update could cause visual glitches or wasted work.

0.83.0 tracks whether .update() was called during handler execution. If it was, the automatic update at the end is skipped. This also means that apps migrated "as is" from Flet 0.28.3 (where there was no auto-update) will behave as expected without changes.

More info:

• PR: #6298
• Issue: #6236

Declarative field validation​

Control fields can now declare validation rules inline using Python's Annotated types and a new V rule set. Instead of writing manual checks in __init__ or before_update(), you express constraints declaratively:

from typing import Annotated
from flet.core.validation import V

entries: Annotated[list, V.or_(V.empty, V.min_length(3))]

This keeps validation close to the field definition and makes it easier to reason about invariants at a glance. Deprecation warnings also get auto-generated admonitions in the docs, so deprecated fields are clearly flagged without manual documentation effort.

More info:

• PR: #6278

Packaging: client binaries to GitHub Releases​

Until now, Flet desktop binaries (the Flutter client for Windows, macOS, and Linux) were bundled inside PyPI wheels. This made the wheels large and consumed significant PyPI storage. We can't ask PyPI team for storage increase forever! 😊

Starting with 0.83.0, the desktop client is downloaded on first run from GitHub Releases and cached locally at ~/.flet/client/. The flet-desktop package is now a single, tiny, platform-independent wheel.

What this means for you:

• Faster installs. pip install flet downloads a small wheel instead of a platform-specific binary.
• One package. The separate flet-desktop-light package is gone - choose the "light" or "full" flavor via FLET_DESKTOP_FLAVOR env var or [tool.flet] in pyproject.toml. On Linux the "light" flavor is used by default if not specified.
• Air-gapped setups. Set FLET_CLIENT_URL to point at a local mirror if your environment can't reach GitHub.

More info:

• PR: #6309

Packaging: templates to GitHub Releases​

The flet-build-template and flet-app-templates repositories have been consolidated into the main Flet monorepo and are now distributed as zip archives attached to each GitHub Release.

When you run flet build or flet create, the CLI downloads the template zip that matches your installed Flet version. Versions are pinned - even for pre-releases - so you always get templates compatible with your Flet version. No more mismatches between the framework and the build template.

For stable releases, the flet Flutter package is published to pub.dev as usual. For pre-releases, the build template references the exact commit SHA via a Git dependency - so flet build always compiles against the precise Flutter code that matches your Python package.

More info:

• PR: #6331

Better release traceability​

We've improved how you can track what's in each release:

• Pre-releases on GitHub. Every dev build now creates a GitHub Release (e.g., v0.83.0.dev6045). You can browse pre-releases to see exactly which fixes and features landed in each build - no more guessing whether your bug fix is in the latest dev version.
• Milestones on issues and PRs. Issues and pull requests are now assigned to milestones. Want to know when your issue was fixed? Check the milestone - it tells you the release version.

Road to 1.0​

We're working hard to make Flet a scalable, sustainable framework, and 0.83.0 reflects that commitment.

Everything is automated. Our CI pipeline handles building, testing, packaging, and publishing end-to-end. Every push to main triggers a full build of all platform binaries, runs the test suite, executes flet build for all targets, and publishes dev releases to GitHub and pub.dev. There are no manual steps.

Comprehensive integration testing. We now run 200+ integration tests on macOS across 12 parallel test suites - covering core controls, Material and Cupertino widgets, services, themes, extensions, and example apps. A full run takes about 85 minutes and catches regressions before they reach you. Integration suites for other platforms are coming!

New documentation is coming. We're moving back to Docusaurus for the Flet docs, which will bring a better reading experience, improved search, and easier contribution workflow. Stay tuned.

Other changes and bug fixes​

• Customizable scrollbars (#6282).
• Scrollable ExpansionPanelList (#6294).
• SharedPreferences now supports int, float, bool, and list[str] types (#6267).
• Align Python defaults with Dart defaults across all packages (#6330).
• Fix ReorderableListView event deserialization for on_reorder_start/on_reorder_end (#6315).
• Skip micropip load for apps with pyproject.toml (#6300).

Conclusion​

Flet 0.83.0 is a release about foundations: faster internals, cleaner packaging, and better tooling. These are the kinds of improvements that compound - every future release builds on a faster, more reliable base.

Try it in your apps and share feedback in GitHub Discussions or on Discord.

Happy Flet-ing!

Highlights in this release:

• New controls: Camera, CodeEditor, PageView, color pickers, RotatedBox.
• Advanced visual transitions with Hero animations and Matrix4 transforms.
• Better app packaging with flet build ios-simulator and flet build --artifact.
• Clipboard APIs for images and files.
• Web FilePicker support for direct file content (with_data=True).
• Platform locale info and locale change events.
• New LayoutControl.on_size_change event for size-aware UI.

How to upgrade​

If you use pip:

pip install 'flet[all]' --upgrade

If you use uv with pyproject.toml and want to upgrade everything:

uv sync --upgrade

If you want to upgrade only Flet packages:

uv sync --upgrade-package flet \
  --upgrade-package flet-cli \
  --upgrade-package flet-desktop \
  --upgrade-package flet-web

On Linux, your project might use flet-desktop-light instead of flet-desktop. In that case, upgrade flet-desktop-light package instead.

Camera​

Camera is a new control for live camera preview, image capture, video recording, and frame streaming.

It is currently supported on web, iOS, and Android, which makes it practical for cross-platform scanning, media capture, and computer vision scenarios from a single Flet codebase.

import flet as ft
import flet_camera as fc


def main(page: ft.Page):
    page.add(
        fc.Camera(
            expand=True,
            preview_enabled=True,
        )
    )


ft.run(main)

More info:

• Docs: https://flet.dev/docs/camera/
• Issue: #6190

CodeEditor​

CodeEditor brings an embedded source editor into Flet apps.

This is useful for developer tools, education apps, playgrounds, and it is also part of the groundwork for the upcoming FletPad experience.

import flet as ft
import flet_code_editor as fce


def main(page: ft.Page):
    page.add(
        fce.CodeEditor(
            language=fce.CodeLanguage.PYTHON,
            code_theme=fce.CodeTheme.ATOM_ONE_LIGHT,
            value="print('Hello, Flet')",
            expand=True,
        )
    )


ft.run(main)

More info:

• Docs: https://flet.dev/docs/codeeditor/
• Issue: #6162

PageView​

PageView provides swipe-based paging with viewport control and programmatic navigation.

It solves a common mobile-style UX need for onboarding, content carousels, step-by-step flows, and story-like interfaces.

import flet as ft


def main(page: ft.Page):
    page.add(
        ft.PageView(
            expand=True,
            viewport_fraction=0.9,
            selected_index=1,
            controls=[
                ft.Container(
                    bgcolor=ft.Colors.INDIGO_400,
                    alignment=ft.Alignment.CENTER,
                    content=ft.Text("Page 1", size=24, color=ft.Colors.WHITE),
                ),
                ft.Container(
                    bgcolor=ft.Colors.PINK_300,
                    alignment=ft.Alignment.CENTER,
                    content=ft.Text("Page 2", size=24, color=ft.Colors.WHITE),
                ),
                ft.Container(
                    bgcolor=ft.Colors.TEAL_300,
                    alignment=ft.Alignment.CENTER,
                    content=ft.Text("Page 3", size=24, color=ft.Colors.WHITE),
                ),
            ],
        )
    )


ft.run(main)

More info:

• Docs: https://flet.dev/docs/controls/pageview/
• Issue: #6158

Color pickers​

Flet now includes multiple color picker controls powered by flutter_colorpicker.

This makes it easier to build design tools, theming UIs, and customization dialogs without third-party integration work.

import flet as ft
from flet_color_pickers import MaterialPicker


def main(page: ft.Page):
    page.add(
        MaterialPicker(
            color="#ff9800",
            on_color_change=lambda e: print(e.data),
        )
    )


ft.run(main)

More info:

• Docs: https://flet.dev/docs/colorpickers/
• Issue: #6109

Hero animations​

Hero animations add shared-element transitions between routes.

They solve abrupt navigation changes by visually connecting matching elements across screens, which improves perceived continuity and polish.

Code example

More info:

• Docs: https://flet.dev/docs/controls/hero/
• Issue: #6157

Matrix4 transforms and RotatedBox​

This release adds Matrix4-based transforms to LayoutControl.transform and introduces RotatedBox.

Together, they cover both advanced transform pipelines and layout-aware quarter-turn rotation. This helps when building rich interactions, visual effects, and precise UI compositions.

import flet as ft
from math import pi


def main(page: ft.Page):
    page.add(
        ft.Container(
            width=220,
            height=130,
            bgcolor=ft.Colors.CYAN_300,
            transform=ft.Transform(
                matrix=ft.Matrix4.identity().set_entry(3, 2, 0.0018).rotate_y(pi / 8)
            ),
        ),
        ft.RotatedBox(quarter_turns=1, content=ft.Text("Rotated")),
    )


ft.run(main)

More info:

• LayoutControl docs: https://flet.dev/docs/controls/layoutcontrol/
• RotatedBox docs: https://flet.dev/docs/controls/rotatedbox/
• Issue: #6198

Build workflow updates: iOS simulator target and artifact naming​

Packaging for iOS simulator now produces an unsigned .app you can drag and drop into the simulator:

flet build ios-simulator

At the same time, flet build --artifact gives better control over output artifact naming without affecting bundle IDs:

flet build macos --artifact "My Awesome App"

More info:

• iOS simulator build: https://flet.dev/docs/publish/ios/#flet-build-ios-simulator
• Artifact name docs: https://flet.dev/docs/publish/#artifact-name
• Issues: #6188, #6074

Clipboard, FilePicker, locales, and size-aware layouts​

This release improves app integration with operating systems and browsers:

• Clipboard can now get/set images and files.
• Web FilePicker can return picked file content as bytes with with_data=True.
• Platform locales and locale change events are available.
• LayoutControl.on_size_change helps build size-aware UI logic.

import flet as ft


def main(page: ft.Page):
    async def pick_text_file(_):
        files = await ft.FilePicker().pick_files(with_data=True)
        print(files[0].bytes if files else None)

    page.add(ft.Button("Pick file", on_click=pick_text_file))


ft.run(main)

import flet as ft


def main(page: ft.Page):
    def handle_size_change(e: ft.LayoutSizeChangeEvent[ft.Container]):
        e.control.content.value = f"{int(e.width)} x {int(e.height)}"

    page.add(
        ft.Container(
            expand=True,
            content=ft.Text(),
            on_size_change=handle_size_change,
        )
    )


ft.run(main)

More info:

• Clipboard docs: https://flet.dev/docs/services/clipboard/
• FilePicker docs: https://flet.dev/docs/services/filepicker/
• Locale type docs: https://flet.dev/docs/types/locale/
• LayoutControl docs: https://flet.dev/docs/controls/layoutcontrol/
• Issues: #6141, #6199, #6191, #6099

Improvements​

0.81.0 reduces memory churn in control diffing algorithm, which is especially important for web apps with frequent UI diffs.

• Optimize object_patch memory churn (#6204).
• Add ignore_up_down_keys to TextField and CupertinoTextField (#6183).

Other changes and bug fixes​

• Bump Flutter to 3.41.2 (italic font finally looks nice!).
• Register MIME types for .mjs and .wasm (#6140).
• Skip component migrate/diff when function signatures differ (#6181).
• Fix memory leaks in Flet web app (#6186).
• Fix desktop window frameless/titlebar update sync and progress bar clearing (#6114).
• Fix first-time button style patching and clear stale style state (#6119).
• Fix map layer rebuilds on marker updates (#6113).
• Fix AlertDialog and CupertinoAlertDialog barrier color updates (#6097).
• Fix ControlEvent runtime type hints (#6102).

Flet app update on mobile stores​

An updated Flet app for testing on mobile devices is coming to the App Store and Google Play soon.

For now, see the current mobile testing guide: https://flet.dev/docs/getting-started/testing-on-mobile/

Conclusion​

Flet 0.81.0 is focused on practical app-building features: richer UI controls, stronger system integration, and smoother build workflows.

Try it in your apps and share feedback in GitHub Discussions or on Discord.

Happy Flet-ing!

Flet 1.0 is a huge leap forward! Its goal is to ensure long-term growth, with an architecture designed to scale to larger projects, more users, and an expanding feature set.

• Developers can use either imperative or declarative style to write their Flet apps.
• The new documentation website based on mkdocs, generated from Flet code base and always up-to-date.
• End-to-end integration tests for all controls and examples.
• Extensions are back in Flet main repo, with combined docs and covered by tests.
• Examples are back to main Flet repo, always in sync with Flet API and covered by tests.
• flet debug CLI for debugging app on real devices and emulators.
• Build, test and release workflows are automated with GitHub Actions.
• Clean extensibility model with simplified API on Python and Flutter sides.

Upgrading to Flet 1.0 Beta​

This release differs from the Alpha in that it is no longer a pre-release (there is no "dev" suffix) and it replaces version 0.28.3 as the current release on PyPI.

This means that if you install flet (or any other Flet package), or add it as a dependency without specifying a version, you will get 0.80.0 by default.

Why is this important? 0.80.0 is not a drop-in upgrade — it includes breaking changes. To run an existing app on 0.80.0, you will need to migrate it manually.

If you use pip to manage your environment just run:

pip install 'flet[all]' --upgrade

For projects managed by uv you just remove lock file and re-sync:

rm uv.lock
uv sync

The latest flet 0.80.x package version will be installed.

Built-in Flet extensions such as flet_audio, flet_video, and others are now published with the same version as the core flet packages, so be sure to update and pin their dependencies as well.

Staying on Flet 0.28.x​

If you do not plan to upgrade your existing app to Flet 1.0, you will need to pin the Flet version to 0.28.3 in your requirements.txt or pyproject.toml:

flet==0.28.3

Flet app for iOS and Android​

Read more about testing on iOS and Android.

Next steps​

If you're starting a new app, we recommend using Flet 0.80.0 (aka "Beta").

"Beta" means the Flet API is 99% stable and will not change before the 1.0 final release. Flet 1.0 Beta is safe for all new applications.

For Flet 0.28.x (also known as Flet v0), we will continue to provide minor updates for bug fixes and security issues, but no new features will be added.

Try Flet 0.80.0 and let us know what you think!

We wish you a Merry Christmas and a Happy New Year! 🎄✨

New sensor services​

• Accelerometer – Reads raw acceleration along the X, Y, and Z axes, including gravity.
• Barometer – Provides atmospheric pressure readings useful for altitude estimation.
• Gyroscope – Measures device rotation around each axis.
• Magnetometer – Detects magnetic field strength, commonly used for compass functionality.
• UserAccelerometer – Reports acceleration data with gravity filtered out for cleaner motion detection.

New system services​

• Battery – Monitors battery level, charging state, and power source changes.
• Connectivity – Detects network status and connection type (Wi-Fi, mobile, offline).
• ScreenBrightness – Allows reading and adjusting the device screen brightness.
• Share – Invokes the system share sheet to share text, files, or URLs.
• Wakelock – Prevents the device screen from dimming or sleeping while active.

Sensor services mostly work on iOS and Android devices. Using them in a web app is also possible to some extent, but only under specific browser and hardware conditions.

System services are supported on all mobile and desktop platforms.

How to test​

Install the latest Flet 0.70.0.devXYZ pre-release.

Use the flet debug command to run your app on a real iOS/Android device or emulator.

Testing in the Android emulator is especially convenient, as it allows you to experiment with virtually all available sensors:

Services API​

Previously, some services were exposed as page properties, such as page.clipboard or page.shared_preferences.

All services are now standalone and should be used by creating their own instances. For example:

clipboard = ft.Clipboard()
await clipboard.set("Hello, world!")

or simply:

await ft.Clipboard().set("Hello, world!")

When you create a new instance of a service, it is automatically registered within the page and disposed of when it is no longer referenced - for example, at the end of a method call.

However, if you need to assign an event handler to a service that must persist across method calls, you must keep a reference to that service to prevent it from being disposed.

In an imperative Flet app, you can use the page.services list, which holds service instances. For example:

async def main(page: ft.Page):
    battery = ft.Battery()
    page.services.append(battery)  # need to keep a reference to the service

    async def on_state_change(e: ft.BatteryStateChangeEvent):
        print(f"State changed: {e.state}")

    battery.on_state_change = on_state_change

    ...

In a declarative Flet app, you can use the use_ref or use_state hook to hold a service reference. For example:

import flet as ft

@ft.component
def App():
    async def on_state_change(e: ft.BatteryStateChangeEvent):
        print(f"State changed: {e.state}")

    ft.use_ref(lambda: ft.Battery(on_state_change=on_state_change))

    return ft.Text("Battery status app")

ft.run(lambda page: page.render(App))

That's all for today, folks! Happy Fletting!

In the latest Flet v1 pre-release we have introduced three new Flet CLI commands to package and run Flet app on a real device or emulator:

• flet debug - to run Flet app on a device or emulator.
• flet devices - to list connected devices.
• flet emulators - to list iOS/Android emulators and manage Android emulators.

This is a screenshot of a simple Flet app running on my iPhone:

How to use​

Run this command to list all connected iOS/Android devices and emulators:

flet devices

If you see empty list make sure emulator is running or device connected.

Copy device ID you'd like to run your app on.

Run the following command to build Flet app and run on your device:

flet debug <ios|android> --device-id <device_id> -v

You can omit -v option next time you run the command, if everything worked OK.

Testing on Android emulator​

To list available iOS and Android emulators run this command:

flet emulators

This command requires Android SDK - you will be asked to install/update it.

To create a new Android emulator run:

flet emulators create my-emulator

To start an emulator:

flet emulators start my-emulator

Testing on iOS/iPadOS emulator​

To create a new iOS/iPadOS simulator:

List simulator models:

xcrun simctl list devicetypes

List available runtimes:

xcrun simctl list runtimes

Create simulator:

xcrun simctl create "<Name>" "<Device Type>" "<Runtime>"

For example:

xcrun simctl create "My iPhone 17 Pro" "iPhone 17 Pro" com.apple.CoreSimulator.SimRuntime.iOS-26-1

Start Apple Simulator with:

open -a Simulator

Open "File -> Open Simulator -> <Your Simulator>".

Run this command to get simulator device ID:

flet devices

Testing on a real iPhone/iPad device​

• Enable developer mode on your device.
• Connect the device with USB cable. You can use debug via Wi-Fi, but it's significantly slower than via cable.
• Open XCode, go to "Window -> Devices and Simulators". Wait until "device support files" are copied - it could take a few minutes.

When you connect an iOS device and open Xcode, it automatically downloads “device support” and symbol files from the iPhone. These files allow Xcode (and Flutter) to understand the exact iOS version on the device and provide fast, reliable debugging. Without them, Xcode can’t map system libraries correctly, which leads to slow startup, missing breakpoints, or warnings like “LLDB could not find the on-disk shared cache.” This setup happens only once per iOS version and is required for running or debugging apps on a physical device.

• Create a new provisioning profile that includes your device ID and developer certificate.
• Configure app bundle ID and "debugging" profile in pyproject.toml:

[tool.flet.ios]
bundle_id = "com.your-company.app"

[tool.flet.ios.export_methods."debugging"]
provisioning_profile = "Development com.your-company.app"

FAQ​

Does flet debug replace "Flet" mobile app?​

No. "Flet" app will stay there and will be updated by Flet v1 Beta release.

"Flet" app allows quickly experience your app on a mobile device, but with limited capabilities (not all permissions are enabled and the app itself is running on your computer).

flet debug allows running on emulator or a real device without making IPA/APK package and manually uploading it to a device. Your entire app is packaged and run on a device. You can customize permissions and other settings in pyproject.toml.

When is stable Flet v1 going to be released?​

We are going to release a stable Flet v1 Beta before Christmas.

Best regards and happy Fletting!

Dogfooding Flet — building our own products like the Flet mobile app and the Control Gallery — made it clear that the imperative approach becomes hard to manage as apps grow.

That’s why Flet 1.0 introduces a declarative approach alongside the existing imperative API, drawing inspiration from frameworks such as React, SwiftUI, and Jetpack Compose.

Here's a quick look at a counter app written declaratively:

import flet as ft

@ft.component
def App():
    count, set_count = ft.use_state(0)

    return ft.Row(
        controls=[
            ft.Text(value=f"{count}"),
            ft.Button("Add", on_click=lambda: set_count(count + 1)),
        ],
    )

ft.run(lambda page: page.render(App))

Keep reading to see how it works and how you can start using it today.

What is imperative UI​

Imperative UI is when you tell the framework exactly how to build and update the interface step by step. You manipulate the UI directly — create controls, change their properties, insert or remove them in response to user actions.

For example, in an imperative style you might write:

“Create a button, then when it's clicked, change the label's text and move it below the image.”

left_column.visible = False
right_column.visible = True
right_column.controls.append(ft.Text("Complete!"))

Flet has championed imperative UI from the beginning, and we still believe it is a valid and straightforward approach — especially for small apps or developers without frontend experience.

The problem with the imperative approach, though, is that the app's state, logic, and UI all live in the same place. You constantly have to synchronize the app state and every UI element that depends on it. Add a new user to a list? You also have to add a corresponding ft.Row to display that record. As your app grows, the number of spots that must stay synchronized grows exponentially.

What is declarative UI​

The declarative approach means you describe what the UI should look like for a given state, not how to build or update it. Instead of manually creating, changing, or removing controls, you write a function that returns the UI structure based on current data — and the framework figures out the minimal updates needed to make it real.

In other words, your UI becomes a pure expression of state: whenever the state changes, the framework re-renders the view so it always stays consistent.

UI = f(state)

This makes the code simpler, more predictable, and easier to reason about.

Declarative Hello World​

Here's a simple declarative "Hello, world" Flet app:

import flet as ft

def App():
    return ft.Text("Hello, world!")

ft.run(lambda page: page.render(App))

Your app must be declarative from top to bottom, similar to how async code needs to remain async all the way. The new page.render() bootstrap method makes that possible.

For clarity, without using lambdas, the code can be rewritten as:

@ft.component
def App():
    return ft.Text("Hello, Flet!")

def main(page: ft.Page):
    page.render(App)

ft.run(main)  # as before

This app does nothing fancy — it simply displays the message and does not respond to user actions in any way.

Declarative Counter​

Here's a simple declarative "counter" Flet app:

import flet as ft

@ft.component
def App():
    count, set_count = ft.use_state(0)

    return ft.Row(
        controls=[
            ft.Text(value=f"{count}"),
            ft.Button("Add", on_click=lambda: set_count(count + 1)),
        ],
    )

ft.run(lambda page: page.render(App))

You may notice a couple of new ideas here: the @component decorator and the use_state() hook — we explain both shortly.

The takeaway is that the App function is a component that returns a fresh UI (Row) every time the app's state changes.

Components​

In Flet's declarative approach, a component is simply a reusable function that describes a piece of UI as a function of state.

You can think of it as a self-contained unit that takes inputs (properties, data, event handlers) and returns Flet controls — like Column, Text, Button, etc. Every time its inputs or internal state change, the component rebuilds its UI, and Flet automatically updates only the changed parts.

Example:

@ft.component
def Counter(value, on_increment):
    return ft.Row([
        ft.Text(f"Count: {value}"),
        ft.Button("Increment", on_click=on_increment)
    ])

Use the @component decorator to mark a function as a component.

Controls vs Components​

A control is a UI element — the basic building block rendered on screen. It's a concrete thing like a Text, Button, Row, or Column. Controls have properties (e.g., text, color, alignment) and can contain child controls.

Example:

ft.Text("Hello")
ft.Button("Click me")
ft.Column([ft.Text("A"), ft.Text("B")])

A component is a piece of logic that builds and returns controls. It's not rendered directly — instead, it describes how to create controls based on inputs or state. Components let you group logic, reuse UI patterns, and define your own higher-level abstractions.

Example:

@ft.component
def Greeting(name):
    return ft.Text(f"Hello, {name}!")

Here Greeting() is a component, and ft.Text is a control. You can combine controls inside components, and combine components to form bigger ones — but only controls end up in the final UI tree that Flet renders.

Hooks​

Hooks are lightweight functions that let components store state, react to lifecycle events, or access shared context — all without writing classes or managing manual state objects.

Example:

@ft.component
def Counter():
    count, set_count = ft.use_state(0)

    return ft.Row(
        controls=[
            ft.Text(value=f"{count}"),
            ft.Button("Add", on_click=lambda: set_count(count + 1)),
        ],
    )

Here:

• The Counter() component reads like a simple function.
• use_state(0) gives it persistent state.
• When set_count() is called, Flet re-runs the component and re-renders only what changed.

That persistence is crucial: ordinary local variables are re-created on every render, so their values would disappear. Hook state survives re-renders, giving your functional components memory without resorting to globals or classes.

To better understand what hooks are (in an OOP analogy), imagine the Counter is a class, not a function. In pseudo-code the example above becomes:

class Counter(Component):
    count: state(0)

    def build(self):
        return Row(...)

Here, count is a field that holds the current counter state.

Hooks are a smart way to add state and behavior to functional, stateless-looking components. The idea is not unique to Flet; we borrowed it from React.

Flet offers the following built-in hooks:

• use_state - Store local state across rebuilds.
• use_effect - Run side effects when something changes.
• use_context - Access shared data or services.
• use_memo - Memoize computed values.

Observable​

Observables make the declarative UI approachable for newcomers compared to a purely React-style model. You can find observables in frameworks such as SolidJS, SwiftUI, and Jetpack Compose.

An observable is a reactive data holder that keeps your UI in sync automatically — whenever its value changes, the corresponding parts of the UI update instantly and efficiently.

There are two ways to make a class observable:

Inherit from ft.Observable:

@dataclass
class CounterState(ft.Observable):
    count: int

Apply ft.observable decorator:

@dataclass
@ft.observable
class CounterState:
    count: int

Observables fit nicely into Flet's declarative approach:

• A component that accepts an observable parameter automatically re-renders when that observable updates.
• use_state and use_context hooks that reference observables trigger a re-render when the observable changes.

Example:

import asyncio
from dataclasses import dataclass

import flet as ft

@dataclass
@ft.observable
class AppState:
    counter: float

    async def start_counter(self):
        self.counter = 0
        for _ in range(0, 10):
            self.counter += 0.1
            await asyncio.sleep(0.5)


@ft.component
def App():
    state, _ = ft.use_state(AppState(counter=0))

    return [
        ft.ProgressBar(state.counter),
        ft.Button("Run!", on_click=state.start_counter),
    ]

ft.run(lambda page: page.render(App))

Here, AppState is observable state, and whenever its counter property updates, the App component re-renders.

Compared to a pure React model, an observable makes life easier by allowing mutable state, while React assumes immutable state that must be replaced entirely to trigger a re-render.

For better performance, multiple updates to observable properties are coalesced, resulting in fewer UI updates when control returns to the UI loop.

Examples​

Explore the declarative examples collection to see the new approach in action — from the simple Counter and classic To-Do to games like Tic-Tac-Toe, Minesweeper, and Solitaire.

For a deeper dive, walk through the Declarative vs Imperative CRUD app cookbook.

FAQ​

Do I need to rewrite my existing Flet apps in declarative style?​

No! Flet supports both the current imperative approach and the new declarative approach.

Where are the StateView and ControlBuilder controls?​

They are gone! They were in-place prototypes for the broader declarative concept. Mixing declarative and imperative styles in the same app caused issues.

Do I need to call update() in a declarative app?​

No! In a declarative app a component is the unit of update. Whenever a component's parameters or state change, it re-renders automatically.

How do I access the page instance?​

Use ft.context:

print(ft.context.page.web)

How do I call a control method?​

Use an ft.Ref to get a reference to a control:

@dataclass
class State:
    txt_name: ft.Ref[ft.TextField] = field(default_factory=lambda: ft.Ref())

@ft.component
def App(state):
    return ft.TextField(ref=state.txt_name)

How do I use a TextField or other input control?​

The recommended approach is to use "controlled" inputs, where controls keep their state in the app's state:

from dataclasses import dataclass
from typing import cast

import flet as ft


@dataclass
@ft.observable
class Form:
    name: str = ""

    def set_name(self, value):
        self.name = value

    async def submit(self, e: ft.Event[ft.Button]):
        e.page.show_dialog(
            ft.AlertDialog(
                title="Hello",
                content=ft.Text(f"Hello, {self.name}!"),
            )
        )

    async def reset(self):
        self.name = ""


@ft.component
def App():
    form, _ = ft.use_state(Form())

    return [
        ft.TextField(
            label="Your name",
            value=form.name,
            on_change=lambda e: form.set_name(e.control.value),
        ),
        ft.Row(
            cast(
                list[ft.Control],
                [
                    ft.FilledButton("Submit", on_click=form.submit),
                    ft.FilledTonalButton("Reset", on_click=form.reset),
                ],
            )
        ),
    ]


ft.run(lambda page: page.render(App))

Here, the value of TextField is stored in state.name, and the on_change handler keeps it in sync.

Call to action​

Try the new Flet declarative approach in the latest 0.70.0.dev releases and let us know what you think!

While we update the docs to cover declarative programming in more depth, we encourage you to check the React introduction and try the Tic-Tac-Toe tutorial. It's not Python, but the JavaScript is simple to follow.

We built a similar declarative Tic-Tac-Toe Flet app that you can compare with its React counterpart as you work through the tutorial.

The next stop is the Flet 1.0 Beta release. We're almost there — new docs (you can follow their progress here), more integration tests, and plenty of polish are underway.

Happy Fletting!

Releasing Flet 1.0 isn’t just about a version number. It’s about signaling stability, maturity, and long-term vision. A stable API, comprehensive documentation, better testing and clearly communicated roadmap — these are the foundational pieces developers need to confidently build serious apps on Flet.

But Flet 1.0 isn’t just the next incremental release. It’s a complete re-architecture.

The first versions of Flet inherited design decisions from Pglet — a web-based framework with a focus on multi-language support. While that served as a useful starting point, Flet has since evolved into a Python-centric framework for building cross-platform apps — web, desktop, and mobile.

With that evolution came technical debt, architectural misfits, and increasing complexity. Rather than patch over the cracks, we made a bold decision: to rewrite Flet from the ground up. It’s always risky to rewrite, but there’s no better time than now — before 1.0 — while the user base is still manageable and we can afford to break things in the name of long-term simplicity and maintainability.

After nearly five months of work, today we’re releasing the Flet 1.0 Alpha — a technical preview of what’s coming.

What’s new​

Flet 1.0 introduces major changes that simplify how you build, run, and scale apps. Some are improvements, some are breaking — all are focused on giving you a faster, more flexible developer experience.

• Declarative approach to building Flet apps - alongside the traditional imperative style.
• Auto-update - automatic page updates after event handler completion.
• Services - persistent, non-UI components that live across UI rebuilds and navigation. Existing controls such as Audio, FilePicker, Clipboard were re-written as services.
• Complete WASM (WebAssembly) support for web apps - faster download and performance on modern browsers.
• Offline (no-CDN) mode for web apps - Flutter resources and Pyodide are bundled with the app.
• Embedding Flet apps into existing web page - render Flet app into an HTML element on any web page.
• Enhanced Extensions API - to export services along with controls, with a room for future customizations like splash and loading screens.

Declarative approach​

Flet 1.0 introduces a declarative/reactive approach to building UIs in Flet. Developers can now mix imperative and declarative patterns in the same app, enabling more flexible and functional UI code.

Basic declarative Flet app example​

from dataclasses import dataclass

import flet as ft


@dataclass
class AppState:
    count: int

    def increment(self):
        self.count += 1


def main(page: ft.Page):
    state = AppState(count=0)

    page.floating_action_button = ft.FloatingActionButton(
        icon=ft.Icons.ADD, on_click=state.increment
    )
    page.add(
        ft.ControlBuilder(
            state,
            lambda state: ft.SafeArea(
                ft.Container(
                    ft.Text(value=f"{state.count}", size=50),
                    alignment=ft.Alignment.center(),
                ),
                expand=True,
            ),
            expand=True,
        )
    )


ft.run(main)

More declarative examples:

• Edit form
• Progress bar with yield
• 🚀 Reactive ToDo app

🚧 Documentation is in progress 🚧

Auto-update​

Control.update() is now automatically called once its event handler method is finished. Most of Flet apps will now work without explicit update() calls.

Use yield inside long-running event handlers to refresh UI, for example:

async def button_click():
  progress.value = "Something started"
  yield
  await asyncio.sleep(3)
  progress.value = "Something finished"

🚧 Documentation is in progress 🚧

Services​

"Service" is a persistent, non-visual control that can "survive" page updates and navigation transitions.

Some of the existing controls were re-implemented as services (breaking change):

• Audio (extension)
• AudioRecorder (extension)
• FilePicker
• Flashlight (extension)
• Geolocator (extension)
• HapticFeedback
• InterstitialAd (extension)
• PermissionHandler (extension)
• SemanticsService
• ShakeDetector

Service instances must be added to page.services list to work.

WebAssembly support​

Flet 1.0 web apps use WebAssembly (WASM) by default on selected browsers.

Built-in Flet web client and Flet apps built with flet build web are now include both Dart2JS (with CanvasKit as a renderer) and WebAssembly (with SKWASM renderer) targets.

🚧 Documentation is in progress 🚧

Offline mode for web apps​

Flet 1.0 has "no-CDN" mode which allows bundling the following resources along with your app instead of loading them from external CDNs:

• CanvasKit
• SkWASM
• Pyodide
• Fonts

To enable no-CDN during runtime either add no_cdn=True to ft.run() (it's a new ft.run()) call:

ft.run(main, no_cdn=True)

or set FLET_WEB_NO_CDN environment variable to 1, true or yes.

To enable no-CDN for flet build add --no-cdn argument.

🚧 Documentation is in progress 🚧

Embedding Flet web apps​

You can now embed a Flet web app into any HTML element within an existing web page.

It's also possible to render multiple views of the same app in different HTML elements.

🚧 Documentation is in progress 🚧

Enhanced Extensions API​

The new extensions API allows exporting from your Flutter package of both control and service widgets. Technically, an extension is a class now rather than a method which will allow us to add more hooks into it like custom spash and loading screens.

For example, flet-ads extension before has just one createControl method:

import 'package:flet/flet.dart';
import 'package:google_mobile_ads/google_mobile_ads.dart';

import 'banner.dart';
import 'interstitial.dart';

CreateControlFactory createControl = (CreateControlArgs args) {
  switch (args.control.type) {
    case "banner_ad":
      return BannerAdControl(
          parent: args.parent, control: args.control, backend: args.backend);
    case "interstitial_ad":
      return InterstitialAdControl(
          parent: args.parent, control: args.control, backend: args.backend);
    default:
      return null;
  }
};

void ensureInitialized() {
  if (isMobilePlatform()) {
    MobileAds.instance.initialize();
  }
}

and for Flet v1 it has two methods createWidget and createService:

import 'package:flet/flet.dart';
import 'package:flutter/cupertino.dart';
import 'package:google_mobile_ads/google_mobile_ads.dart';

import 'banner.dart';
import 'interstitial.dart';

class Extension extends FletExtension {
  @override
  void ensureInitialized() {
    if (isMobilePlatform()) {
      MobileAds.instance.initialize();
    }
  }

  @override
  FletService? createService(Control control) {
    switch (control.type) {
      case "InterstitialAd":
        return InterstitialAdService(control: control);
      default:
        return null;
    }
  }

  @override
  Widget? createWidget(Key? key, Control control) {
    switch (control.type) {
      case "BannerAd":
        return BannerAdControl(control: control);
      default:
        return null;
    }
  }
}

This change is breaking.

🚧 Documentation is in progress 🚧

Other changes and improvements​

ft.run with before_main​

A new before_main arg added to ft.run() (replaces ft.run()). before_main is a hook that allows to reliable configure page-level event handlers before Flutter client starts sending events. before_main is a function that accepts one parameter: page: ft.Page

Example usage:

def config(page: ft.Page):
  page.on_resize = lambda e: print("Page resized!")

def main(page: ft.Page):
  page.add(ft.Text("Hello!"))

ft.run(main, before_main=config)

Storage paths​

There is a new page.storage_paths multi-platform API based on path_provider for finding commonly used locations on the filesystem:

get_application_cache_directory_async(self) -> str
get_application_documents_directory_async(self) -> str
get_application_support_directory_async(self) -> str
get_downloads_directory_async(self) -> Optional[str]
get_external_cache_directories_async(self) -> Optional[List[str]]
get_external_storage_directories_async(self) -> Optional[List[str]]
get_library_directory_async(self) -> str
get_external_cache_directory_async(self) -> Optional[str]
get_temporary_directory_async(self) -> str
get_console_log_filename_async(self) -> str

🚧 Documentation is in progress 🚧

Event handlers without e​

Event handlers can now omit e parameter, for example both of these work:

button_1.on_click = lambda: print("Clicked!")
button_2.on_click = lambda e: print("Clicked!", e)

or

def increment():
   print("Increment clicked")

inc_btn.on_click = increment

Control.before_event(e) hook​

The method is called before calling any event handler.

It receives an instance of ControlEvent as parameter and should return either True or False. Returning False cancels event handler. Example implementation in Page class:

    def before_event(self, e: ControlEvent):
        if isinstance(e, RouteChangeEvent):
            if self.route == e.route:
                return False
            self.query()
        return super().before_event(e)

ft.context.page works everywhere​

It's now possible to get a reference to a current Page instance in any part of Flet program.

The new Architecture​

Flet 1.0 is not just a feature release — it's a ground-up rewrite designed to address technical debt, improve maintainability, and unlock long-term performance and flexibility. Here are some of the most impactful architectural changes:

Simplified Python control implementation​

• Controls are now implemented as Python dataclasses, bringing:

  • Automatic constructor generation
  • Native support for default values, type annotations, and field validation
  • No more manual conversions to/from str or JSON
  • Seamless support for complex property types (nested dataclasses, enums, etc.)

• This significantly reduces boilerplate and makes adding new controls trivial — often zero-maintenance.

Strong typing and IDE support​

• Event handlers are now strongly typed, improving both runtime safety and developer ergonomics.
• All controls include docstrings, enabling rich auto-generated API documentation with Docusaurus.

Smarter UI diffing​

• A new diffing algorithm powers efficient updates to the UI tree.
• It’s optimized for both imperative and declarative Flet programming styles.
• This results in faster rebuilds and fewer unnecessary redraws.

Dart runtime modernization​

• Replaced the old Redux-based state management with InheritedWidget + Provider.
• The internal control hierarchy on the Dart side now mirrors the Python control tree, enabling more efficient traversal and updates.

Binary protocol for performance​

• A new binary serialization protocol (MessagePack) replaces the JSON-based message format:

  • Significantly reduces traffic size
  • No more base64 encoding for transferring binary data (e.g., images, files)

• Control property names in Dart now exactly match their Python counterparts, making it easier to debug and extend across both runtimes.

Breaking changes​

Flet 1.0 is a major release and includes breaking changes — for good reason!

The Flet team maintains a list of known breaking changes in this issue.

If you discover something else that’s broken or incorrect, please submit a new issue or discussion. Once confirmed, we’ll update the list.

Below is a summary of the most significant and impactful breaking changes:

Single-threaded async UI model​

Flet 1.0 adopts a single-threaded async UI model, similar to JavaScript or Flutter. This design makes concurrency more predictable and better suited for the browser and mobile platforms.

• Blocking calls like time.sleep() will freeze the UI. Instead of time.sleep() use async def event handlers and using await asyncio.sleep() for delays.
• Switch to async APIs whenever possible.
• For CPU-bound tasks, offload them to threads using asyncio.to_thread(...).

🚧 Example with CPU-bound method updating progress bar 🚧

Async control methods​

All controls' get- and set- methods are async now.

Methods that do not return any results have fire-and-forget sync wrappers.

🚧 Documentation is in progress 🚧

ft.run() replaces ft.run()​

target argument renamed to main and the rest of method arguments stays the same. A new before_main argument added (see above).

Page split​

Page split into Page and PageView.

To support Flet embedding with multi-views.

It's not a breaking-change per-se if you just continue to use page instance methods or properties.

🚧 Documentation is in progress 🚧

Dialogs​

To display a dialog, banner, snack bar, drawer, or any similar popup control, use page.show_dialog(dialog_control) instead of page.open().

To close the topmost popup, use page.pop_dialog().

Drawers​

page.drawer and page.end_drawer were removed.

Use NavigationDrawer.position property and then page.show_dialog() to display drawer instead of page.drawer and page.end_drawer.

FilePicker​

FilePicker is now a service and must be added to page.services list to work.

API re-worked to provide async methods immediatly returning dialog results without using "result" event handlers.

files: list[FilePickerFile] = await file_picker.pick_files_async(allow_multiple=True)
file_name: str = await file_picker.save_file_async()
dir_name: str = await file_picker.get_directory_path_async()

Full examples:

• All dialogs
• Upload

Clipboard​

Instead of page.set_clipboard() use page.clipboard.set_async().

Instead of page.get_clipboard() use page.clipboard.get_async().

Client storage​

"Client storage" is now "Shared Preferences".

page.client_storage property renamed to page.shared_preferences.

Scrollables​

In scrollable controls on_scroll_interval property renamed to scroll_interval.

Buttons​

All buttons: no text property, use content instead.

Charts​

Chart controls have been moved to a separate package flet-charts.

Control ID is integer​

e.target is a number now, not a string.

Trying Flet 1.0 Alpha​

We are releasing Flet 1.0 Alpha as 0.70.0.devXXXX.

To install Flet v1 Alpha with pip:

pip install --pre 'flet[all]>=0.70.0.dev0'

or install with uv:

uv add 'flet[all]>=0.70.0.dev0' --prerelease=allow

or add flet >=0.70.0.dev0 to dependencies of your Python project.

flet build​

To make flet build work with Flet 1.0 Alpha specify exact version of flet and all extension packages in dependencies section of your pyproject.toml:

dependencies=[
  "flet >=0.70.0.dev0",
  "flet-audio >=0.2.0.dev0",
  "flet-video >=0.2.0.dev0",
  ...
]

Extensions for Flet v1 will have version 0.2.x and above and Flet v0 extensions will have version 0.1.x.

Roadmap to Flet 1.0​

• Flet 0.70 aka "Flet 1.0 Alpha" - this release. Generated docs are not yet included. We may release a few Flet 0.71, 0.72, 0.73, etc. to fix things.
• Flet 0.80 aka "Flet 1.0 Beta" - docs generated from sources are ready. All extensions are working and documented. Integration tests are available.
• Flet 0.90 aka "Flet 1.0 RC" - website landing page is updated, API complete and frozen.
• Flet 1.0 aka "Flet 1.0 RTM" - final release! 🎉

Conclusion​

Flet 1.0 Alpha marks the beginning of a new chapter for the framework — one focused on performance, maintainability, and developer experience. It introduces a streamlined architecture, a powerful declarative programming model, and a reimagined extension system — all while laying the groundwork for a stable and scalable 1.0 release.

This is a technical preview, and while it's not production-ready yet, we invite you to try it out, share your feedback, and help us shape the future of Flet.

We’re incredibly excited about what’s coming next — and we’re just getting started.

You can now integrate both Pyjnius and Pyobjus into your Flet apps! 🚀

Pyjnius for Android​

Pyjnius is a Python library for accessing Java classes using the Java Native Interface (JNI).

Adding to a project​

Add pyjnius dependency for Android builds only (other settings in pyproject.toml were omitted for brevity):

[project]
name = "pyjnius_demo"
version = "0.1.0"
dependencies = [
  "flet==0.27.1"
]

[tool.flet.android]
dependencies = [
  "pyjnius"
]

Usage examples​

Here are some example of how Pyjnius can be used in your Flet Android app.

Getting Android OS details​

from jnius import autoclass

# Get Build and Build.VERSION classes
Build = autoclass('android.os.Build')
Version = autoclass('android.os.Build$VERSION')

# Get OS details
device_model = Build.MODEL
manufacturer = Build.MANUFACTURER
brand = Build.BRAND
hardware = Build.HARDWARE
product = Build.PRODUCT
device = Build.DEVICE
os_version = Version.RELEASE
sdk_version = Version.SDK_INT

Listing Bluetooth devices​

from jnius import autoclass

# Get BluetoothAdapter instance
BluetoothAdapter = autoclass('android.bluetooth.BluetoothAdapter')
bluetooth_adapter = BluetoothAdapter.getDefaultAdapter()

if bluetooth_adapter is None:
    print("Bluetooth not supported on this device")
else:
    if not bluetooth_adapter.isEnabled():
        print("Bluetooth is disabled. Please enable it.")
    else:
        print("Bluetooth is enabled.")

        # Get paired devices
        paired_devices = bluetooth_adapter.getBondedDevices()
        for device in paired_devices.toArray():
            print(f"Device Name: {device.getName()}, MAC Address: {device.getAddress()}")

Accessing the Activity​

App main activity instance can be retrieved with the following code:

import os
from jnius import autoclass

activity_host_class = os.getenv("MAIN_ACTIVITY_HOST_CLASS_NAME")
assert activity_host_class
activity_host = autoclass(activity_host_class)
activity = activity_host.mActivity

Heck, you can basically call any Android API using Pyjnius - endless posibilities!

Check complete Flet Pyjnius example.

For more Pyjnius examples and API refer to the Pyjnius Documentation.

...or just use ChatGPT (or your favorite LLM) to get more ideas and solutions! 😅

Pyobjus for iOS​

Pyobjus is a library for accessing Objective-C classes as Python classes using Objective-C runtime reflection.

Adding to a project​

Add pyobjus dependency for iOS builds only (other settings in pyproject.toml were omitted for brevity):

[project]
name = "Pyjnius"
version = "0.1.0"
dependencies = [
  "flet==0.27.1"
]

[tool.flet.ios]
dependencies = [
  "pyobjus"
]

Usage examples​

The simplest example​

from pyobjus import autoclass

NSString = autoclass('NSString')
text = NSString.alloc().initWithUTF8String_('Hello world')
print(text.UTF8String())

Getting OS details​

from pyobjus import autoclass
from pyobjus.dylib_manager import load_framework, INCLUDE

# Load Foundation framework
load_framework(INCLUDE.Foundation)

# Get NSProcessInfo instance
NSProcessInfo = autoclass('NSProcessInfo')
process_info = NSProcessInfo.processInfo()

# Retrieve OS version as a string
os_version = process_info.operatingSystemVersionString.UTF8String()

print(f"iOS Version: {os_version}")

Working with app user settings​

from pyobjus import autoclass, objc_str

NSUserDefaults = autoclass('NSUserDefaults')

key = "pyobjus_hello_world_key"
value = "Hello, world!"

# set key
NSUserDefaults.standardUserDefaults().setObject_forKey_(objc_str(value), objc_str(key))

# get key
ret = NSUserDefaults.standardUserDefaults().stringForKey_(objc_str(key))

assert ret.UTF8String() == value

Check complete Flet Pyobjus example.

For more Pyobjus examples and API refer to the Pyobjus Documentation.

Plyer challenge​

There is a Plyer project by Kivy team which uses both Pyjnius and Pyobjus under the hood.

It's not ported to Flet yet. You can either get more usage examples for Android and iOS from there or help us with porting it to Flet.

• iOS packaging & signing updates – ensures compliance with App Store Connect verification requirements.
• Reduced startup delay – faster initial launch for desktop applications.
• Faster incremental re-builds – enhances development efficiency with quicker iteration times.
• Enhanced Dropdown control – improved functionality and user experience.
• Bug fixes & stability improvements – various fixes to enhance overall performance and reliability.

How to upgrade​

Run the following command to upgrade Flet:

pip install 'flet[all]' --upgrade

Bump flet package version to 0.27.0 (or remove it at all to use the latest) in your pyproject.toml.

Revamped iOS Packaging​

• Third-party Flet app dependencies (also known as “site packages” like numpy, pandas, flet, etc.) are now bundled inside a framework, ensuring Xcode signs all files correctly and passes App Store Connect verification.
• New flet build options for proper iOS package signing.
• Comprehensive step-by-step documentation for packaging and deploying iOS apps. Learn more!

Enhanced startup performance for desktop apps​

Currently, when packaging for macOS, Windows, and Linux, third-party Flet app dependencies (e.g., numpy, pandas, flet, etc.), also known as site packages, are bundled inside the app.zip artifact. This can cause a startup delay, sometimes significant, as the app needs to extract the artifact to the user’s file system before launching.

With Flet 0.27.0, site packages are now copied in an unpacked state directly into the application bundle instead of being compressed into app.zip. This change significantly reduces the first launch time.

Faster incremental re-builds​

If certain parts of the build configuration remain unchanged, the flet build command attempts to skip or optimize specific build pipeline steps (such as re-installing Flet app dependencies), reducing the overall completion time for consecutive builds.

Faster builds mean happier developers! 😄

Pyodide 0.27.2​

Pyodide 0.27.2 is based on Python 3.12 and has some serious performance improvements to foreign function interface (FFI).

Flet now supports Python 3.12 across all packaging platforms.

The next stop is Python 3.13!

Enhanced Dropdown control.​

Since version 0.27.0, Flet uses DropdownMenu flutter widget for Dropdown control, which is a Material 3 version of previously used DropdownButton. Additionally to enhanced look and feel, it allows filter the list based on the text input or search one item in the menu list.

Some properties of previous Dropdown implementation are not available in the new version and were "stubbed" - they will not break your program but don't do anything. See the list of deprecated properties here.

Previous version of Dropdown control is available as DropdownM2 control and will be removed in Flet 0.30.0.

💥 Breaking changes​

flet build command​

• --team option renamed to --ios-team-id.
• --include-packages has been removed. Just add extension package into dependencies section of your pyproject.toml file: https://flet.dev/docs/extend/built-in-extensions/
• --cleanup-on-compile removed and two new options added to separate cleanup of app and 3rd-party site packages: --cleanup-app and --cleanup-packages. Two additional options: --cleanup-app-files and --cleanup-package-files work together with --cleanup-* and allow specifying lists of globs to exclude from app and site packages.
• tool.flet.build_arch renamed to tool.flet.target_arch.

Removed v0.24.0 Deprecations​

The following items, deprecated in Flet 0.24.0, have been removed: https://flet.dev/blog/flet-v-0-24-release-announcement#deprecations

CupertinoCheckbox.inactive_color property​

The inactive_color property of the CupertinoCheckbox has been removed in favor of fill_color.

Other changes​

The full list of changes can be found in the CHANGELOG.

New features​

• feat: ReorderableListView Control (#4865)
• feat: Implement Container.dark_theme property (#4857)
• Upgrade to Pyodide 0.27 for httpx Support (#4840)
• Remove CupertinoCheckbox.inactive_color in favor of fill_color (#4837)
• feat: flet build: use Provisioning Profile to sign iOS app archive (.ipa), deprecate --team option (#4869)
• feat: flet doctor CLI command (#4803)
• feat: implement button themes (for ElevatedButton, OutlinedButton, TextButton, FilledButton, IconButton ) (#4872)
• feat: ControlEvent.data should be of type Optional[str] and default to None (#4786)
• feat: flet build: add --source-packages to allow installing certain Python packages from source distros (#4762)

Bug fixes​

• Fixed: Disable rich's Markup for stdout logs (#4795)
• Fixed: Setting SearchBar.bar_border_side isn't visually honoured (#4767)
• Fixed: Dropdown: Long options cause the down-arrow to overflow (#4838)
• Fixed: CupertinoSlider initialisation does not allow values less then zero/greater then 1 (#4853)
• Fixed: Same code shows different appearance in Flet APP/Web/PC local. (#4855)
• Fixed: Transforming scale renders a grey screen (#4759)
• Fixed: UnicodeDecodeError when using accented characters in manifest.json (#4713)
• Fixed: Implement SearchBar.blur() to programmatically unfocus the bar (#4827)
• Fixed: Disable markup for flet-cli stdout logs (#4796)

Conclusion​

Upgrade to Flet 0.27.0, test your apps and let us know how you find the new features we added.

If you have any questions, please join Flet Discord server or create a new thread on Flet GitHub discussions.

Happy Flet-ing! 👾

In summary, a Flet extension is now a single Python package that bundles both Python and Flutter code. This package can be part of your Flet project or hosted in a public Git repository or PyPI.

Built-in Flet extensions, such as Audio, Video, and Map, have been moved to their own repositories. You’re welcome to fork these extensions to create your own or contribute to Flet! These extensions have been published to PyPI, making them easy to include in your Flet app. To use them, simply add the desired extensions to the dependencies section of your pyproject.toml file.

How to upgrade​

Run the following command to upgrade Flet:

pip install 'flet[all]' --upgrade

Bump flet package version to 0.26.0 (or remove it at all to use the latest) in your pyproject.toml.

Extensibility changes​

Built-in extensions​

Flet controls based on 3rd-party Flutter packages that used to be a part of Flet repository, now have been moved to separate repos and published on pypi:

• flet-ads
• flet-audio
• flet-audio-recorder
• flet-flashlight
• flet-geolocator
• flet-lottie
• flet-map
• flet-permission-handler
• flet-rive
• flet-video
• flet-webview

To use a built-in Flet extension in your project, add it to the dependencies section of your pyproject.toml file, for example:

dependencies = [
  "flet-audio",
  "flet>=0.26.0",
]

User extensions​

Flet now makes it easy to create and build projects with your custom controls based on Flutter widgets or Flutter 3rd-party packages:

1. Create new virtual environment and install Flet there.

2. Create new Flet extension project from template:

flet create --template extension --project-name my-control

A project with new MyControl control will be created. The control is just a Flutter Text widget with a single text property.

3. Build your app.

Flet project created from extension template has examples/my_control_example folder with the example app.

When in the folder where your pyproject.toml for the app is, run flet build command, for example, for macOS:

flet build macos -v

Run the app and see the new custom Flet Control:

open build/macos/my-control-example.app

Read more about how to customise your extension here.

Development environment configuration​

To enhance the developer experience with the flet build command, Flet 0.26.0 ensures that the correct versions of Flutter SDK, Java (JDK), and Android SDK are installed. If any of these are missing or outdated, it automatically installs them for you.

You still need to install Visual Studio 2022 yourself if you're building a Flet app for Windows, or Xcode if you're building for iOS or macOS.

In the next releases we are going to introduce automatic configuration and startup of Android and iOS emulators.

Flutter 3.27​

Flet has been migrated to Flutter SDK 3.27. See this pull request for new and updated control properties.

Python 3.9​

Flet 0.26.0 requires Python 3.9 or later. Python 3.8 has reached EOL.

Other changes​

• Optional on-demand creation of ListView.controls (#3931)
• Reset InteractiveViewer transformations (#4391)
• Passthrough of mouse events from main window to other applications (#1438)
• Implemented Window.ignore_mouse_events (#4465)
• Adding Google/Android TV platform support (#4581)
• Remove Optional[] from predefined typing *Values (#4702)
• Throttle InteractiveViewer update events (#4704)
• Remove v0.26.0-related deprecations (#4456)

Bug fixes​

• Fixed: Update project_dependencies.py (#4459)
• Fixed: SafeArea object has no attribute _SafeArea__minimum (#4500)
• Fixed: Tooltip corruption in Segment and BarChartRod on update() (#4525)
• Fixed: Setting CheckBox.border_side.stroke_align to an Enum fails (#4526)
• Fixed: ControlState should be resolved based on user-defined order (#4556)
• Fixed: broken Dismissible.dismiss_direction (#4557)
• Fixed: Fix Rive not updating (#4582)
• Fixed: DatePicker regression with first and last dates (#4661)
• flet build command: Copy flutter-packages, support for platform-specific dependencies (#4667)
• Fixed: CupertinoBottomSheet applies a red color and yellow underline to Text content (#4673)
• Fixed: setting ButtonTheme displays a grey screen (#4731)
• Fixed: Textfield input border color considers user-specified border_color property (#4735)
• Fixed: make Tooltip.message a required parameter (#4736)

Conclusion​

Upgrade to Flet 0.26.0, test your apps and let us know how you find the new features we added.

If you have any questions, please join Flet Discord server or create a new thread on Flet GitHub discussions.

Happy Flet-ing! 👾

The biggest news? No more Kivy for iOS and Android packaging. No more dealing with frustrating Python binary dependencies — Flet now uses its own custom Python runtime, so your app builds are easier than ever. Plus, we’ve added loads of new features like better permissions control, faster rebuilds, and even a lightweight Linux client that skips the bloat.

Let’s dive into all the cool stuff Flet 0.25.0 has to offer! 🚀

How to upgrade​

Run the following command to upgrade Flet:

pip install 'flet[all]' --upgrade

Bump flet package version to 0.25.0 (or remove it at all to use the latest) in requirements.txt or pyproject.toml.

New packaging​

Flet packaging for iOS and Android has been relying on Kivy and it was super annoying when your app depends on Python binary packages, such as Numpy or Pillow. You needed to compile those packages yourself using Kivy command line tools. It was really frustrating and even hopeless if Kivy didn't have "recipes" for some packages, like Pydantic.

Flet does not depend on Kivy anymore and uses its own Python runtime "meticulously crafted in-house".

Flet packaging implementation for iOS and Android adheres to strict specifications defined in PEP 730 (iOS) and PEP 738 (Android) which were implemented and released in Python 3.13 (and back-ported to Python 3.12). When pypi.org supports wheel tags for iOS and Android and 3rd-party Python package maintainers start uploading their mobile packages Flet will be compatible with them and you'll be able to use them in your Flet app.

Pre-built binary packages​

flet build command for iOS and Android is now installing pre-built binary packages from https://pypi.flet.dev.

New packages can be built with creating a recipe in Mobile Forge project. For now, Flet team is authoring those recipes for you, but when the process is polished and fully-automated you'll be able to send a PR and test the compiled package right away.

If you don't yet see a package you require at https://pypi.flet.dev, you can request it in Flet discussions - Packages. Please do not request pure Python packages. Go to package's "Download files" section at https://pypi.org and make sure it contains binary platform-specific wheels.

Packaging behavior was changed too:

• The packaging is not trying to replace flet dependency with flet-runtime, flet-embed or flet-pyodide, but install all dependencies "as is" from requirements.txt or pyproject.toml - thanks to the new Flet packages structure.
• If the binary package for target platform is not found the packaging won't be trying to compile it from source distribution, but will fail instead with a meaningful error.

Python 3.12​

Packaged Flet app runs on Python 3.12.7 runtime on all platforms.

Permissions​

New flet build command allows granular control over permissions, features and entitlements embedded into AndroidManifest.xml, Info.plist and .entitlements files.

No more hard-coded permissions in those files!

For example, setting permissions for iOS bundle:

flet build --info-plist NSLocationWhenInUseUsageDescription="This app uses location service when in use."

or the same in pyproject.toml (read about pyproject.toml support below):

[tool.flet.ios.info] # --info-plist
NSLocationWhenInUseUsageDescription = "This app uses location service when in use."

An example of setting Android permissions and features:

flet build \
    --android-permissions android.permission.READ_EXTERNAL_STORAGE=True \
      android.permission.WRITE_EXTERNAL_STORAGE=True \
    --android-features android.hardware.location.network=False

Read more about permissions in the docs.

Control over app compilation and cleanup​

flet build command is no longer compiling app .py files into .pyc by default which allows you to defer discovery of any syntax errors in your app and complete the packaging.

You can control the compilation and cleanup with the following new options:

• --compile-app - compile app's .py files.
• --compile-packages - compile installed packages' .py files.
• --cleanup-on-compile - remove unnecessary files upon successful compilation.

Signing Android bundles​

We also added new options for signing Android builds:

• --android-signing-key-store - path to an upload keystore .jks file for Android apps.
• --android-signing-key-store-password - Android signing store password.
• --android-signing-key-alias - Android signing key alias. Default is "upload".
• --android-signing-key-password - Android signing key password.

Read Build and release an Android app for more information on how to configure upload key for Android builds.

Deep linking configuration​

There is a new --deep-linking-url option to configure deep linking for iOS and Android builds. The value must be in the format <scheme>://<host>.

Faster re-builds​

Ephemeral Flutter app created by flet build command is no longer being re-created on every build in a temp directory, but cached in build/flutter directory which gives faster re-builds, improves packaging troubleshooting and does not pollute user temp directory.

You can use --clear-cache option to do a clean build though.

Split APKs per ABI​

flet build now provides the built-in --split-per-abi option to split the APKs per ABIs.

"Data" and "Temp" directories for the app​

Flet developers have been asking where to store application data, such as uploaded files, SQLite databases, etc. that are persistent across application updates.

This release introduce two environment variables that are available in your Flet apps:

• FLET_APP_STORAGE_DATA - directory for storing application data that is preserved between app updates. That directory is already pre-created and its location depends on the platform the app is running on.
• FLET_APP_STORAGE_TEMP - directory for temporary application files, i.e. cache. That directory is already pre-created and its location depends on the platform the app is running on.

For example, data folder path can be read in your app as:

import os

# it's `None` when running the app in web mode
data_dir = os.getenv("FLET_APP_STORAGE_DATA")

pyproject.toml support​

It's inconvenient and bulky to carry all flet build settings as command line options.

In Flet 0.25.0 release is now possible to configure flet build, flet run, and flet publish settings in pyproject.toml!

Flet adds tool.flet section and sub-sections to pyproject.toml. Here's the minimal version of pyproject.toml you can put into root folder of your app:

[project]
name = "my_app"
version = "1.0.0"
description = "My first Flet project"
authors = [
  {name = "John Smith", email = "john@email.com"}
]
dependencies = ["flet"]

You can also generate a starting pyproject.toml (and other files) for your project with flet create command.

New Python packages structure​

We re-factored Flet Python packages and removed flet-core, flet-runtime, flet-embed orflet-pyodide packages.

The new structure avoids rewriting pip dependencies while installing flet package on various platforms. There was a problem of detecting the correct flet package to install (flet-runtime, flet-embed orflet-pyodide?) if flet was not a direct dependency in user's app.

New Flet packages:

• flet - required for minimal Flet setup, app entry point for various platforms with core logic and controls. Installed on all platforms.
• flet-cli - contains Flet CLI commands. Installed on desktop only.
• flet-desktop - contains pre-built Flet "client" app binary for macOS, Windows and Linux. By default installed on macOS and Windows desktops only.
• flet-desktop-light - contains a light-weight version (without Audio and Video controls) of Flet "client" for Linux. By default installed on Linux desktops only.
• flet-web - contains Flet web "client" and FastAPI integration. Installed on desktop only.

Packaged Flet app contains only flet package now.

flet package extras​

flet package defines the following extras that can be specified when installing Flet with pip, uv, poetry and other package manager:

• flet[all] - installs flet, flet-cli, flet-desktop and flet-web. Recommended for development.
• flet[cli] - installs flet and flet-cli. Can be used in CI environment for packaging only.
• flet[web] - installs flet and flet-web. Used for deploying Flet web apps.
• flet[desktop] - installs flet and flet-desktop. Used for desktop-only development.

New Flet install and upgrade commands​

Starting from this release the development version of flet package should be installed with the following command:

pip install 'flet[all]'

Upgrading flet package:

pip install 'flet[all]' --upgrade

"Light" client for Linux​

A lightweight desktop client, without Audio and Video controls, is now installed on Linux by default. It improves initial user experience as user doesn't need to immediately deal with gstreamer (audio) and mpv (video) dependencies and Flet "just works".

Once user got some Flet experience and wants to use Video and Audio controls in their application they can install gstreamer and/or mpv and replace Flet desktop with a full version.

Uninstall "light" Flet client:

pip uninstall flet-desktop-light --yes

Install full Flet desktop client:

pip install flet-desktop

New controls​

• Mobile Ads (Banner and Interstitial) (details and example).
• Button control (#4265) - which is just an alias for ElevatedButton control.

Breaking changes​

• Refactor Badge Control to a Dataclass; added new badge property to all controls (#4077).

Below is how to migrate:

# before
    page.navigation_bar = ft.NavigationBar(
        destinations=[
            ft.NavigationBarDestination(
                icon_content=ft.Badge(
                    content=ft.Icon(ft.Icons.PHONE),
                    text=10,
                ),
                label="Calls",
            ),
        ]
    )

# after
    page.navigation_bar = ft.NavigationBar(
        destinations=[
            ft.NavigationBarDestination(
                  icon=ft.Icon(
                        ft.Icons.PHONE,
                        badge="10",
                    ),
                label="Calls",
            ),
        ]
    )

Other changes​

• Added {value_length}, {max_length}, and {symbols_left} placeholders to TextField.counter_text (#4403).
• Added --skip-flutter-doctor to build cli command (#4388).
• WebView enhancements (#4018).
• Map control enhancements (#3994).
• Exposed more Theme props (#4278, #4278).
• Exposed more properties in multiple Controls (#4105)
• Added __contains__ methods in container-alike Controls (#4374).
• Added a custom Markdown code theme (#4343).
• Added barrier_color prop to dialogs (#4236).
• Merged icon and icon_content props into icon: str | Control (#4305).
• Migrated colors and icons variables to Enums (#4180).
• TextField: suffix_icon, prefix_icon and icon can be Control or str (#4173).
• Added --pyinstaller-build-args to flet pack CLI command (#4187).
• Made SearchBar's view height adjustable; added new properties (#4039).
• Bumped Rive version and fixed Linux app build template for rive_common.

Bug fixes​

• Fixed Icon rotation (#4384).
• Fixed regression in Markdown.code_theme when using MarkdownCodeTheme enum (#4373).
• Fixed Segment and NavigationBarDestination accept only string tooltips (#4326).
• Display informative message when date has wrong format (#4019).
• Fixed MapConfiguration.interaction_configuration is not honoured (#3976).
• Fixed Video.jump_to() fails with negative indexes (#4294).
• Fixed condition in AppBar.tooltip_opacity (#4280).
• Fixed wrong type (asyncio.Future -> concurrent.futures.Future) and handle CancelledError (#4268).
• Fixed clicking on CupertinoContextMenuAction doesn't close context menu (#3948).
• Fixed dropdown max_menu_height (#3974).
• Fixed prevent button style from being modified in before_update() (#4181).
• Fixed disabling filled buttons is not visually respected (#4090).
• when label is set, use MainAxisSize.min for the Row (#3998).
• Fixed NavigationBarDestination.disabled has no visual effect (#4073).
• Fixed autofill in CupertinoTextField (#4103).
• Linechart: jsonDecode tooltip before displaying (#4069).
• Fixed button's bgcolor, color and elevation (#4126).
• Fixed scrolling issues on Windows (#4145).
• Skip running flutter doctor on windows if no_rich_output is True (#4108).
• Fixed TextField freezes on Linux Mint #4422](https://github.com/flet-dev/flet/pull/4422)).

Conclusion​

Flet 0.25.0 is a huge release and your feedback is highly welcomed!

Upgrade to Flet 0.25.0, test your apps and let us know how you find the new features we added.

If you have any questions, please join Flet Discord server or create a new thread on Flet GitHub discussions.

Happy Flet-ing! 👾

Today, we are excited to announce another Flet pre-release which now allows configuring app build settings in pyproject.toml!

Installing pre-release​

pip install flet==0.25.0.dev3526

Building the app with pre-release​

To build your app with flet build command and pre-release version of Flet make sure your requirements.txt either contains exact version specifier:

flet==0.25.0.dev3526

or --pre flag before flet dependency:

--pre
flet

Quick start​

Create the following minimal pyproject.toml file in the root of your Flet app or run flet create to create a new app from template:

[project]
name = "my_app"
version = "1.0.0"
description = "My first Flet project"
authors = [
  {name = "John Smith", email = "john@email.com"}
]
dependencies = ["flet==0.25.0.dev3526"]

[project] is the standard required section of project.toml.

A minimal pyproject.toml for Poetry, which is also supported by flet build command, is the following:

[tool.poetry]
name = "my_app"
version = "1.0.0"
description = "My first Flet project"
authors = ["John Smith <john@email.com>"]

[tool.poetry.dependencies]
python = "^3.10"
flet = "0.25.0.dev3526"

project.name (or tool.poetry.name) corresponds to --project option of flet build command and it will be the name of app bundle or executable. The value of project.name will be "slugified" where all non-alphanumeric values are replaced with dashes -.

project.version (or tool.poetry.version) corresponds to --build-version option and it is a value in "x.y.z" string used as the version number shown to users.

project.description (or tool.poetry.description) corresponds to --description option which is the description to use for executable or bundle.

Overriding config with CLI options​

All settings in pyproject.toml have corresponding flet build CLI options. If you run the flet build command and specify options that are already configured in pyproject.toml, the CLI option values will override those from the configuration file.

Project dependencies​

List project dependencies in project.dependencies section. The value is an array with pip-like requirement specifiers:

[project]
dependencies = [
  "flet==0.25.0.dev3526",
  "numpy"
]

Product information​

All Flet specific settings should be put into [tool.flet] section and sub-sections below it.

Product information settings complement the ones in [project] section and allows configuring app bundle identifier and product display name.

[tool.flet]
org = "com.mycompany" # --org
product = "Product name" # --product
company = "My Company" # --company
copyright = "Copyright (C) 2024 by MyCompany" # --copyright
build_number = 1 # --build-number

App package contents​

The following settings control the contents of Python app archive and compilation of app/packages sources.

[tool.flet]
app.module = "main" # --module-name
app.path = "src" # path to Python app relative to `pyproject.toml`
app.exclude = ["assets"] # --exclude

compile.app = false # --compile-app
compile.packages = false # --compile-packages
compile.cleanup = false # --cleanup-on-compile

They could be alternatively written under their own sub-sections as:

[tool.flet.app]
module = "main"
path = "src"
exclude = ["assets"]

[tool.flet.compile]
app = false
packages = false
cleanup = false

Splash​

[tool.flet.splash]
color = "" # --splash-color
dark_color = "" # --splash-dark-color
web = false # --no-web-splash
ios = false # --no-ios-splash
android = false # --no-android-splash

Permissions​

[tool.flet]
permissions = ["camera", "microphone"] # --permissions

Deep linking​

[tool.flet.deep_linking]
scheme = "https" # --deep-linking-scheme
host = "mydomain.com" # --deep-linking-host

Android settings​

[tool.flet.android]
adaptive_icon_background = "" # --android-adaptive-icon-background
split_per_abi = false # --split-per-abi

Permissions (notice quotes " around key names):

[tool.flet.android.permission] # --android-permissions
"android.permission.CAMERA" = true
"android.permission.CAMERA" = true

Features (notice quotes " around key names):

[tool.flet.android.feature] # --android-features
"android.hardware.camera" = false

Android-specific deep-linking:

[tool.flet.android.deep_linking]
scheme = "https" # --deep-linking-scheme
host = "mydomain.com" # --deep-linking-host

Android bundle signing options:

[tool.flet.android.signing]
# store and key passwords can be passed with `--android-signing-key-store-password`
# and `--android-signing-key-password` options or
# FLET_ANDROID_SIGNING_KEY_STORE_PASSWORD
# and FLET_ANDROID_SIGNING_KEY_PASSWORD environment variables.
key_store = "path/to/store.jks" # --android-signing-key-store
key_alias = "upload"

iOS settings​

[tool.flet.ios]
team = "team_id" # --team

[tool.flet.ios.info] # --info-plist
NSCameraUsageDescription = "This app uses the camera to ..."

[tool.flet.ios.info.deep_linking]
scheme = "https"
host = "mydomain.com"

macOS settings​

[tool.flet.macos]
entitlement."com.apple.security.personal-information.photos-library" = true

[tool.flet]
build_arch = "arm64" # --arch - if arch is not specified Flet will build universal package for both arm64 and x86_64 archs

Web settings​

[tool.flet.web]
base_url = "/" # --base-url
renderer = "canvaskit" # --web-renderer
use_color_emoji = false # --use-color-emoji
route_url_strategy = "path" # --route-url-strategy

Flutter settings​

Dependencies​

flutter.dependencies = ["flet_video", "flet_audio"] # --include-packages

or with alternative syntax with versions:

[tool.flet.flutter.dependencies]
flet_video = "1.0.0"
flet_audio = "2.0.0"

or with path to the package on your disk:

[tool.flet.flutter.dependencies.my_package]
path = "/path/to/my_package"

Extra build args​

flutter.build_args = ["--some-flutter-arg"] # --flutter-build-args

Extra pubspec.yaml settings​

Allows injecting arbitrary content into resulting pubspec.yaml, for example:

[tool.flet.flutter.pubspec.dependency_overrides]
web = "1.0.0"

Custom template​

[tool.flet.template]
path = "gh:some-github/repo" # --template
dir = "" # --template-dir
ref = "" # --template-ref

That's it! Upgrade to Flet 0.25.0.dev3526, give this new feature and try and let us know what you think!

Cheers!

Kivy no more! We've just published Flet 0.25.0.dev3519 pre-release with the improved flet build command which does not use Kivy! Flet is now using its own Python runtime "meticulously crafted in-house".

Flet packaging implementation for iOS and Androind adheres to strict specifications defined in PEP 730 (iOS) and PEP 738 (Android) which were implemented and released in Python 3.13 (and back-ported to Python 3.12). When pypi.org supports wheel tags for iOS and Android and 3rd-party Python package maintainers start uploading their mobile packages Flet will be compatible with them and you'll be able to use them in your Flet app.

Installing pre-release​

pip install flet==0.25.0.dev3519

Building the app with pre-release​

To build your app with flet build command and pre-release version of Flet make sure your requirements.txt either contains exact version specifier:

flet==0.25.0.dev3519

or --pre flag before flet dependency:

--pre
flet

Python 3.12​

Packaged Flet app runs on Python 3.12.6 runtime for all platforms.

Pre-built binary packages​

flet build command for iOS and Android is now installing pre-built binary packages from https://pypi.flet.dev.

New packages can be built with creating a recipe in Mobile Forge project. For now, Flet team is authoring those recipes for you, but when the process is polished and fully-automated you'll be able to send a PR and test the compiled package right away.

If you don't yet see a package at https://pypi.flet.dev you can request it in Flet discussions - Packages. Please do not request pure Python packages. Go to package's "Download files" section at https://pypi.org and make sure it contains binary platform-specific wheels.

Packaging behavior was changed too:

• The packaging is not trying to replace flet dependency with flet-runtime, flet-embed or flet-pyodide, but install all dependencies "as is" from requirements.txt or pyproject.toml - thanks to the new Flet packages structure (link).
• If the binary package for target platform is not found the packaging won't be trying to compile it from source distribution, but will fail instead with a meaningful error.

New packages structure​

The structure avoids rewriting pip dependencies while installing flet package on various platforms. There was a problem of detecting the correct flet package to install (flet-runtime, flet-embed orflet-pyodide?) if flet was not a direct dependency in user's app.

New Flet packages:

• flet - required for minimal Flet setup, app entry point for various platforms. Installed on all platforms.
• flet-core - required for minimal Flet setup, core logic and controls. Installed on all platforms.
• flet-cli - contains Flet CLI commands. Installed on desktop only.
• flet-desktop - contains pre-built Flet "client" app binary for macOS, Windows and Linux. By default installed on macOS and Windows desktops only.
• flet-desktop-light - contains a light-weight version (without Audio and Video controls) of Flet "client" for Linux. By default installed on Linux desktops only.
• flet-web - contains Flet web "client" and FastAPI integration. Installed on desktop only.

Other words, packaged Flet app contains only flet and flet-core packages.