Skip to content

chore(deps): bump flet from 0.86.5 to 1.0.0 - #45

Closed
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/uv/flet-1.0.0
Closed

dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/uv/flet-1.0.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 26, 2026 •

Copy link
Copy Markdown
Contributor

Bumps flet from 0.86.5 to 1.0.0.

Release notes

Sourced from flet's releases.

v1.0.0

New features

  • Client actions: an action property that performs gesture-gated work without a round trip to Python. Browsers only let a page open a file picker, write to the clipboard, show a share sheet or open a new tab while they are still handling the user's click or key press. Sending that click to your Python code and acting on the reply takes longer than the permission lasts, so on iOS Safari those operations were silently ignored while Android and desktop browsers let them through - which made a browser rule look like a Flet bug. Button, Container, IconButton, ListTile, CupertinoButton, CupertinoListTile, FloatingActionButton, OutlinedButton, TextButton and TextSpan now accept action - a single ClientAction or a list of them - which the client performs inside the original gesture, before your on_click handler is even notified: ft.Button("Open", action=ft.OpenUrl("https://flet.dev", target=ft.UrlTarget.BLANK)). Because an action runs before your code sees the click, its arguments have to be known in advance; to act on a value computed at click time, set it on the control ahead of the click. url is unchanged and keeps working exactly as before by @​FeodorFitsner.
  • App icon and desktop integration for flet build linux. Linux was the one platform flet build shipped without an icon — flutter_launcher_icons has no Linux generator, so assets/icon.png was silently ignored and built apps ran with a generic icon. The resolved icon (icon_linux.png, falling back to icon.png or the default Flet icon) is now bundled as data/app_icon.png and set as the window icon on startup, which taskbars and window switchers pick up on X11 and XWayland. Because Wayland has no window-icon protocol — desktops resolve icons from an installed desktop entry matching the app id — the bundle also ships a ready-to-install freedesktop tree: share/applications/<bundle_id>.desktop (name from --product, comment from --description, StartupWMClass set) plus the icon at share/icons/hicolor/<size>/apps/<bundle_id>.png. The entry's application categories default to Utility and are configurable with --linux-categories or [tool.flet.linux].categories, and the runner now sets its program name to the bundle ID (matching upstream Flutter's runner template) so the running app maps to that entry on both Wayland and X11. See the new App icon docs (#2269) by @​ndonkoHenri.
  • macOS code signing, notarization, and Mac App Store builds in flet build macos. Select a distribution lane with --macos-distribution (or [tool.flet.macos.signing].distribution): developer-id signs every bundled binary with your Developer ID certificate — hardened runtime, entitlements, secure timestamp — then notarizes and staples the app for direct distribution, while app-store produces a sandboxed app with your provisioning profile embedded, packaged into an installer-signed .pkg ready for App Store Connect and TestFlight. Signing identities are auto-discovered from the keychain when not explicitly configured (via CLI options, pyproject.toml — including per-lane [tool.flet.macos.signing.<lane>] subtables — or environment variables), and the whole configuration is validated before the build starts, so a typo'd identity, expired certificate, or missing store prerequisite fails in seconds instead of after the full build. See the new Code signing, Notarization, and Mac App Store docs (#2347, #4543, #6702) by @​ndonkoHenri.
  • Add flet-local-auth extension with a LocalAuthentication service for on-device biometric and credential authentication on Android, iOS, macOS, and Windows via the local_auth Flutter plugin. Linux and Web are not supported (#3192, #6823).

Improvements

  • Built apps no longer segfault on exit, and now terminate immediately without running process teardown. An app whose Python code was still running when the process ended could crash with EXC_BAD_ACCESS - reported by the OS as an application crash even though the app had finished its work. Your Python code runs on its own thread alongside Flutter, and a normal process exit runs __cxa_finalize (DLL_PROCESS_DETACH on Windows), destroying the C++ statics inside every loaded C extension module while that thread is still executing inside one of them; the reported case died in matplotlib's ft2font looking up a pybind11 type-caster map that had just been destructed, but numpy, Pillow and Flutter's own Skia statics are torn down by the same pass. Both exit paths were affected: closing the window on desktop, and sys.exit() on every native platform - the latter is the worse of the two, because Flet's sys.exit posts the exit code to the Dart side and returns, so the interpreter is still fully alive (running on into Py_Finalize()) when Dart tears the process down. The desktop runners now _exit (TerminateProcess on Windows, since _exit/ExitProcess still run DLL_PROCESS_DETACH and would not help), and the sys.exit path routes through a new serious_python_hard_exit in dart_bridge 1.9.0, reached via serious_python 4.7.0 with the bundled python-build snapshot re-pinned to 20260908 (no CPython or Pyodide versions change). Exit codes are preserved. The trade-off is now a documented contract: Python atexit handlers, __del__ finalizers and unflushed buffered writes are not guaranteed to run on exit - persist what matters before exiting rather than relying on shutdown cleanup. SharedPreferences writes are unaffected and were verified to survive both paths. See How a built app terminates by @​FeodorFitsner.
  • flet run -v now turns on the framework's own logging, and -vv raises it to debug. The flag was accepted and documented as "enable verbose output", but nothing mapped it to a log level, so every logger.info in Flet's web transport — web root, assets directory, session and upload activity — was unreachable and the command printed nothing at all. flet run passes the level to the app through the new FLET_LOG_LEVEL variable; an app that configures logging itself keeps the setup it chose. The web root now also names FLET_WEB_PATH when that is where it came from, matching what the desktop client already reports for FLET_VIEW_PATH. flet run itself now configures logging too, not just the app it starts, so the desktop client resolution — which of build/<platform>, FLET_VIEW_PATH or the cached client won — is visible as well (#6835) by @​ndonkoHenri.
  • FLET_WEB_PATH now works with a flet build web output, so an app with third-party extensions can be served by flet run --web and ft.run(export_asgi_app=True). Those commands serve the prebuilt web client shipped in the flet-web package, whose extension list is fixed when Flet is released — so a third-party control renders as Unknown control: <Type> there, however the app was built. Pointing FLET_WEB_PATH at a built client should have solved that, but a built page bakes flet.pyodide = true into its config and carried no injection point, so it kept trying to start Python in the browser and never connected. The build template now carries the injection marker, and the runtime config states the mode explicitly instead of relying on the page's own default — mirroring flet run on desktop, which already prefers a client from a previous flet build (#6835) by @​ndonkoHenri.
  • Bulk byte traffic from a web app's DataChannels is no longer structured-cloned on its way to the Python worker. The Dart side has always built a postMessage transfer list from the packet's own buffer, but the JavaScript jsSend it calls accepted only two parameters, so the third was dropped and every frame was copied. jsSend now takes the transfer list and hands it to postMessage, making the hand-off zero-copy as intended; each packet is freshly allocated per send and never read back, so detaching the buffer is safe (#6829) by @​ndonkoHenri.
  • flet build web no longer compiles and ships a dart2wasm build that the page can never load. Flutter emits that output for the skwasm renderer only, while the generated flutter_bootstrap.js pins flutterConfig.renderer to whatever web_renderer resolved to — so under the default canvaskit the loader skipped it on every page load, leaving main.dart.wasm and main.dart.mjs (~7.3 MB) in the output as files nothing requests. --wasm is now passed only when the resolved renderer is auto or skwasm, the two cases where the loader can actually select it; --no-wasm and [tool.flet.web] wasm = false are unchanged (#6828) by @​ndonkoHenri.
  • The Flet web client now shows a static loading logo instead of the breathing and zoom animation. Dynamic websites can still replace it by supplying icons/loading-animation.png in the assets directory. The logo disappears on Flutter's first frame; [tool.flet.boot_screen] configures the subsequent startup screen (#6824) by @​FeodorFitsner.
  • flet run --web no longer logs assets_dir does not exist: ... for an app that simply has no assets directory. assets_dir defaults to "assets" whether or not the app has one, so the resolved path was handed downstream regardless — the desktop view ignored it silently while the web server complained, which is why the same app warned only with --web, about a directory the user never asked for. A resolved path that does not exist is now dropped at the source, making both views behave the same. A path set explicitly through FLET_ASSETS_DIR, or passed straight to FletStaticFiles when mounting on FastAPI, is always deliberate and still reports a missing directory by @​FeodorFitsner.
  • New Flet logo, and a fix for Android launcher icons that were silently being clipped. Every icon in the repo is now derived from a single master by a committed generator (.github/scripts/generate_brand_assets.py) instead of being maintained by hand across three pipelines. That surfaced a real defect in what flet build shipped: the default icon.png framed the mark at 72.9% of the canvas, outside the 66.7% that Android guarantees is visible in an adaptive icon's foreground layer — so every flet build apk produced a launcher icon cropped under circular masks, and the Android 12 splash, which clips to a circle of the same ratio, lost its edges too. The default is now framed at 60% and both render whole. Two knock-on changes worth knowing about: flet create no longer ships assets/splash_android.png, because icon.png now fits the splash circle on its own and the extra file silently won the fallback chain — replacing only icon.png gave you your own launcher icon but kept the Flet logo on the splash; and the default PWA theme_color moved from #0175C2 (Flutter's stock blue, which matched no Flet brand colour) to #FF005F, still overridable with --pwa-theme-color or [tool.flet.web].pwa_theme_color (#6816) by @​FeodorFitsner.
  • flet build generates app icons and splash screens itself, replacing flutter_launcher_icons and flutter_native_splash. Both Dart tools are gone from generated projects, along with the two pubspec.yaml config blocks that fed them; generation now runs through a new flet-platform-assets package (Pillow only, no other dependencies), and everything whose content is fixed at render time ships as a template file so the generator writes only pixels. This fixes a splash that was already broken, not just a quality gap: cookiecutter re-renders the project with overwrite_if_exists=True after the Dart tools run, restoring every file the template ships, while the change-detection stamp still recorded the earlier run — so generation was skipped on every later build and the reverted files stayed reverted. The result was that LaunchImage{,@2x,@3x}.png stayed 1x1 placeholders and Contents.json stayed light-only (the correctly generated LaunchImageDark* files were left orphaned, referenced by nothing), and launch_background.xml stayed stock white — so iOS showed no launch image at all and Android below 12 showed a plain white screen; only Android 12+ worked, because values-v31/styles.xml happens to be the one file the template does not ship. Alongside the fix, several long-standing output defects go away: web/favicon.png is 32x32 instead of a hardcoded 16x16; macOS icons get Apple's inset squircle and drop shadow instead of a plain full-bleed resize; maskable web icons are opaque and actually differ from the normal ones instead of being byte-identical copies; the Windows .ico carries 16/32/48/256 instead of a single 256 entry; apple-touch-icon-192.png is generated at last, though index.html has always linked to it; the Android 12 splash icon is fitted to the circle the platform crops it to, on the canvas the platform specifies, instead of being passed through for the user to pad by hand; web splash images are always .png, so a .webp source no longer produces a <picture> srcset pointing at files that were never written; and every downscale is done with premultiplied alpha, which removes the dark halo that any logo with soft transparent edges used to pick up. Splash bitmap sizes are unchanged and asserted against a real flutter_native_splash build, so existing apps keep the on-screen size they have today by @​FeodorFitsner.
  • flet create now ships a full-bleed assets/icon.png, and flet build linux gets the default icon it was missing. The template icon framed the mark at 60% of its canvas, which spent about 40% of every favicon, Windows .ico entry and Linux icon on empty space — those three surfaces apply no mask at all. It is now edge-to-edge, and flet build computes the margin iOS, macOS and Android need, so a new app's favicon fills its 32 pixels instead of two thirds of them. The build template also ships a Linux icon theme for the first time: an app that supplies no icon of its own already fell back to the Flet logo on iOS, macOS, Windows, web and Android, but produced a Linux bundle with no icon at all. The Flet client's own Linux icons are framed tight for the same reason by @​FeodorFitsner.
  • One assets/icon.png now works everywhere: Flet computes each platform's margin instead of asking you to pick one. No single framing can satisfy every platform - web, Windows and Linux apply no mask and want the artwork edge to edge, while iOS, macOS and Android each mask the edges away and need margin - so an icon padded to survive Android wasted about 40% of every favicon, and a full-bleed one lost 24% of itself to Android's circular mask. Supply a full-bleed icon.png and it is used as-is on the unmasked platforms, then shrunk to suit each of the other three: 60% of the canvas for iOS, 68% for macOS (which Flet then insets into the squircle tile, landing at 55%), and for Android to 85% of the launcher's mask radius, measured radially because a circle clips artwork that passes an axis test. The web needs all three cases at once, so its maskable icons are framed to the safe zone the spec defines — a circle 80% of the icon's width — and apple-touch-icon, which becomes an iOS home-screen icon, is framed exactly like the native one, while the favicon and the plain Icon-*.png keep every pixel because nothing masks them. Framing only ever shrinks, so an icon you already padded is untouched, and it is skipped entirely for an opaque source, which is a finished icon rather than a glyph on a canvas and would otherwise be ringed with background colour. Supplying icon_ios.png, icon_macos.png or icon_android.png opts that platform out completely and uses your file exactly as given. flet build also warns when a source is smaller than the largest icon it is about to make — 1024px for iOS and macOS, less elsewhere — since anything below that is enlarged and looks soft, most visibly in an App Store listing by @​FeodorFitsner.
  • An installed PWA's launch background now follows your splash colour. [tool.flet.web] pwa_background_color falls through to [tool.flet.splash] color instead of defaulting to white on its own. A browser paints the in-page splash from the page, but an installed PWA paints its launch screen from manifest.json, so the two were driven by different keys — colouring your splash left a white flash in front of it on the home screen by @​FeodorFitsner.
  • [tool.flet] icon_background sets the colour behind your icon wherever transparency cannot survive. assets/icon.png is meant to be transparent, but three surfaces reject an alpha channel: iOS, because the App Store checks for one; the macOS tile, which has to be opaque to read as a tile at all; and the maskable web icons, which render with black corners on some Android launchers otherwise. All three were hardcoded to white while Android's equivalent (adaptive_icon_background) was configurable, so an app with a dark brand had no way to avoid a white square on Apple platforms. The new key resolves platform-specific over global — [tool.flet.macos] icon_background overrides [tool.flet] icon_background — matching how the splash colours already resolve, and defaults to white so nothing changes for anyone who does not set it. Android's adaptive-icon background falls through to it as well, so one colour covers every platform; [tool.flet.android] adaptive_icon_background still overrides it. An unparsable colour warns and falls back rather than failing the build by @​FeodorFitsner.
  • flet build linux ships a proper icon theme, and flet run on Linux finally has a window icon. flutter_launcher_icons never had a Linux generator — requested since 2022 — so flet build linux installed a single file, often a 1024px image, into hicolor/256x256/; a directory that claims one size while holding another is rescaled wrongly by the icon cache, and every small panel size was downscaled from it on the fly. Each of the eight hicolor sizes is now rendered at the size its directory declares. Separately, the Flet client itself (flet run) shipped no Linux icon at all and its runner had no icon reference, so it has always shown a generic placeholder; it now carries the same generated icon set and sets its program name to the application id, so desktop environments map the running app to its desktop entry by @​FeodorFitsner.
  • FilePicker gained an on_result event, called when files are selected through a PickFiles action. A PickFiles action opens the dialog on the client before your code sees the click, so the selection cannot be returned to the caller the way pick_files() returns it - it arrives here instead. The picked files stay associated with the FilePicker, so they can be passed straight to upload() by @​FeodorFitsner.
  • flet build ipa now validates the configured provisioning profile before the build starts, instead of letting Xcode fail at the signing step minutes later with "No profile for team 'X' matching 'Y' found" — a message that cannot say what is installed. The profile is resolved the same way Xcode's PROVISIONING_PROFILE_SPECIFIER does (by name or UUID, across both directories Xcode reads), and is additionally checked for expiry, team match, and bundle-id coverage. A name that matches nothing now fails in seconds, listing the installed profiles with their teams and UUIDs so a typo — or a profile that was downloaded but never installed — is immediately obvious (#5100, #6796) by @​ndonkoHenri.
  • flet build ipa now reports the artifact it actually produced. An unsigned build yields only an .xcarchive, yet the command announced "Successfully built your .ipa bundle" and pointed at an output directory holding no .ipa; it now names the .xcarchive and explains that Xcode exports an .ipa only for a signed app. A failed export is also caught properly: flutter build ipa exits 0 when Xcode's export step fails, and the existing check for it inspected captured output — which is empty whenever -v is used, so verbose builds reported the failure as success. The check now looks for the .ipa itself (#6796) by @​ndonkoHenri.
  • Web builds and flet publish now read the FLET_WEB_RENDERER, FLET_WEB_ROUTE_URL_STRATEGY, and FLET_WEB_NO_CDN environment variables as fallbacks behind the CLI options and [tool.flet.web] pyproject keys, matching the [env: ...] notation the options already advertised, by @​ndonkoHenri.
  • flet build web and flet publish no longer bundle CanvasKit and Pyodide when CDN mode is on (the default), taking a minimal web build from 71 MB to 19 MB. In CDN mode Flutter loads CanvasKit from gstatic.com and Flet points pyodideUrl at jsdelivr, so both copies were dead weight the browser never requested — yet flutter build web always emits canvaskit/ (~37 MB), and ensure_pyodide() ran unconditionally in both commands, downloading and copying a further ~15 MB. Neither is fetched, so nothing about how a CDN-mode app loads changes; verified with a network log showing the built app pulling chromium/canvaskit.{js,wasm} from gstatic and the full Pyodide runtime from jsdelivr, with no request to a local canvaskit/ or pyodide/ path. --no-cdn (or [tool.flet.web] cdn = false) still bundles everything and is unchanged. flet build also clears a pyodide/ left in the reused Flutter project by an earlier --no-cdn build, so switching modes doesn't silently keep shipping it by @​FeodorFitsner.
  • flet.canvasKitBaseUrl and flet.fontFallbackBaseUrl are now honored whenever they are set, instead of only when flet.noCdn is true. Previously flutter_bootstrap.js applied both inside if (flet.noCdn), so a host serving its own copy of the runtime — a CDN-restricted network, an air-gapped deployment, or a platform that mirrors the runtime on its own origin — had to also set noCdn for the assignment to take effect at all, and assigning the URL alone failed silently by booting off gstatic anyway. Where a runtime asset is fetched from is now independent of what the build bundled: both values default to null in CDN mode and are pinned by flet build/patch_index.py only when bundling by @​FeodorFitsner.
  • flet_web.fastapi.app() now honors the FLET_ASSETS_DIR environment variable, as it already did for FLET_UPLOAD_DIR and as ft.run() does for both, so a deployment can point a mounted app at a different assets directory without editing code (#6792) by @​ndonkoHenri.
  • Bumped serious_python to 4.6.0 and re-pinned the bundled python-build snapshot to 20260902, moving the bundled Python to 3.12.14 / 3.13.15 / 3.14.7 and Pyodide for 3.14 to 314.0.6. All three CPython micros are security releases — they fix a quadratic-complexity denial of service in incremental html.parser.HTMLParser parsing and the same in xml.etree.ElementTree XPath index predicates; 3.12.14 additionally bundles libexpat 2.8.3 for CVE-2026-72522, which 3.13.15 and 3.14.7 shipped a week too early to carry. serious_python 4.6.0 tracks the same python-build release, keeping PYTHON_BUILD_RELEASE_DATE in sync with its pythonReleaseDate as the pin requires (#6810) by @​FeodorFitsner.
  • Android host apps now use FlutterFragmentActivity and AppCompat LaunchTheme / NormalTheme so biometric authentication dialogs work on API 24–27. A biometric cross-platform permission bundle adds NSFaceIDUsageDescription for iOS and macOS builds (#6823).

Breaking changes

  • Splash settings renamed for consistency, and the splash no longer changes size when you replace your icon. Three keys under [tool.flet.splash] describe the Android 12 splash icon and now say so: icon_bgcolor becomes icon_background, icon_dark_bgcolor becomes icon_dark_background, and android_12_fit becomes icon_fit. All three were undocumented, and the former names are still read so existing configuration keeps working. Every key under [tool.flet.splash] now also accepts a per-platform override at [tool.flet.<platform>.splash], which previously only the colours did. Separately, when no splash image is supplied the splash falls back to icon.png — and since an app icon fills its canvas by design, it was being drawn at full size, which made the splash artwork 67% larger than before. It is now framed for the splash, as it always effectively was when the default icon carried its own padding. An explicit splash.png is still used exactly as supplied, and opaque artwork is never resized on either path — including on the Android 12 splash icon, which previously shrank it into the middle of the circle instead of letting its colour bleed past, unlike the equivalent icon rule by @​FeodorFitsner.
  • InputBorder is a class hierarchy instead of an enum, so enum-shaped usage no longer works: InputBorder is not iterable, its members have no .value or .name, and InputBorder.OUTLINE is InputBorder.OUTLINE is now False because each access returns a new instance — compare with ==. Assigning a border is unaffected; see the deprecations below. Rendering changes as well: a border with no explicit side now takes its color and weight from the Material theme per state instead of always painting black, so dark mode and custom themes work; an underline finally honors its border_radius; DropdownM2's open menu is shaped by the new menu_border_radius rather than by the field's radius; and on CupertinoTextField, NoInputBorder() now actually removes the border while an outline without a side keeps the native iOS one. See the InputBorder class hierarchy guide (#6773) by @​ndonkoHenri.
  • Properties whose Flutter default is a fixed constant now declare that constant rather than Optional[...] = None, so reading one returns the value the control actually applies instead of None: the eight Paint style properties, RoundedRectangleBorder.radius, Button.autofocus, Text.no_wrap, GridView.clip_behavior, Semantics.container, ExpansionPanelList.spacing, TextField.fit_parent_size, Page.show_semantics_debugger, the three CupertinoAppBar.automatic* flags, Path.Rect.border_radius and canvas.Text.max_width. Rendering is unchanged, and properties a widget resolves at runtime from the theme, the platform or its own state keep None (#6773) by @​ndonkoHenri.
  • iOS per-method signing settings in [tool.flet.ios.export_methods.<method>] (https://github.com/flet-dev/flet/blob/HEAD/`provisioning_profile`, signing_certificate, export_options, team_id) now override the flat [tool.flet.ios] keys instead of being overridden by them. Previously a per-method value silently lost to the generic one, making the subtables useless whenever a flat key was also set; the flat key is now the shared fallback across methods — the same rule as the macOS [tool.flet.macos.signing.<lane>] subtables. See the iOS per-method signing precedence guide (#6702) by @​ndonkoHenri.
  • Remove DragTargetEvent.x, DragTargetEvent.y, and DragTargetEvent.offset (deprecated in 0.85.0). Use DragTargetEvent.local_position for target-relative coordinates or DragTargetEvent.global_position for global coordinates (#6693) by @​ndonkoHenri.
  • Remove Video.show_controls (deprecated in 0.85.0). Set Video.controls to None to hide controls (#6693) by @​ndonkoHenri.
  • Remove Video.playlist_add() and Video.playlist_remove() (deprecated in 0.85.0). Mutate Video.playlist directly with list methods such as append() and pop() (#6693) by @​ndonkoHenri.
  • Remove FletApp.show_app_startup_screen and FletApp.app_startup_screen_message (deprecated in 0.86.0). Use FletApp.boot_screen_options instead, e.g. boot_screen_options={'spinner_size': 30} or boot_screen_options={'startup_message': '...'} (#6693) by @​ndonkoHenri.
  • Remove the --clear-cache flag of flet build and flet debug (deprecated in 0.86.0). Use the flet clean command instead (#6693) by @​ndonkoHenri.
  • Remove Page.go() (deprecated in 0.80.0). Use Page.push_route() instead (#6693) by @​ndonkoHenri.
  • Remove the Page.url_launcher, Page.browser_context_menu, Page.shared_preferences, Page.clipboard, and Page.storage_paths service accessors (deprecated in 0.80.0). Instantiate the corresponding service classes directly: UrlLauncher(), BrowserContextMenu(), SharedPreferences(), Clipboard(), StoragePaths() (#6693) by @​ndonkoHenri.
  • Remove the ConstrainedControl base class (deprecated in 0.80.0). Inherit from LayoutControl instead (#6693) by @​ndonkoHenri.
  • Remove ElevatedButton (deprecated in 0.80.0). Use Button instead (#6693) by @​ndonkoHenri.

... (truncated)

Changelog

Sourced from flet's changelog.

1.0.0

New features

  • Client actions: an action property that performs gesture-gated work without a round trip to Python. Browsers only let a page open a file picker, write to the clipboard, show a share sheet or open a new tab while they are still handling the user's click or key press. Sending that click to your Python code and acting on the reply takes longer than the permission lasts, so on iOS Safari those operations were silently ignored while Android and desktop browsers let them through - which made a browser rule look like a Flet bug. Button, Container, IconButton, ListTile, CupertinoButton, CupertinoListTile, FloatingActionButton, OutlinedButton, TextButton and TextSpan now accept action - a single ClientAction or a list of them - which the client performs inside the original gesture, before your on_click handler is even notified: ft.Button("Open", action=ft.OpenUrl("https://flet.dev", target=ft.UrlTarget.BLANK)). Because an action runs before your code sees the click, its arguments have to be known in advance; to act on a value computed at click time, set it on the control ahead of the click. url is unchanged and keeps working exactly as before by @​FeodorFitsner.
  • App icon and desktop integration for flet build linux. Linux was the one platform flet build shipped without an icon — flutter_launcher_icons has no Linux generator, so assets/icon.png was silently ignored and built apps ran with a generic icon. The resolved icon (icon_linux.png, falling back to icon.png or the default Flet icon) is now bundled as data/app_icon.png and set as the window icon on startup, which taskbars and window switchers pick up on X11 and XWayland. Because Wayland has no window-icon protocol — desktops resolve icons from an installed desktop entry matching the app id — the bundle also ships a ready-to-install freedesktop tree: share/applications/<bundle_id>.desktop (name from --product, comment from --description, StartupWMClass set) plus the icon at share/icons/hicolor/<size>/apps/<bundle_id>.png. The entry's application categories default to Utility and are configurable with --linux-categories or [tool.flet.linux].categories, and the runner now sets its program name to the bundle ID (matching upstream Flutter's runner template) so the running app maps to that entry on both Wayland and X11. See the new App icon docs (#2269) by @​ndonkoHenri.
  • macOS code signing, notarization, and Mac App Store builds in flet build macos. Select a distribution lane with --macos-distribution (or [tool.flet.macos.signing].distribution): developer-id signs every bundled binary with your Developer ID certificate — hardened runtime, entitlements, secure timestamp — then notarizes and staples the app for direct distribution, while app-store produces a sandboxed app with your provisioning profile embedded, packaged into an installer-signed .pkg ready for App Store Connect and TestFlight. Signing identities are auto-discovered from the keychain when not explicitly configured (via CLI options, pyproject.toml — including per-lane [tool.flet.macos.signing.<lane>] subtables — or environment variables), and the whole configuration is validated before the build starts, so a typo'd identity, expired certificate, or missing store prerequisite fails in seconds instead of after the full build. See the new Code signing, Notarization, and Mac App Store docs (#2347, #4543, #6702) by @​ndonkoHenri.
  • Add flet-local-auth extension with a LocalAuthentication service for on-device biometric and credential authentication on Android, iOS, macOS, and Windows via the local_auth Flutter plugin. Linux and Web are not supported (#3192, #6823).

Improvements

  • Built apps no longer segfault on exit, and now terminate immediately without running process teardown. An app whose Python code was still running when the process ended could crash with EXC_BAD_ACCESS - reported by the OS as an application crash even though the app had finished its work. Your Python code runs on its own thread alongside Flutter, and a normal process exit runs __cxa_finalize (DLL_PROCESS_DETACH on Windows), destroying the C++ statics inside every loaded C extension module while that thread is still executing inside one of them; the reported case died in matplotlib's ft2font looking up a pybind11 type-caster map that had just been destructed, but numpy, Pillow and Flutter's own Skia statics are torn down by the same pass. Both exit paths were affected: closing the window on desktop, and sys.exit() on every native platform - the latter is the worse of the two, because Flet's sys.exit posts the exit code to the Dart side and returns, so the interpreter is still fully alive (running on into Py_Finalize()) when Dart tears the process down. The desktop runners now _exit (TerminateProcess on Windows, since _exit/ExitProcess still run DLL_PROCESS_DETACH and would not help), and the sys.exit path routes through a new serious_python_hard_exit in dart_bridge 1.9.0, reached via serious_python 4.7.0 with the bundled python-build snapshot re-pinned to 20260908 (no CPython or Pyodide versions change). Exit codes are preserved. The trade-off is now a documented contract: Python atexit handlers, __del__ finalizers and unflushed buffered writes are not guaranteed to run on exit - persist what matters before exiting rather than relying on shutdown cleanup. SharedPreferences writes are unaffected and were verified to survive both paths. See How a built app terminates by @​FeodorFitsner.
  • flet run -v now turns on the framework's own logging, and -vv raises it to debug. The flag was accepted and documented as "enable verbose output", but nothing mapped it to a log level, so every logger.info in Flet's web transport — web root, assets directory, session and upload activity — was unreachable and the command printed nothing at all. flet run passes the level to the app through the new FLET_LOG_LEVEL variable; an app that configures logging itself keeps the setup it chose. The web root now also names FLET_WEB_PATH when that is where it came from, matching what the desktop client already reports for FLET_VIEW_PATH. flet run itself now configures logging too, not just the app it starts, so the desktop client resolution — which of build/<platform>, FLET_VIEW_PATH or the cached client won — is visible as well (#6835) by @​ndonkoHenri.
  • FLET_WEB_PATH now works with a flet build web output, so an app with third-party extensions can be served by flet run --web and ft.run(export_asgi_app=True). Those commands serve the prebuilt web client shipped in the flet-web package, whose extension list is fixed when Flet is released — so a third-party control renders as Unknown control: <Type> there, however the app was built. Pointing FLET_WEB_PATH at a built client should have solved that, but a built page bakes flet.pyodide = true into its config and carried no injection point, so it kept trying to start Python in the browser and never connected. The build template now carries the injection marker, and the runtime config states the mode explicitly instead of relying on the page's own default — mirroring flet run on desktop, which already prefers a client from a previous flet build (#6835) by @​ndonkoHenri.
  • Bulk byte traffic from a web app's DataChannels is no longer structured-cloned on its way to the Python worker. The Dart side has always built a postMessage transfer list from the packet's own buffer, but the JavaScript jsSend it calls accepted only two parameters, so the third was dropped and every frame was copied. jsSend now takes the transfer list and hands it to postMessage, making the hand-off zero-copy as intended; each packet is freshly allocated per send and never read back, so detaching the buffer is safe (#6829) by @​ndonkoHenri.
  • flet build web no longer compiles and ships a dart2wasm build that the page can never load. Flutter emits that output for the skwasm renderer only, while the generated flutter_bootstrap.js pins flutterConfig.renderer to whatever web_renderer resolved to — so under the default canvaskit the loader skipped it on every page load, leaving main.dart.wasm and main.dart.mjs (~7.3 MB) in the output as files nothing requests. --wasm is now passed only when the resolved renderer is auto or skwasm, the two cases where the loader can actually select it; --no-wasm and [tool.flet.web] wasm = false are unchanged (#6828) by @​ndonkoHenri.
  • The Flet web client now shows a static loading logo instead of the breathing and zoom animation. Dynamic websites can still replace it by supplying icons/loading-animation.png in the assets directory. The logo disappears on Flutter's first frame; [tool.flet.boot_screen] configures the subsequent startup screen (#6824) by @​FeodorFitsner.
  • flet run --web no longer logs assets_dir does not exist: ... for an app that simply has no assets directory. assets_dir defaults to "assets" whether or not the app has one, so the resolved path was handed downstream regardless — the desktop view ignored it silently while the web server complained, which is why the same app warned only with --web, about a directory the user never asked for. A resolved path that does not exist is now dropped at the source, making both views behave the same. A path set explicitly through FLET_ASSETS_DIR, or passed straight to FletStaticFiles when mounting on FastAPI, is always deliberate and still reports a missing directory by @​FeodorFitsner.
  • New Flet logo, and a fix for Android launcher icons that were silently being clipped. Every icon in the repo is now derived from a single master by a committed generator (.github/scripts/generate_brand_assets.py) instead of being maintained by hand across three pipelines. That surfaced a real defect in what flet build shipped: the default icon.png framed the mark at 72.9% of the canvas, outside the 66.7% that Android guarantees is visible in an adaptive icon's foreground layer — so every flet build apk produced a launcher icon cropped under circular masks, and the Android 12 splash, which clips to a circle of the same ratio, lost its edges too. The default is now framed at 60% and both render whole. Two knock-on changes worth knowing about: flet create no longer ships assets/splash_android.png, because icon.png now fits the splash circle on its own and the extra file silently won the fallback chain — replacing only icon.png gave you your own launcher icon but kept the Flet logo on the splash; and the default PWA theme_color moved from #0175C2 (Flutter's stock blue, which matched no Flet brand colour) to #FF005F, still overridable with --pwa-theme-color or [tool.flet.web].pwa_theme_color (#6816) by @​FeodorFitsner.
  • flet build generates app icons and splash screens itself, replacing flutter_launcher_icons and flutter_native_splash. Both Dart tools are gone from generated projects, along with the two pubspec.yaml config blocks that fed them; generation now runs through a new flet-platform-assets package (Pillow only, no other dependencies), and everything whose content is fixed at render time ships as a template file so the generator writes only pixels. This fixes a splash that was already broken, not just a quality gap: cookiecutter re-renders the project with overwrite_if_exists=True after the Dart tools run, restoring every file the template ships, while the change-detection stamp still recorded the earlier run — so generation was skipped on every later build and the reverted files stayed reverted. The result was that LaunchImage{,@2x,@3x}.png stayed 1x1 placeholders and Contents.json stayed light-only (the correctly generated LaunchImageDark* files were left orphaned, referenced by nothing), and launch_background.xml stayed stock white — so iOS showed no launch image at all and Android below 12 showed a plain white screen; only Android 12+ worked, because values-v31/styles.xml happens to be the one file the template does not ship. Alongside the fix, several long-standing output defects go away: web/favicon.png is 32x32 instead of a hardcoded 16x16; macOS icons get Apple's inset squircle and drop shadow instead of a plain full-bleed resize; maskable web icons are opaque and actually differ from the normal ones instead of being byte-identical copies; the Windows .ico carries 16/32/48/256 instead of a single 256 entry; apple-touch-icon-192.png is generated at last, though index.html has always linked to it; the Android 12 splash icon is fitted to the circle the platform crops it to, on the canvas the platform specifies, instead of being passed through for the user to pad by hand; web splash images are always .png, so a .webp source no longer produces a <picture> srcset pointing at files that were never written; and every downscale is done with premultiplied alpha, which removes the dark halo that any logo with soft transparent edges used to pick up. Splash bitmap sizes are unchanged and asserted against a real flutter_native_splash build, so existing apps keep the on-screen size they have today by @​FeodorFitsner.
  • flet create now ships a full-bleed assets/icon.png, and flet build linux gets the default icon it was missing. The template icon framed the mark at 60% of its canvas, which spent about 40% of every favicon, Windows .ico entry and Linux icon on empty space — those three surfaces apply no mask at all. It is now edge-to-edge, and flet build computes the margin iOS, macOS and Android need, so a new app's favicon fills its 32 pixels instead of two thirds of them. The build template also ships a Linux icon theme for the first time: an app that supplies no icon of its own already fell back to the Flet logo on iOS, macOS, Windows, web and Android, but produced a Linux bundle with no icon at all. The Flet client's own Linux icons are framed tight for the same reason by @​FeodorFitsner.
  • One assets/icon.png now works everywhere: Flet computes each platform's margin instead of asking you to pick one. No single framing can satisfy every platform - web, Windows and Linux apply no mask and want the artwork edge to edge, while iOS, macOS and Android each mask the edges away and need margin - so an icon padded to survive Android wasted about 40% of every favicon, and a full-bleed one lost 24% of itself to Android's circular mask. Supply a full-bleed icon.png and it is used as-is on the unmasked platforms, then shrunk to suit each of the other three: 60% of the canvas for iOS, 68% for macOS (which Flet then insets into the squircle tile, landing at 55%), and for Android to 85% of the launcher's mask radius, measured radially because a circle clips artwork that passes an axis test. The web needs all three cases at once, so its maskable icons are framed to the safe zone the spec defines — a circle 80% of the icon's width — and apple-touch-icon, which becomes an iOS home-screen icon, is framed exactly like the native one, while the favicon and the plain Icon-*.png keep every pixel because nothing masks them. Framing only ever shrinks, so an icon you already padded is untouched, and it is skipped entirely for an opaque source, which is a finished icon rather than a glyph on a canvas and would otherwise be ringed with background colour. Supplying icon_ios.png, icon_macos.png or icon_android.png opts that platform out completely and uses your file exactly as given. flet build also warns when a source is smaller than the largest icon it is about to make — 1024px for iOS and macOS, less elsewhere — since anything below that is enlarged and looks soft, most visibly in an App Store listing by @​FeodorFitsner.
  • An installed PWA's launch background now follows your splash colour. [tool.flet.web] pwa_background_color falls through to [tool.flet.splash] color instead of defaulting to white on its own. A browser paints the in-page splash from the page, but an installed PWA paints its launch screen from manifest.json, so the two were driven by different keys — colouring your splash left a white flash in front of it on the home screen by @​FeodorFitsner.
  • [tool.flet] icon_background sets the colour behind your icon wherever transparency cannot survive. assets/icon.png is meant to be transparent, but three surfaces reject an alpha channel: iOS, because the App Store checks for one; the macOS tile, which has to be opaque to read as a tile at all; and the maskable web icons, which render with black corners on some Android launchers otherwise. All three were hardcoded to white while Android's equivalent (adaptive_icon_background) was configurable, so an app with a dark brand had no way to avoid a white square on Apple platforms. The new key resolves platform-specific over global — [tool.flet.macos] icon_background overrides [tool.flet] icon_background — matching how the splash colours already resolve, and defaults to white so nothing changes for anyone who does not set it. Android's adaptive-icon background falls through to it as well, so one colour covers every platform; [tool.flet.android] adaptive_icon_background still overrides it. An unparsable colour warns and falls back rather than failing the build by @​FeodorFitsner.
  • flet build linux ships a proper icon theme, and flet run on Linux finally has a window icon. flutter_launcher_icons never had a Linux generator — requested since 2022 — so flet build linux installed a single file, often a 1024px image, into hicolor/256x256/; a directory that claims one size while holding another is rescaled wrongly by the icon cache, and every small panel size was downscaled from it on the fly. Each of the eight hicolor sizes is now rendered at the size its directory declares. Separately, the Flet client itself (flet run) shipped no Linux icon at all and its runner had no icon reference, so it has always shown a generic placeholder; it now carries the same generated icon set and sets its program name to the application id, so desktop environments map the running app to its desktop entry by @​FeodorFitsner.
  • FilePicker gained an on_result event, called when files are selected through a PickFiles action. A PickFiles action opens the dialog on the client before your code sees the click, so the selection cannot be returned to the caller the way pick_files() returns it - it arrives here instead. The picked files stay associated with the FilePicker, so they can be passed straight to upload() by @​FeodorFitsner.
  • flet build ipa now validates the configured provisioning profile before the build starts, instead of letting Xcode fail at the signing step minutes later with "No profile for team 'X' matching 'Y' found" — a message that cannot say what is installed. The profile is resolved the same way Xcode's PROVISIONING_PROFILE_SPECIFIER does (by name or UUID, across both directories Xcode reads), and is additionally checked for expiry, team match, and bundle-id coverage. A name that matches nothing now fails in seconds, listing the installed profiles with their teams and UUIDs so a typo — or a profile that was downloaded but never installed — is immediately obvious (#5100, #6796) by @​ndonkoHenri.
  • flet build ipa now reports the artifact it actually produced. An unsigned build yields only an .xcarchive, yet the command announced "Successfully built your .ipa bundle" and pointed at an output directory holding no .ipa; it now names the .xcarchive and explains that Xcode exports an .ipa only for a signed app. A failed export is also caught properly: flutter build ipa exits 0 when Xcode's export step fails, and the existing check for it inspected captured output — which is empty whenever -v is used, so verbose builds reported the failure as success. The check now looks for the .ipa itself (#6796) by @​ndonkoHenri.
  • Web builds and flet publish now read the FLET_WEB_RENDERER, FLET_WEB_ROUTE_URL_STRATEGY, and FLET_WEB_NO_CDN environment variables as fallbacks behind the CLI options and [tool.flet.web] pyproject keys, matching the [env: ...] notation the options already advertised, by @​ndonkoHenri.
  • flet build web and flet publish no longer bundle CanvasKit and Pyodide when CDN mode is on (the default), taking a minimal web build from 71 MB to 19 MB. In CDN mode Flutter loads CanvasKit from gstatic.com and Flet points pyodideUrl at jsdelivr, so both copies were dead weight the browser never requested — yet flutter build web always emits canvaskit/ (~37 MB), and ensure_pyodide() ran unconditionally in both commands, downloading and copying a further ~15 MB. Neither is fetched, so nothing about how a CDN-mode app loads changes; verified with a network log showing the built app pulling chromium/canvaskit.{js,wasm} from gstatic and the full Pyodide runtime from jsdelivr, with no request to a ...

    Description has been truncated

Bumps [flet](https://github.com/flet-dev/flet) from 0.86.5 to 1.0.0.
- [Release notes](https://github.com/flet-dev/flet/releases)
- [Changelog](https://github.com/flet-dev/flet/blob/main/CHANGELOG.md)
- [Commits](flet-dev/flet@v0.86.5...v1.0.0)

---
updated-dependencies:
- dependency-name: flet
  dependency-version: 1.0.0
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file python:uv Pull requests that update python:uv code labels Sep 26, 2026
@dependabot @github

dependabot Bot commented on behalf of github Sep 26, 2026

Copy link
Copy Markdown
Contributor Author

Looks like flet is up-to-date now, so this is no longer needed.

@dependabot dependabot Bot closed this Sep 26, 2026
@dependabot
dependabot Bot deleted the dependabot/uv/flet-1.0.0 branch September 26, 2026 20:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file python:uv Pull requests that update python:uv code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants