Skip to main content

6 posts tagged with "news"

View All Tags

Introducing Declarative UI in Flet

· 9 min read
Feodor Fitsner
Flet founder and developer

Flet 1.0 is about more than a facelift. Our goal is to help Python developers build production-grade apps that scale from a handful of screens to hundreds of pages, views, and dialogs.

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.

Introducing Flet 1.0 Alpha

· 12 min read
Feodor Fitsner
Flet founder and developer

Flet has been in the making for over three years, steadily gaining traction and building a vibrant user community. As more developers adopt Flet for real-world projects, one thing has become clear: people are ready to commit — but they also want to see the same commitment from us.

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.

Tap into native Android and iOS APIs with Pyjnius and Pyobjus

· 3 min read
Feodor Fitsner
Flet founder and developer

When building mobile apps with Flet, you may need to interact directly with platform-specific APIs. Whether it’s accessing system information, managing Bluetooth devices, or working with user preferences, Pyjnius and Pyobjus by Kivy provide a seamless way to bridge Python with Java (for Android) and Objective-C (for iOS).

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

Flet mobile update

· 5 min read
Feodor Fitsner
Flet founder and developer

This post is a continuation of Flet mobile strategy published a few months ago.

Our original approach to Flet running on a mobile device was Server-Driven UI. Though SDUI has its own benefits (like bypassing App Store for app updates) it doesn't work in all cases, requires web server to host Python part of the app and, as a result, adds latency which is not great for user actions requiring nearly instance UI response, like drawing apps.

I've been thinking on how to make Python runtime embedded into Flutter iOS or Android app to run user Python program. No doubt, it's technically possible as Kivy and BeeWare projects do that already.

Flet versioning and pre-releases

· 2 min read
Feodor Fitsner
Flet founder and developer

Flet is a fast-evolving framework with a new functionality and bug fixes being committed every other day.

The development model with one pull request per release didn't work well for the project as users waited for weeks to get hands on a new release and, honestly, from development perspective producing large "heroic" releases takes a lot of energy 🫠.

From now on we'll be breaking releases into multiple pull requests with one feature/bugfix per PR.

Every PR merged into main branch will be publishing pre-release (developmental release) package to pypi.org having version format of X.Y.Z.devN.