diff --git a/CHANGELOG.md b/CHANGELOG.md
index 839986f6c9..502278a66b 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -2,7 +2,8 @@
 
 ### Bug fixes
 
-* Fix ink ripples and hover highlights not covering the whole `Container` when both `ink=True` and `animate` are set, and its `padding` being applied twice. In that combination `padding` and `alignment` were passed to the outer `AnimatedContainer` *and* to the inner `Container` that wraps the content inside the `InkWell`, so a `padding=10` container was laid out with 20 on each side. The duplicated `alignment` was the more visible half: it made the `Material`/`InkWell` shrink-wrap to the content, so splashes and the hover overlay stopped short of the container's edges while `bgcolor` on the same container still filled it - the two disagreed on where the control ended. Both properties now live only on the inner container, which becomes an `AnimatedContainer` when `animate` is set so that padding and alignment changes still animate; this is what the non-animated ink path already did. Inked, animated containers with padding will render tighter than before - by the padding they declare, instead of double by @FeodorFitsner.
+* Fix ink ripples and hover highlights not covering the whole `Container` when both `ink=True` and `animate` are set, and its `padding` being applied twice. In that combination `padding` and `alignment` were passed to the outer `AnimatedContainer` *and* to the inner `Container` that wraps the content inside the `InkWell`, so a `padding=10` container was laid out with 20 on each side. The duplicated `alignment` was the more visible half: it made the `Material`/`InkWell` shrink-wrap to the content, so splashes and the hover overlay stopped short of the container's edges while `bgcolor` on the same container still filled it - the two disagreed on where the control ended. Both properties now live only on the inner container, which becomes an `AnimatedContainer` when `animate` is set so that padding and alignment changes still animate; this is what the non-animated ink path already did. Inked, animated containers with padding will render tighter than before - by the padding they declare, instead of double ([#6757](https://github.com/flet-dev/flet/pull/6757)) by @FeodorFitsner.
+* Fix `disabled=True` having almost no effect on `Radio` and `CupertinoRadio`: the radio could still be selected and kept its enabled colors; only the label grayed out. Broken since the migration to Flutter's native `RadioGroup` widget ([#5651](https://github.com/flet-dev/flet/pull/5651)), whose API needs an explicit `enabled: false` that Flet never passed. A disabled radio now ignores clicks and renders grayed out (`fill_color`'s `ControlState.DISABLED` value applies too), disabling a whole `RadioGroup` cascades to its radios, and the label grays out with the default text style as well ([#6159](https://github.com/flet-dev/flet/issues/6159), [#6769](https://github.com/flet-dev/flet/pull/6769)) by @ndonkoHenri.
 
 ## 0.86.5
 
@@ -12,61 +13,61 @@
 
 ### Improvements
 
-* An Android permission set to `false` is now actively **removed** from the merged manifest instead of merely being left out of the generated one. Gradle's manifest merger folds in the manifest of every Flutter plugin and can also synthesize permissions on its own, and `false` previously had no effect on either — the template only skipped emitting the entry, so a plugin-contributed permission passed straight through with no way to stop it. Concretely: `flet-camera` pulls in `camera_android_camerax`, which declares `WRITE_EXTERNAL_STORAGE` bounded to `maxSdkVersion="28"`, and the merger implies an **unbounded** `READ_EXTERNAL_STORAGE` from it (legacy behaviour — write once implied read). Both then appear in the Play Console despite being absent from `pyproject.toml`, and the unbounded read is exactly the shape Google Play's storage policy objects to. Permissions set to `false` now render as `<uses-permission android:name="…" tools:node="remove" />` (the template's `<manifest>` gained the `tools` namespace), which strips them during the merge; removing a permission nothing declares is a harmless no-op. Verified on Flet Studio: 11 permissions down to 9, both storage entries gone from the built APK by @FeodorFitsner.
+* An Android permission set to `false` is now actively **removed** from the merged manifest instead of merely being left out of the generated one. Gradle's manifest merger folds in the manifest of every Flutter plugin and can also synthesize permissions on its own, and `false` previously had no effect on either — the template only skipped emitting the entry, so a plugin-contributed permission passed straight through with no way to stop it. Concretely: `flet-camera` pulls in `camera_android_camerax`, which declares `WRITE_EXTERNAL_STORAGE` bounded to `maxSdkVersion="28"`, and the merger implies an **unbounded** `READ_EXTERNAL_STORAGE` from it (legacy behaviour — write once implied read). Both then appear in the Play Console despite being absent from `pyproject.toml`, and the unbounded read is exactly the shape Google Play's storage policy objects to. Permissions set to `false` now render as `<uses-permission android:name="…" tools:node="remove" />` (the template's `<manifest>` gained the `tools` namespace), which strips them during the merge; removing a permission nothing declares is a harmless no-op. Verified on Flet Studio: 11 permissions down to 9, both storage entries gone from the built APK ([#6742](https://github.com/flet-dev/flet/pull/6742)) by @FeodorFitsner.
 
-* Bumped `serious_python` to **4.5.1** and re-pinned the bundled python-build snapshot to [20260730](https://github.com/flet-dev/python-build/releases/tag/20260730) (`dart_bridge` 1.7.1). `serious_python` 4.5.1 tracks the same python-build release, keeping `PYTHON_BUILD_RELEASE_DATE` in sync with its `pythonReleaseDate` as the pin requires by @FeodorFitsner.
+* Bumped `serious_python` to **4.5.1** and re-pinned the bundled python-build snapshot to [20260730](https://github.com/flet-dev/python-build/releases/tag/20260730) (`dart_bridge` 1.7.1). `serious_python` 4.5.1 tracks the same python-build release, keeping `PYTHON_BUILD_RELEASE_DATE` in sync with its `pythonReleaseDate` as the pin requires ([#6742](https://github.com/flet-dev/flet/pull/6742)) by @FeodorFitsner.
 
-* Android ProGuard/R8 rules can now be extended from `pyproject.toml` via `[tool.flet.android].proguard_rules`. The generated project's `android/app/proguard-rules.pro` was a fixed template file, so an app that needed an extra keep rule had no way to add one short of downloading the published build template, patching the file and passing `--template`. This matters for [Pyjnius](https://flet.dev/blog/tap-into-native-android-and-ios-apis-with-Pyjnius-and-pyobjus): `autoclass()` resolves Java classes by name at runtime, and R8 renames anything in the APK that isn't kept — so `autoclass()` on a class bundled by a Flutter plugin or by your own Java/Kotlin fails in release builds. It fails hard: JNI `FindClass` returns null and the process aborts with `JNI DETECTED ERROR IN APPLICATION: obj == null` / `SIGABRT` rather than raising a catchable Python exception, and because R8 only runs in release builds it never reproduces in debug. Android framework classes (`android.os.Build` and friends) live outside the APK and never needed a rule. Rules are *appended* to the defaults, since R8 has no directive that undoes a keep; to remove the defaults instead — in particular `-keepnames class * { *; }`, which keeps every class and member name in the app and costs 2.5 MB of `classes.dex` on Flet Studio (5.9 MB → 3.4 MB, -43%) — set `[tool.flet.android].proguard_default_rules = false`. Dropping the defaults is safe for Pyjnius's `PythonActivity` access, because `serious_python_android` 4.1.0+ ships that keep rule in its own `consumer-rules.pro`. Defaults are unchanged, so existing builds render exactly the same file by @FeodorFitsner.
+* Android ProGuard/R8 rules can now be extended from `pyproject.toml` via `[tool.flet.android].proguard_rules`. The generated project's `android/app/proguard-rules.pro` was a fixed template file, so an app that needed an extra keep rule had no way to add one short of downloading the published build template, patching the file and passing `--template`. This matters for [Pyjnius](https://flet.dev/blog/tap-into-native-android-and-ios-apis-with-Pyjnius-and-pyobjus): `autoclass()` resolves Java classes by name at runtime, and R8 renames anything in the APK that isn't kept — so `autoclass()` on a class bundled by a Flutter plugin or by your own Java/Kotlin fails in release builds. It fails hard: JNI `FindClass` returns null and the process aborts with `JNI DETECTED ERROR IN APPLICATION: obj == null` / `SIGABRT` rather than raising a catchable Python exception, and because R8 only runs in release builds it never reproduces in debug. Android framework classes (`android.os.Build` and friends) live outside the APK and never needed a rule. Rules are *appended* to the defaults, since R8 has no directive that undoes a keep; to remove the defaults instead — in particular `-keepnames class * { *; }`, which keeps every class and member name in the app and costs 2.5 MB of `classes.dex` on Flet Studio (5.9 MB → 3.4 MB, -43%) — set `[tool.flet.android].proguard_default_rules = false`. Dropping the defaults is safe for Pyjnius's `PythonActivity` access, because `serious_python_android` 4.1.0+ ships that keep rule in its own `consumer-rules.pro`. Defaults are unchanged, so existing builds render exactly the same file ([#6741](https://github.com/flet-dev/flet/pull/6741)) by @FeodorFitsner.
 
-* Android Gradle properties can now be configured from `pyproject.toml` via `[tool.flet.android.gradle_properties]`. The generated project's `android/gradle.properties` was previously fixed, so its memory settings — `org.gradle.jvmargs=-Xmx8G` plus a 4 GB metaspace — could not be changed. That is larger than the total RAM of a standard GitHub-hosted runner (measured: 7.8 GB with 3 GB of swap), so release builds, which additionally run Dart AOT once per ABI and R8, could exhaust memory and stall with no error; the only workaround was to download the published build template, patch the file and pass `--template`. Entries in the table override the defaults or add new properties, e.g. `"org.gradle.jvmargs" = "-Xmx3G -XX:MaxMetaspaceSize=1G"` and `"org.gradle.workers.max" = 2`. Defaults are unchanged, so existing builds render exactly the same file by @FeodorFitsner.
+* Android Gradle properties can now be configured from `pyproject.toml` via `[tool.flet.android.gradle_properties]`. The generated project's `android/gradle.properties` was previously fixed, so its memory settings — `org.gradle.jvmargs=-Xmx8G` plus a 4 GB metaspace — could not be changed. That is larger than the total RAM of a standard GitHub-hosted runner (measured: 7.8 GB with 3 GB of swap), so release builds, which additionally run Dart AOT once per ABI and R8, could exhaust memory and stall with no error; the only workaround was to download the published build template, patch the file and pass `--template`. Entries in the table override the defaults or add new properties, e.g. `"org.gradle.jvmargs" = "-Xmx3G -XX:MaxMetaspaceSize=1G"` and `"org.gradle.workers.max" = 2`. Defaults are unchanged, so existing builds render exactly the same file ([#6732](https://github.com/flet-dev/flet/issues/6732), [#6733](https://github.com/flet-dev/flet/pull/6733)) by @FeodorFitsner.
 
 ## 0.86.4
 
 ### Bug fixes
 
-* Fix services registered after an embedded `FletApp` is opened never becoming usable on the host page — calling one failed with `Timeout waiting for invoke method listener for <Service>(id).<method>`. `ServiceRegistry` subclasses `Service`, so it registered *itself* on construction; when an embedded app's page built its own registry while the host page was still the current context, the embedded registry was registered as a service **inside the host's registry**. The client has no binding for a control of type `ServiceRegistry`, so building it threw `Unknown service` inside the host's service loop and aborted it, leaving every service positioned after that entry unbound — permanently, since the entry stays in the list. A registry is the container for services, not a service, so it no longer self-registers; the client-side loop also isolates per-service failures now, so a single unbuildable entry can't stop the rest from binding. Reproduced with a host app embedding a `FletApp` and registering a `Clipboard` afterwards by @FeodorFitsner.
+* Fix services registered after an embedded `FletApp` is opened never becoming usable on the host page — calling one failed with `Timeout waiting for invoke method listener for <Service>(id).<method>`. `ServiceRegistry` subclasses `Service`, so it registered *itself* on construction; when an embedded app's page built its own registry while the host page was still the current context, the embedded registry was registered as a service **inside the host's registry**. The client has no binding for a control of type `ServiceRegistry`, so building it threw `Unknown service` inside the host's service loop and aborted it, leaving every service positioned after that entry unbound — permanently, since the entry stays in the list. A registry is the container for services, not a service, so it no longer self-registers; the client-side loop also isolates per-service failures now, so a single unbuildable entry can't stop the rest from binding. Reproduced with a host app embedding a `FletApp` and registering a `Clipboard` afterwards ([#6728](https://github.com/flet-dev/flet/pull/6728)) by @FeodorFitsner.
 
 ## 0.86.3
 
 ### Improvements
 
-* An embedded `FletApp` can now run over the in-process `dart_bridge` transport instead of a socket. Set `url="dartbridge://"` and the client allocates a native channel, delivers its port through the new `FletApp.on_connect` event, and the host serves that port with a `FletDartBridgeServer` — so a Flet program hosted inside another Flet app (a gallery, a preview) exchanges messages at memcpy speed with no socket file, no TCP port, and no `AF_UNIX` path-length limit (which broke embedded apps on the iOS simulator, where the container path overflows `sun_path`). High-throughput `DataChannel`s used by embedded apps (`RawImage`, `MatplotlibChart`) get their own dedicated bridge too. The transport is opt-in and falls back to the existing URL-scheme channels: on web and desktop dev builds, where `dart_bridge` is unavailable, hosts keep using a socket URL by @FeodorFitsner.
+* An embedded `FletApp` can now run over the in-process `dart_bridge` transport instead of a socket. Set `url="dartbridge://"` and the client allocates a native channel, delivers its port through the new `FletApp.on_connect` event, and the host serves that port with a `FletDartBridgeServer` — so a Flet program hosted inside another Flet app (a gallery, a preview) exchanges messages at memcpy speed with no socket file, no TCP port, and no `AF_UNIX` path-length limit (which broke embedded apps on the iOS simulator, where the container path overflows `sun_path`). High-throughput `DataChannel`s used by embedded apps (`RawImage`, `MatplotlibChart`) get their own dedicated bridge too. The transport is opt-in and falls back to the existing URL-scheme channels: on web and desktop dev builds, where `dart_bridge` is unavailable, hosts keep using a socket URL ([#6723](https://github.com/flet-dev/flet/pull/6723)) by @FeodorFitsner.
 
-* `flet run` can now pass custom arguments to your app script: everything after a `--` separator is forwarded to the script instead of being parsed by Flet, and arrives there as `sys.argv[1:]` - e.g. `flet run --web main.py -- --dataset big.csv --verbose`. Previously there was no way to do this: the app was always launched as `python -u <script>` with no extra arguments, so a flag meant for the app was consumed by the CLI's own parser and rejected with `flet: error: unrecognized arguments: --verbose`. The arguments are re-applied on every hot reload and work in all run modes (desktop, `--web`, `--ios`, `--android`, and `-m` module invocations). Arguments that don't look like options can be passed without the separator (`flet run main.py big.csv`), and mistyped Flet options are still reported as errors - now with a hint to use `--` when they were meant for the app. See [Passing arguments to your app](https://flet.dev/docs/getting-started/running-app#passing-arguments-to-your-app) by @FeodorFitsner.
+* `flet run` can now pass custom arguments to your app script: everything after a `--` separator is forwarded to the script instead of being parsed by Flet, and arrives there as `sys.argv[1:]` - e.g. `flet run --web main.py -- --dataset big.csv --verbose`. Previously there was no way to do this: the app was always launched as `python -u <script>` with no extra arguments, so a flag meant for the app was consumed by the CLI's own parser and rejected with `flet: error: unrecognized arguments: --verbose`. The arguments are re-applied on every hot reload and work in all run modes (desktop, `--web`, `--ios`, `--android`, and `-m` module invocations). Arguments that don't look like options can be passed without the separator (`flet run main.py big.csv`), and mistyped Flet options are still reported as errors - now with a hint to use `--` when they were meant for the app. See [Passing arguments to your app](https://flet.dev/docs/getting-started/running-app#passing-arguments-to-your-app) ([#6721](https://github.com/flet-dev/flet/pull/6721)) by @FeodorFitsner.
 
 ### Bug fixes
 
-* Fix iOS apps built with `flet build ipa` crashing at startup with `Failed to lookup symbol 'serious_python_run': dlsym(RTLD_DEFAULT, serious_python_run): symbol not found`. `serious_python` shipped `dart_bridge` — which provides the in-process Dart↔Python transport — as a **static** library linked into the app executable. An iOS executable exports nothing to the dynamic symbol table by default and the release build strips local symbols, so the `dlsym` lookups that Dart (`DynamicLibrary.process()`) and Python (`import dart_bridge`) perform at runtime could not resolve. Only release/archive (device) builds under the Swift Package Manager path were affected — debug and simulator builds don't dead-strip, so the failure did not reproduce there, and Android was never affected (its `dart_bridge` is a dynamic `.so`, which exports its symbols). Bumps `serious_python` to **4.4.0**, which ships `dart_bridge` as a dynamic framework — embedded and signed into the app like `Python.xcframework`, with its symbols exported — and re-pins the bundled python-build snapshot to **20260727** (`dart_bridge` **1.5.1 → 1.6.1**, Pyodide 3.14 **314.0.2 → 314.0.3**); the bundled Python versions (**3.12.13 / 3.13.14 / 3.14.6**) are unchanged by @FeodorFitsner.
+* Fix iOS apps built with `flet build ipa` crashing at startup with `Failed to lookup symbol 'serious_python_run': dlsym(RTLD_DEFAULT, serious_python_run): symbol not found`. `serious_python` shipped `dart_bridge` — which provides the in-process Dart↔Python transport — as a **static** library linked into the app executable. An iOS executable exports nothing to the dynamic symbol table by default and the release build strips local symbols, so the `dlsym` lookups that Dart (`DynamicLibrary.process()`) and Python (`import dart_bridge`) perform at runtime could not resolve. Only release/archive (device) builds under the Swift Package Manager path were affected — debug and simulator builds don't dead-strip, so the failure did not reproduce there, and Android was never affected (its `dart_bridge` is a dynamic `.so`, which exports its symbols). Bumps `serious_python` to **4.4.0**, which ships `dart_bridge` as a dynamic framework — embedded and signed into the app like `Python.xcframework`, with its symbols exported — and re-pins the bundled python-build snapshot to **20260727** (`dart_bridge` **1.5.1 → 1.6.1**, Pyodide 3.14 **314.0.2 → 314.0.3**); the bundled Python versions (**3.12.13 / 3.13.14 / 3.14.6**) are unchanged ([#6723](https://github.com/flet-dev/flet/pull/6723)) by @FeodorFitsner.
 
 * Fix `MatplotlibChart` freezing permanently when its platform view is disposed with a frame in flight — the common trigger is switching to another tab inside the app, which races the frame stream: `DataChannel.send` on a disposed channel silently drops, so the frame's `[0xFF]` frame-applied ack never arrives and `_send_and_wait`'s unbounded await parks `MatplotlibChart._receive_loop` — the sole consumer of the frame queue — for the rest of the session, with no exception raised; remounting opens a fresh channel but the stale ack futures were never resolved, so the chart stayed frozen. `_capture_channel` now resolves all pending ack futures when a new channel is captured (a fresh channel means every pending ack belongs to the disposed one), unparking the producer instantly on remount, and the ack await is bounded by `FRAME_ACK_TIMEOUT` (5s; a healthy ack lands in milliseconds) — on expiry the frame is dropped and its future removed from the ack FIFO so subsequent acks keep resolving the right entries ([#6709](https://github.com/flet-dev/flet/issues/6709), [#6710](https://github.com/flet-dev/flet/pull/6710)) by @ForsakenDurian.
-* Fix a system/edge-swipe back gesture exiting the whole host app instead of navigating back when it lands on an embedded `FletApp` (an app rendered inside another Flet app — e.g. a gallery host running example apps in-process). The embedded app's `WidgetsApp` (`MaterialApp`/`CupertinoApp`) ran the default `NavigationNotification` handler, which reported `SystemNavigator.setFrameworkHandlesBack(false)` for a nested app that couldn't pop (typically a single-view example) and swallowed the notification, so the OS finished the whole activity on back and the host never got to report that it could pop. An embedded page now lets that notification bubble to the host (which re-reports `canHandlePop`) and chains a `ChildBackButtonDispatcher` to the host Router, so a system back propagates to the host and pops the view that embeds it by @FeodorFitsner.
-* Fix `page.window.maximized = True` intermittently reverting to unmaximized right after startup on macOS, when set in the same patch as `page.title` (e.g. `page.title = "My App"; page.window.maximized = True` in `main()`) by @davidlawson.
-* Fix `flet build` picking a non-decodable icon/splash image when several files share a base name, producing a machine-dependent `NoDecoderForImageFormatException` from `flutter_launcher_icons`. When an app's `assets` held, say, both `icon.png` and `icon.svg`, `find_platform_image` selected the first match from `glob.glob(...)` — whose order is filesystem-dependent — so the same app could pick `icon.png` on one machine and `icon.svg` on another (SVG is vector and can't be decoded by the raster icon/splash generators), turning a working build into a crash purely based on directory listing order. Candidates are now filtered to formats the generators can actually decode (`.svg` is dropped everywhere; `.icns` stays macOS-only and `.ico` Windows-only) and ranked so a raster image (`.png` first) always wins, making the choice deterministic across machines. When the only supplied image is an SVG (no raster sibling), it's skipped with a build-log warning and the default Flet icon is used instead of crashing by @FeodorFitsner.
-* Fix modal controls (`AlertDialog`, `CupertinoAlertDialog`, `BottomSheet`, `CupertinoBottomSheet`) crashing to a black screen with "setState()/markNeedsBuild() called during build" when they close in the same frame that another route or overlay opens — e.g. dismissing a bottom sheet and showing a `SnackBar` from one handler. The close path popped the route synchronously during `build`, so the exit animation notified a listener that was mid-build. Each modal now tracks its own `ModalRoute` and closes it in a post-frame callback, popping *that* route (never the topmost one); `View`'s confirm-pop pops its own route too, so a modal dismissed in the same tick as a view pop can no longer dismiss the wrong one by @FeodorFitsner.
+* Fix a system/edge-swipe back gesture exiting the whole host app instead of navigating back when it lands on an embedded `FletApp` (an app rendered inside another Flet app — e.g. a gallery host running example apps in-process). The embedded app's `WidgetsApp` (`MaterialApp`/`CupertinoApp`) ran the default `NavigationNotification` handler, which reported `SystemNavigator.setFrameworkHandlesBack(false)` for a nested app that couldn't pop (typically a single-view example) and swallowed the notification, so the OS finished the whole activity on back and the host never got to report that it could pop. An embedded page now lets that notification bubble to the host (which re-reports `canHandlePop`) and chains a `ChildBackButtonDispatcher` to the host Router, so a system back propagates to the host and pops the view that embeds it ([#6715](https://github.com/flet-dev/flet/pull/6715)) by @FeodorFitsner.
+* Fix `page.window.maximized = True` intermittently reverting to unmaximized right after startup on macOS, when set in the same patch as `page.title` (e.g. `page.title = "My App"; page.window.maximized = True` in `main()`) ([#6712](https://github.com/flet-dev/flet/pull/6712)) by @davidlawson.
+* Fix `flet build` picking a non-decodable icon/splash image when several files share a base name, producing a machine-dependent `NoDecoderForImageFormatException` from `flutter_launcher_icons`. When an app's `assets` held, say, both `icon.png` and `icon.svg`, `find_platform_image` selected the first match from `glob.glob(...)` — whose order is filesystem-dependent — so the same app could pick `icon.png` on one machine and `icon.svg` on another (SVG is vector and can't be decoded by the raster icon/splash generators), turning a working build into a crash purely based on directory listing order. Candidates are now filtered to formats the generators can actually decode (`.svg` is dropped everywhere; `.icns` stays macOS-only and `.ico` Windows-only) and ranked so a raster image (`.png` first) always wins, making the choice deterministic across machines. When the only supplied image is an SVG (no raster sibling), it's skipped with a build-log warning and the default Flet icon is used instead of crashing ([#6707](https://github.com/flet-dev/flet/pull/6707)) by @FeodorFitsner.
+* Fix modal controls (`AlertDialog`, `CupertinoAlertDialog`, `BottomSheet`, `CupertinoBottomSheet`) crashing to a black screen with "setState()/markNeedsBuild() called during build" when they close in the same frame that another route or overlay opens — e.g. dismissing a bottom sheet and showing a `SnackBar` from one handler. The close path popped the route synchronously during `build`, so the exit animation notified a listener that was mid-build. Each modal now tracks its own `ModalRoute` and closes it in a post-frame callback, popping *that* route (never the topmost one); `View`'s confirm-pop pops its own route too, so a modal dismissed in the same tick as a view pop can no longer dismiss the wrong one ([#6714](https://github.com/flet-dev/flet/pull/6714)) by @FeodorFitsner.
 
 ## 0.86.2
 
 ### Bug fixes
 
 * Fix code edits not taking effect under `flet debug android`: after re-running the command, the app kept executing the previously-unpacked, stale code instead of your changes. `flet debug` rebuilds and reinstalls the same-version APK on each iteration (`flutter run` does an update install that preserves app data), and `serious_python`'s on-device extraction cache — keyed only on `versionName+versionCode` — never saw the version change, so it skipped re-unpacking the new `app.zip`. Bumps `serious_python` to 4.3.4, which folds the APK's `lastUpdateTime` into that cache key so every (re)install re-extracts the current code while ordinary relaunches still hit the cache. `flet build apk` was never affected ([#6682](https://github.com/flet-dev/flet/issues/6682)) by @FeodorFitsner.
-* Fix an embedded `FletApp` (an app rendered inside another Flet app — e.g. a preview or gallery host that runs example apps in-process) not refreshing its UI in response to events. Auto-update mode was tracked as `components_mode` on a single process-global `context` singleton, so a host app that rendered via `page.render`/`page.render_views` turned components mode on process-wide and `context.auto_update_enabled()` then returned `False` for the *embedded* app too — any handler that mutated a control without calling `.update()` (the common imperative style, including all `page.services` sensor readings) silently never re-rendered. Event dispatch also ran in a fresh task whose page context var could carry a different session's page, so context-derived state resolved against the wrong session. `components_mode` is now stored per-`Session`, and `Session.dispatch_event` binds the page context to its own session before invoking handlers, so multiple Flet apps sharing one process keep independent update behavior by @FeodorFitsner.
-* Modernize examples for 0.86: replace the removed `TextField.error_text` with `error` (chat tutorial, `mind_queue`, `palette_editor`), and declare the device permissions each sensor example needs to run on-device — `NSMotionUsageDescription` on iOS for the motion/barometer sensors and `android.permission.VIBRATE` for HapticFeedback by @FeodorFitsner.
-* Fix opening a `flet run --ios` / `--android` app URL in a desktop browser: the page loaded but stayed on the boot screen, endlessly retrying a WebSocket connection to `ws://<host>:<port>/ws`. Mobile-mode apps are mounted under a non-root path (e.g. `/counter/main.py`), so the real WebSocket route lives at `/counter/main.py/ws` - but since 1.0 Alpha the FastAPI wrapper always passed the bare default `ws` endpoint name into `FletStaticFiles`, bypassing its mount-path-aware fallback, and `index.html` got patched with `flet.webSocketEndpoint="ws"`, which the web client resolves against the server root. The native iOS/Android client derives the path from the page URL and was unaffected. A relative WebSocket endpoint is now resolved against the app mount path when patching `index.html`, fixing browser access to any Flet web app mounted under a non-root path (`--ios`/`--android`, `flet run --name`, or a `flet_web.fastapi` app mounted at a sub-path) by @FeodorFitsner.
+* Fix an embedded `FletApp` (an app rendered inside another Flet app — e.g. a preview or gallery host that runs example apps in-process) not refreshing its UI in response to events. Auto-update mode was tracked as `components_mode` on a single process-global `context` singleton, so a host app that rendered via `page.render`/`page.render_views` turned components mode on process-wide and `context.auto_update_enabled()` then returned `False` for the *embedded* app too — any handler that mutated a control without calling `.update()` (the common imperative style, including all `page.services` sensor readings) silently never re-rendered. Event dispatch also ran in a fresh task whose page context var could carry a different session's page, so context-derived state resolved against the wrong session. `components_mode` is now stored per-`Session`, and `Session.dispatch_event` binds the page context to its own session before invoking handlers, so multiple Flet apps sharing one process keep independent update behavior ([#6699](https://github.com/flet-dev/flet/pull/6699)) by @FeodorFitsner.
+* Modernize examples for 0.86: replace the removed `TextField.error_text` with `error` (chat tutorial, `mind_queue`, `palette_editor`), and declare the device permissions each sensor example needs to run on-device — `NSMotionUsageDescription` on iOS for the motion/barometer sensors and `android.permission.VIBRATE` for HapticFeedback ([#6699](https://github.com/flet-dev/flet/pull/6699)) by @FeodorFitsner.
+* Fix opening a `flet run --ios` / `--android` app URL in a desktop browser: the page loaded but stayed on the boot screen, endlessly retrying a WebSocket connection to `ws://<host>:<port>/ws`. Mobile-mode apps are mounted under a non-root path (e.g. `/counter/main.py`), so the real WebSocket route lives at `/counter/main.py/ws` - but since 1.0 Alpha the FastAPI wrapper always passed the bare default `ws` endpoint name into `FletStaticFiles`, bypassing its mount-path-aware fallback, and `index.html` got patched with `flet.webSocketEndpoint="ws"`, which the web client resolves against the server root. The native iOS/Android client derives the path from the page URL and was unaffected. A relative WebSocket endpoint is now resolved against the app mount path when patching `index.html`, fixing browser access to any Flet web app mounted under a non-root path (`--ios`/`--android`, `flet run --name`, or a `flet_web.fastapi` app mounted at a sub-path) ([#6699](https://github.com/flet-dev/flet/pull/6699)) by @FeodorFitsner.
 * Fix web `RawImage` and `MatplotlibChart` animations flooding the console with uncatchable engine exceptions (and breaking the animation) after the browser tab was backgrounded for a while and then refocused. On Flet web the frame producer runs in a Pyodide worker (or on a remote server over a WebSocket) that the browser never throttles, while the client's Flutter frame pipeline is suspended whenever the tab is hidden - so `setState` schedules frames that never paint and the post-frame callbacks that dispose replaced `ui.Image`s never fire. Decoded images and pending disposals then pile up unbounded in the Dart heap and flush into the engine all at once on resume, one exception per queued frame. This is a client-side accumulation independent of transport, so it also affected native windows minimized with an animation running. Fixed in two layers: (1) a shared `FrameStreamVisibility` client-side mixin - used by both `RawImage` and `flet-charts`' `MatplotlibChartCanvas` - stops decoding/uploading and frees replaced images immediately while hidden (keeping only cheap offscreen state up to date, so incremental matplotlib diffs stay correct), then presents just the latest frame on resume; (2) a new `page.wait_until_visible()` gate (driven by `on_app_lifecycle_state_change`, alongside a `page.app_visible` property) that the streaming controls await internally, so producer loops park while hidden instead of rendering frames a suspended client can only discard ([#6691](https://github.com/flet-dev/flet/issues/6691)) by @FeodorFitsner.
-* Fix `flet build` / `flet publish` flooding non-interactive logs (CI, cloud build, any piped stdout) with thousands of progress-spinner frames, and fix the `--no-rich-output` flag not actually producing plain output. The CLI's rich `Console` was created with `force_terminal=True` whenever the `FLET_CLI_NO_RICH_OUTPUT` env var was unset, which forces the `Live` status spinner to repaint even when stdout isn't a TTY — so in a pipe every animation frame lands on its own line (e.g. hundreds of `( ●    ) Initializing web build...` lines). And the `--no-rich-output` CLI flag never reached that console at all: it's parsed per-command, after the module-level `console` is already built, so it only suppressed emojis while color and the spinner kept going. Now the console auto-detects the terminal (`force_terminal=None`) — interactive terminals keep the animated spinner while piped output stays quiet — and both `FLET_CLI_NO_RICH_OUTPUT` and `--no-rich-output` (detected from `sys.argv` at import) force fully plain output by @FeodorFitsner.
+* Fix `flet build` / `flet publish` flooding non-interactive logs (CI, cloud build, any piped stdout) with thousands of progress-spinner frames, and fix the `--no-rich-output` flag not actually producing plain output. The CLI's rich `Console` was created with `force_terminal=True` whenever the `FLET_CLI_NO_RICH_OUTPUT` env var was unset, which forces the `Live` status spinner to repaint even when stdout isn't a TTY — so in a pipe every animation frame lands on its own line (e.g. hundreds of `( ●    ) Initializing web build...` lines). And the `--no-rich-output` CLI flag never reached that console at all: it's parsed per-command, after the module-level `console` is already built, so it only suppressed emojis while color and the spinner kept going. Now the console auto-detects the terminal (`force_terminal=None`) — interactive terminals keep the animated spinner while piped output stays quiet — and both `FLET_CLI_NO_RICH_OUTPUT` and `--no-rich-output` (detected from `sys.argv` at import) force fully plain output ([#6704](https://github.com/flet-dev/flet/pull/6704)) by @FeodorFitsner.
 
 ### Improvements
 
 * Flutter updated to [3.44.7](https://github.com/flutter/flutter/blob/stable/CHANGELOG.md#3447).
 * Fix `flet_video.Video` resetting its `volume` (and `pitch`, `playback_rate`, `shuffle_playlist`, `playlist_mode`, `subtitle_track`) to the player's defaults after toggling `visible` off then on — e.g. `volume` jumped back to `100`. Hiding a `Video` disposes its native `media_kit` player and showing it recreates a fresh one at default settings; the "last-applied" tracking now lives with the player (not the persistent control model) and is reset on recreation, so `build()` re-applies every setting to the new player ([#6683](https://github.com/flet-dev/flet/issues/6683), [#6694](https://github.com/flet-dev/flet/pull/6694)) by @ndonkoHenri.
 * Fix `SearchBar.on_tap_outside_bar` not firing when the user tapped outside the *open* search view. That case now has a dedicated `SearchBar.on_tap_outside_view` event (fired when tapping outside the open view, e.g. to dismiss it), and `on_tap_outside_bar` is documented to match what it actually does: fire while the bar is focused and the view is closed, like `TextField.on_tap_outside` ([#6593](https://github.com/flet-dev/flet/issues/6593), [#6697](https://github.com/flet-dev/flet/pull/6697)) by @ndonkoHenri.
-* Add a `--android-legacy-packaging` flag (and `[tool.flet.android].legacy_packaging` setting) to `flet build apk`/`aab` for opting into legacy Android native-library packaging. By default (modern packaging), native `.so` files are stored uncompressed and page-aligned in the APK and memory-mapped directly at runtime, which typically gives a smaller install and Play Store download but a larger raw `.apk` file. Enabling this option sets `useLegacyPackaging = true` so the `.so` are compressed inside the APK and extracted to disk on install: the raw `.apk` file is smaller (handy when side-loading), at the cost of a larger on-device install and slower native-library loading. The extraction directory is exposed to Python as `ANDROID_NATIVE_LIBRARY_DIR`, which can help custom native-library consumers that require a real filesystem path. See [Native library packaging](https://flet.dev/docs/publish/android#native-library-packaging-modern-vs-legacy) by @FeodorFitsner.
+* Add a `--android-legacy-packaging` flag (and `[tool.flet.android].legacy_packaging` setting) to `flet build apk`/`aab` for opting into legacy Android native-library packaging. By default (modern packaging), native `.so` files are stored uncompressed and page-aligned in the APK and memory-mapped directly at runtime, which typically gives a smaller install and Play Store download but a larger raw `.apk` file. Enabling this option sets `useLegacyPackaging = true` so the `.so` are compressed inside the APK and extracted to disk on install: the raw `.apk` file is smaller (handy when side-loading), at the cost of a larger on-device install and slower native-library loading. The extraction directory is exposed to Python as `ANDROID_NATIVE_LIBRARY_DIR`, which can help custom native-library consumers that require a real filesystem path. See [Native library packaging](https://flet.dev/docs/publish/android#native-library-packaging-modern-vs-legacy) ([#6698](https://github.com/flet-dev/flet/issues/6698), [#6703](https://github.com/flet-dev/flet/pull/6703)) by @FeodorFitsner.
 
 ## 0.86.1
 
 ### Improvements
 
-* `flet-mcp`'s `get_api` tool now covers **top-level callables** — the app entry point (`run`), reactive hooks (`use_state`, `use_ref`, `use_effect`, …), and decorators (`component`, `memo`, `observable`) — which previously returned `not found` because only classes were indexed. A new `functions` bucket in the API builder extracts each package's re-exported public callables and renders them with a `signature:` line. `get_api` also **resolves enum member lookups inline**: `get_api("Colors", query="RED")` now returns the matching members instead of erroring with a redirect to `search_enum_members`. Both changes remove wasted agent round-trips observed in production usage by @FeodorFitsner.
+* `flet-mcp`'s `get_api` tool now covers **top-level callables** — the app entry point (`run`), reactive hooks (`use_state`, `use_ref`, `use_effect`, …), and decorators (`component`, `memo`, `observable`) — which previously returned `not found` because only classes were indexed. A new `functions` bucket in the API builder extracts each package's re-exported public callables and renders them with a `signature:` line. `get_api` also **resolves enum member lookups inline**: `get_api("Colors", query="RED")` now returns the matching members instead of erroring with a redirect to `search_enum_members`. Both changes remove wasted agent round-trips observed in production usage ([#6680](https://github.com/flet-dev/flet/pull/6680)) by @FeodorFitsner.
 
 ### Bug fixes
 
@@ -81,8 +82,8 @@
 
 * Add support for **Python `multiprocessing` in packaged Flet desktop apps** built with `flet build macos`, `flet build windows`, and `flet build linux`. `multiprocessing` APIs such as `Process`, `ProcessPoolExecutor`, the `spawn`/`forkserver` start methods, and the resource tracker now work in packaged desktop apps. Previously, worker processes re-executed `sys.executable`, which pointed to the app binary itself, causing each worker to launch another GUI app instance and hang. Flet desktop runners now detect CPython multiprocessing child command lines before Flutter starts and divert them to a headless embedded Python interpreter via `dart_bridge` 1.5.0+. The Python bootstrap also runs the app module as the real `sys.modules["__main__"]` with `python -m` semantics, so top-level worker functions in `main.py` can be pickled correctly. When using `multiprocessing`, your app must follow normal Python multiprocessing rules: guard `ft.run(...)` with `if __name__ == "__main__":`, define worker functions at module top level, and do not access Flet UI objects from worker processes. See the new [Multiprocessing](https://docs.flet.dev/cookbook/multiprocessing) cookbook page. Mobile platforms remain unsupported because iOS and Android do not allow apps to spawn arbitrary child processes ([#4283](https://github.com/flet-dev/flet/issues/4283), [#6577](https://github.com/flet-dev/flet/pull/6662)) by @ndonkoHenri.
 * Multi-version bundled CPython support in `flet build` and `flet publish`. Pick the runtime your app ships with via the new `--python-version` flag (3.12 / 3.13 / 3.14), or let it be derived from `[project].requires-python` in your `pyproject.toml`; defaults to the latest supported stable (currently 3.14). The matching CPython-standalone build, Pyodide release (0.27.7 / 0.29.4 / 314.0.1), and Emscripten wheel platform tag are all resolved from `flet-dev/python-build`'s date-keyed manifest. Adding a future pre-release CPython line (e.g. 3.15 beta) is a one-row append with `prerelease=True` — opt-in only via an explicit `--python-version 3.15` or `requires-python = "==3.15.*"`, never the auto-resolved default. Requires `serious_python` >= 4.0.0, now pinned in the `flet build` template. See the new [Choosing a Python version](https://flet.dev/docs/publish#choosing-a-python-version) docs section ([#6577](https://github.com/flet-dev/flet/pull/6577)) by @FeodorFitsner.
-* Add `ft.DataChannel`: dedicated byte channels for widgets that move bulk binary data (image frames, audio buffers, ML tensors) between Dart and Python, bypassing the MsgPack control protocol. The Dart side opens a channel via `FletBackend.of(context).openDataChannel()` and announces it to Python by firing a `data_channel_open` control event with `{channel_name, channel_id}`; the Python side declares `on_data_channel_open: Optional[ft.EventHandler[ft.DataChannelOpenEvent]]` and captures the channel via `self.get_data_channel(e.channel_id)`. Backed by a dedicated `PythonBridge` per channel in embedded native mode (4–7 GiB/s on M2 Pro) and by the default `ProtocolMuxedDataChannelFactory` in dev / web modes (raw-byte frames muxed over the active Flet protocol transport with a 1-byte type discriminator). Pyodide gets zero-copy outbound sends via `postMessage` Transferable ArrayBuffer. First consumer: `flet-charts` `MatplotlibChartCanvas`, migrated from `_invoke_method` PNG dispatch to a 1-byte-opcode data channel by @FeodorFitsner.
-* **In-process Python transport (`dart_bridge` FFI).** `package:flet` gains a third protocol transport alongside the UDS / TCP socket servers: it can run Flet's MsgPack protocol over an in-process `dart_bridge` byte channel via a `FletApp(channelBuilder: …)` seam (the `flet` package stays Python-independent — it doesn't depend on `serious_python` or know about `PythonBridge`; the embedder wires the channel). `serious_python` >= 3.0.0 uses this seam to embed the Python interpreter **in-process** instead of talking to it over a localhost socket, and the `flet build` template migrates from sockets to the FFI transport. On Android, where the OS may keep the process alive across a back-button quit and restart only the Dart VM, the transport rebinds to the new VM's `dart_bridge` ports on a session-restart signal (`libdart_bridge` >= 1.3.0) — the Python process and its in-memory state are preserved and the Flet session is rebuilt from `REGISTER_CLIENT` by @FeodorFitsner.
+* Add `ft.DataChannel`: dedicated byte channels for widgets that move bulk binary data (image frames, audio buffers, ML tensors) between Dart and Python, bypassing the MsgPack control protocol. The Dart side opens a channel via `FletBackend.of(context).openDataChannel()` and announces it to Python by firing a `data_channel_open` control event with `{channel_name, channel_id}`; the Python side declares `on_data_channel_open: Optional[ft.EventHandler[ft.DataChannelOpenEvent]]` and captures the channel via `self.get_data_channel(e.channel_id)`. Backed by a dedicated `PythonBridge` per channel in embedded native mode (4–7 GiB/s on M2 Pro) and by the default `ProtocolMuxedDataChannelFactory` in dev / web modes (raw-byte frames muxed over the active Flet protocol transport with a 1-byte type discriminator). Pyodide gets zero-copy outbound sends via `postMessage` Transferable ArrayBuffer. First consumer: `flet-charts` `MatplotlibChartCanvas`, migrated from `_invoke_method` PNG dispatch to a 1-byte-opcode data channel ([#6601](https://github.com/flet-dev/flet/pull/6601)) by @FeodorFitsner.
+* **In-process Python transport (`dart_bridge` FFI).** `package:flet` gains a third protocol transport alongside the UDS / TCP socket servers: it can run Flet's MsgPack protocol over an in-process `dart_bridge` byte channel via a `FletApp(channelBuilder: …)` seam (the `flet` package stays Python-independent — it doesn't depend on `serious_python` or know about `PythonBridge`; the embedder wires the channel). `serious_python` >= 3.0.0 uses this seam to embed the Python interpreter **in-process** instead of talking to it over a localhost socket, and the `flet build` template migrates from sockets to the FFI transport. On Android, where the OS may keep the process alive across a back-button quit and restart only the Dart VM, the transport rebinds to the new VM's `dart_bridge` ports on a session-restart signal (`libdart_bridge` >= 1.3.0) — the Python process and its in-memory state are preserved and the Flet session is rebuilt from `REGISTER_CLIENT` ([#6601](https://github.com/flet-dev/flet/pull/6601)) by @FeodorFitsner.
 * Add `flet clean` command that deletes the `build` directory of a Flet app — the Flutter bootstrap project, cached artifacts, and generated output — in a single step ([#6233](https://github.com/flet-dev/flet/issues/6233)) by @ndonkoHenri.
 * Add `compression_quality` to `FilePicker.pick_files()` for selecting the image compression quality used by supported platforms ([#6573](https://github.com/flet-dev/flet/pull/6573)) by @ndonkoHenri.
 * Add `ConsentManager` to `flet-ads` for gathering user consent (e.g. GDPR/EEA) via Google's User Messaging Platform (UMP) before requesting ads ([#6569](https://github.com/flet-dev/flet/issues/6569), [#6615](https://github.com/flet-dev/flet/pull/6615)) by @ndonkoHenri.
@@ -90,26 +91,26 @@
 
 ### Improvements
 
-* **Swift Package Manager for iOS/macOS builds (on by default).** `flet build` / `flet debug` now integrate the embedded Python runtime via SPM instead of CocoaPods (CocoaPods goes read-only in December 2026). Flet **auto-falls back to CocoaPods** when the app depends on a package that isn't SPM-ready — currently `flet-video` (media_kit) — since Flutter then builds the whole app with CocoaPods. Force CocoaPods for other non-SPM packages with `--no-swift-package-manager` (or `swift_package_manager = false` under `[tool.flet]`). Flet does **not** change Flutter's global SPM configuration; the setting only selects how `serious_python` stages the runtime to match. When SPM is used (it has no `pod install` hook), `flet build` sets `SERIOUS_PYTHON_DARWIN_SPM` so `serious_python`'s `package` step stages the runtime (Python/dart_bridge xcframeworks, the iOS native extensions, and the stdlib/site-packages/app resources) into the plugin's `Package.swift` layout on the host before `flutter build`, and exports the `SP_NATIVE_SET` cache-bust key into the build. Requires the SPM-capable `serious_python` release.
-* **Smaller Android apps with no native-packaging config.** `flet build apk`/`aab` consume serious_python's new Android packaging: Python extension modules load **memory-mapped directly from the APK** (no extraction to disk), and pure Python ships in stored asset zips read via `zipimport`, so the standard library is no longer duplicated per ABI. Apps no longer need `useLegacyPackaging` / `keepDebugSymbols` — the `flet build` Android template drops them; just use `minSdk 23+`. New `--android-extract-packages` flag and `[tool.flet.android].extract_packages` ship "path-hungry" packages — those that read bundled data via `__file__` / `pkg_resources` instead of `importlib.resources` — extracted to disk instead of inside the zip (most packages, including `certifi`, are zip-safe and need no entry). Requires `serious_python` with the native-mmap packaging (dart_bridge 1.4.0).
+* **Swift Package Manager for iOS/macOS builds (on by default).** `flet build` / `flet debug` now integrate the embedded Python runtime via SPM instead of CocoaPods (CocoaPods goes read-only in December 2026). Flet **auto-falls back to CocoaPods** when the app depends on a package that isn't SPM-ready — currently `flet-video` (media_kit) — since Flutter then builds the whole app with CocoaPods. Force CocoaPods for other non-SPM packages with `--no-swift-package-manager` (or `swift_package_manager = false` under `[tool.flet]`). Flet does **not** change Flutter's global SPM configuration; the setting only selects how `serious_python` stages the runtime to match. When SPM is used (it has no `pod install` hook), `flet build` sets `SERIOUS_PYTHON_DARWIN_SPM` so `serious_python`'s `package` step stages the runtime (Python/dart_bridge xcframeworks, the iOS native extensions, and the stdlib/site-packages/app resources) into the plugin's `Package.swift` layout on the host before `flutter build`, and exports the `SP_NATIVE_SET` cache-bust key into the build. Requires the SPM-capable `serious_python` release ([#6608](https://github.com/flet-dev/flet/pull/6608)).
+* **Smaller Android apps with no native-packaging config.** `flet build apk`/`aab` consume serious_python's new Android packaging: Python extension modules load **memory-mapped directly from the APK** (no extraction to disk), and pure Python ships in stored asset zips read via `zipimport`, so the standard library is no longer duplicated per ABI. Apps no longer need `useLegacyPackaging` / `keepDebugSymbols` — the `flet build` Android template drops them; just use `minSdk 23+`. New `--android-extract-packages` flag and `[tool.flet.android].extract_packages` ship "path-hungry" packages — those that read bundled data via `__file__` / `pkg_resources` instead of `importlib.resources` — extracted to disk instead of inside the zip (most packages, including `certifi`, are zip-safe and need no entry). Requires `serious_python` with the native-mmap packaging (dart_bridge 1.4.0) ([#6601](https://github.com/flet-dev/flet/pull/6601)).
 * Pyodide is no longer pre-baked into the `flet build` template. Each `flet build web` / `flet publish` run downloads the matching `pyodide-core-<version>.tar.bz2` (plus the runtime `micropip` and `packaging` wheels) into a per-version cache at `~/.flet/pyodide/<version>/` and copies the files into the build output. Subsequent builds reuse the cache; the older `0.27.5` bundle previously shipped in the cookiecutter template is gone ([#6577](https://github.com/flet-dev/flet/pull/6577)) by @FeodorFitsner.
 * The supported Python / Pyodide / dart_bridge versions are loaded on demand from `flet-dev/python-build`'s date-keyed `manifest.json` (fetched once and cached under `~/.flet/cache`), the single source of truth shared with `serious_python` — replacing flet's hand-mirrored version table. `flet build` forwards only `SERIOUS_PYTHON_VERSION` and lets `serious_python` derive the full version / build date / dart_bridge version from its own committed snapshot. The module exposes `get_supported_python_versions()` / `get_default_python_version()` (the previous `SUPPORTED_PYTHON_VERSIONS` / `DEFAULT_PYTHON_VERSION` constants are removed) ([#6577](https://github.com/flet-dev/flet/pull/6577)) by @FeodorFitsner.
 * `flet --version` shows just the Flet and Flutter versions; the static `Pyodide: …` line and the global `flet.version.pyodide_version` export are removed (the supported Python / Pyodide set now lives in python-build's manifest, not the CLI output) ([#6577](https://github.com/flet-dev/flet/pull/6577)) by @FeodorFitsner.
-* `flet --version --json` emits a machine-readable document — Flet/Flutter versions and the Linux build dependencies — for CI to read via `jq` instead of importing Flet internals with `python -c`. (The supported Python/Pyodide table is no longer included; it comes from python-build's manifest.) The canonical Linux apt dependency list moved from `flet.utils.linux_deps` (runtime package) to `flet_cli.utils.linux_deps` (build tooling) by @FeodorFitsner.
+* `flet --version --json` emits a machine-readable document — Flet/Flutter versions and the Linux build dependencies — for CI to read via `jq` instead of importing Flet internals with `python -c`. (The supported Python/Pyodide table is no longer included; it comes from python-build's manifest.) The canonical Linux apt dependency list moved from `flet.utils.linux_deps` (runtime package) to `flet_cli.utils.linux_deps` (build tooling) ([#6601](https://github.com/flet-dev/flet/pull/6601)) by @FeodorFitsner.
 * `client/web/python.js` and the build template's `python.js` no longer hardcode `defaultPyodideUrl`. `patch_index.py` now injects `flet.pyodideUrl` per build (CDN URL by default, or the local `pyodide/pyodide.js` path under `--no-cdn`) so the runtime URL always tracks the resolved Pyodide release ([#6577](https://github.com/flet-dev/flet/pull/6577)) by @FeodorFitsner.
-* Stream-oriented Flet protocol transports (UDS / TCP used by `flet run` dev mode) now use length-prefixed framing instead of streaming `msgpack.Unpacker.feed`. Combined with a new 1-byte type discriminator at the head of every packet (`0x00` = MsgPack control frame, `0x01` = raw DataChannel frame), this unifies framing across all transports (sockets, WebSocket, `dart_bridge` FFI, Pyodide `postMessage`). `StreamingMsgpackDeserializer` is removed from `package:flet`; each inbound packet is one complete MsgPack value, decoded one-shot via `msgpack.deserialize(bytes)` by @FeodorFitsner.
-* Bump the bundled Flutter to **3.44.2** (from 3.41.7). The Flet client and the `flet build` template migrate to Flutter 3.44's built-in Kotlin (the Android app no longer applies the Kotlin Gradle plugin itself) and Java 17; the client's Gradle wrapper moves to 8.14 by @FeodorFitsner.
+* Stream-oriented Flet protocol transports (UDS / TCP used by `flet run` dev mode) now use length-prefixed framing instead of streaming `msgpack.Unpacker.feed`. Combined with a new 1-byte type discriminator at the head of every packet (`0x00` = MsgPack control frame, `0x01` = raw DataChannel frame), this unifies framing across all transports (sockets, WebSocket, `dart_bridge` FFI, Pyodide `postMessage`). `StreamingMsgpackDeserializer` is removed from `package:flet`; each inbound packet is one complete MsgPack value, decoded one-shot via `msgpack.deserialize(bytes)` ([#6601](https://github.com/flet-dev/flet/pull/6601)) by @FeodorFitsner.
+* Bump the bundled Flutter to **3.44.2** (from 3.41.7). The Flet client and the `flet build` template migrate to Flutter 3.44's built-in Kotlin (the Android app no longer applies the Kotlin Gradle plugin itself) and Java 17; the client's Gradle wrapper moves to 8.14 ([#6601](https://github.com/flet-dev/flet/pull/6601)) by @FeodorFitsner.
 * **Raw RGBA Matplotlib frames on local transports.** `MatplotlibChart` now skips per-frame diffing and PNG encode/decode when the client runs on the same machine: uncompressed RGBA full frames stream straight from Agg's buffer over the chart's `DataChannel` (new `0x04` opcode) and are displayed with a single `decodeImageFromPixels` + swap on the Dart side. A 1600×1000 @ DPR 2 figure (24 MB/frame) over a local socket goes from 7.4 to 18.7 fps, leaving matplotlib's own render as the dominant per-frame cost; remote WebSocket clients keep the compact PNG full+diff pipeline. The format is auto-selected via the new `Connection.local_data_transport` capability flag (set by the socket, `dart_bridge` and Pyodide transports). Also fixes O(n²) length-prefixed packet reassembly in the Dart socket transport — multi-MB frames arrive in dozens of chunks and previously re-flattened the accumulation buffer on every chunk ([#6673](https://github.com/flet-dev/flet/pull/6673)) by @FeodorFitsner.
 * `flet build web` and `flet publish` now default the web renderer to `canvaskit` instead of `auto`. With `auto`, Chromium selects the dart2wasm/skwasm renderer, whose JS↔Dart typed-data boundary costs make byte-streaming Pyodide apps (matplotlib frames, `RawImage`) ~6–7x slower per frame; pass `--renderer auto` or set `[tool.flet.web].renderer` to restore the old behavior. Also fixes `tool.flet.web.renderer` being ignored by `flet publish` (shadowed by an argparse default) ([#6673](https://github.com/flet-dev/flet/pull/6673)) by @FeodorFitsner.
 * **Faster mobile cold start: `import flet` is now lazy.** The `flet` package previously executed its full ~270-module public API eagerly on `import flet`; it now resolves public names on first access via a module-level `__getattr__` (PEP 562), so an app loads only the modules it actually uses. On a mid-range Android device this cut `import flet` from ~2.0s to ~0.15s. The eager subsystem clusters that `Page` pulled in (auth, components/hooks, Cupertino controls) are deferred too. Type checkers, IDEs, and `from flet import *` are unaffected ([#6597](https://github.com/flet-dev/flet/pull/6597)) by @FeodorFitsner.
 
 ### Breaking changes
 
-* **App files now ship unpacked in a read-only bundle, and the storage directories were reworked** (requires `serious_python` >= 4.0.0, now pinned in the `flet build` template). Your Python sources ship **unpacked inside the app bundle** next to the stdlib/site-packages (no first-launch `app.zip` extraction) on macOS/iOS/Windows/Linux; on Android they ship as a *stored* `app.zip` asset unpacked once on first launch; web is unchanged. The app directory is now **read-only**, so the Python program's **working directory** moved to a writable, app-private data dir. `FLET_APP_STORAGE_DATA` now maps to the OS *application support* dir (a `data` subdir) instead of the user's Documents folder and is the cwd; `FLET_APP_STORAGE_TEMP` now points to the OS temp dir (was the cache dir) and a new `FLET_APP_STORAGE_CACHE` exposes the cache dir. `flet run` sets the dev cwd to a hidden, git-ignored `<project>/.flet/storage/data`. Relative **reads** of bundled files (`open("seed.json")`) must move to `__file__`/`importlib.resources` or `assets/`. See the [app files unpacked / storage dirs](/docs/updates/breaking-changes/v0-86-0/app-files-unpacked-read-only-bundle) guide by @FeodorFitsner.
+* **App files now ship unpacked in a read-only bundle, and the storage directories were reworked** (requires `serious_python` >= 4.0.0, now pinned in the `flet build` template). Your Python sources ship **unpacked inside the app bundle** next to the stdlib/site-packages (no first-launch `app.zip` extraction) on macOS/iOS/Windows/Linux; on Android they ship as a *stored* `app.zip` asset unpacked once on first launch; web is unchanged. The app directory is now **read-only**, so the Python program's **working directory** moved to a writable, app-private data dir. `FLET_APP_STORAGE_DATA` now maps to the OS *application support* dir (a `data` subdir) instead of the user's Documents folder and is the cwd; `FLET_APP_STORAGE_TEMP` now points to the OS temp dir (was the cache dir) and a new `FLET_APP_STORAGE_CACHE` exposes the cache dir. `flet run` sets the dev cwd to a hidden, git-ignored `<project>/.flet/storage/data`. Relative **reads** of bundled files (`open("seed.json")`) must move to `__file__`/`importlib.resources` or `assets/`. See the [app files unpacked / storage dirs](/docs/updates/breaking-changes/v0-86-0/app-files-unpacked-read-only-bundle) guide ([#6608](https://github.com/flet-dev/flet/pull/6608)) by @FeodorFitsner.
 * `flet build` and `flet publish` now bundle CPython 3.14 by default (previously 3.12, implicit via the old single-version `serious_python`). Existing apps that depend on native wheels without 3.14 binaries should pin explicitly with `--python-version 3.12` (CLI), `requires-python = ">=3.12,<3.13"` (pyproject), or `SERIOUS_PYTHON_VERSION=3.12` in the build environment ([#6577](https://github.com/flet-dev/flet/pull/6577)) by @FeodorFitsner.
 * Android builds now include only the ABIs the bundled Python supports, sourced per-version from python-build's manifest (`pythons.<short>.android_abis`) rather than hardcoded in flet. As of python-build `20260630`, `armeabi-v7a` (32-bit ARM) is published for **3.12, 3.13 and 3.14**, so all three build it by default; an explicit `--arch <abi>` is validated against the selected Python's supported set and fails with a clear error otherwise ([#6578](https://github.com/flet-dev/flet/pull/6578)) by @ndonkoHenri.
 * `flet build` / `flet publish` now **compile your app and packages to `.pyc` by default** (previously off). This removes per-launch bytecode recompilation — a significant cold-start win, especially on mobile where pure Python is imported from a stored zip (`zipimport`) and can't cache bytecode back to disk, so every module would otherwise recompile from source on each launch. The CLI flags gain `--no-compile-app` / `--no-compile-packages` (via `argparse.BooleanOptionalAction`; the existing `--compile-app` / `--compile-packages` still work), and `[tool.flet.compile].app` / `.packages` now default to `true`. Pass `--no-compile-*` or set them to `false` to restore the old behavior (faster iterative builds, or keeping `.py` source in the bundle). Compiled web builds were verified to load in Pyodide (bundled CPython and Pyodide share the same minor version). See the [compile-on-by-default](/docs/updates/breaking-changes/v0-86-0/compile-on-by-default) guide ([#6598](https://github.com/flet-dev/flet/pull/6598)) by @FeodorFitsner.
-* Flet protocol wire format on stream-oriented transports (UDS / TCP) is incompatible with pre-0.86 servers and clients. Every packet now starts with a 4-byte little-endian length prefix and a 1-byte type discriminator (`0x00` = MsgPack control frame, `0x01` = raw DataChannel frame). WebSocket / `postMessage` / `dart_bridge` transports keep native message boundaries and only gain the type byte. The Flet CLI dev server and the in-process Python runtime are upgraded in lockstep — running `flet run` with mismatched `flet` versions across CLI and runtime is no longer supported. See the [DataChannel protocol framing upgrade](/docs/updates/breaking-changes/v0-86-0/data-channel-protocol-upgrade) guide. The `MatplotlibChartCanvas` widget transports its full / diff / clear frames via a `DataChannel` rather than `_invoke_method` arguments — visually identical, but custom code that subclassed it and overrode the apply methods may need updating by @FeodorFitsner.
+* Flet protocol wire format on stream-oriented transports (UDS / TCP) is incompatible with pre-0.86 servers and clients. Every packet now starts with a 4-byte little-endian length prefix and a 1-byte type discriminator (`0x00` = MsgPack control frame, `0x01` = raw DataChannel frame). WebSocket / `postMessage` / `dart_bridge` transports keep native message boundaries and only gain the type byte. The Flet CLI dev server and the in-process Python runtime are upgraded in lockstep — running `flet run` with mismatched `flet` versions across CLI and runtime is no longer supported. See the [DataChannel protocol framing upgrade](/docs/updates/breaking-changes/v0-86-0/data-channel-protocol-upgrade) guide. The `MatplotlibChartCanvas` widget transports its full / diff / clear frames via a `DataChannel` rather than `_invoke_method` arguments — visually identical, but custom code that subclassed it and overrode the apply methods may need updating ([#6601](https://github.com/flet-dev/flet/pull/6601)) by @FeodorFitsner.
 
 ### Deprecations
 
@@ -119,9 +120,9 @@
 
 * Fix a debug-mode `'!_dirty': is not true` assertion (`EXCEPTION CAUGHT BY WIDGETS LIBRARY` in `_BootOverlay`) thrown by apps built or debugged from the `flet build` template when the app becomes ready. With the default `boot_screen.fade_out_duration` of 0 the overlay's zero-duration `AnimatedOpacity` completed synchronously, firing `onEnd` — and its `setState` — in the middle of the overlay's own rebuild. The overlay is now removed in a single state update when no fade is configured; non-zero fade durations still animate as before. Debug-mode only: the assertion is compiled out of release builds ([#6666](https://github.com/flet-dev/flet/pull/6666)) by @FeodorFitsner.
 * Fix `flet build` failing on Windows when a dependency is pulled in via `[tool.flet.<platform>].dev_packages` (or any local-path install): the rewritten `<pkg> @ file://<path>` URL now uses `Path.as_uri()`, producing the correct `file:///D:/...` three-slash form instead of `file://D:\...`, which pip on Windows parsed as a UNC path and aborted with `OSError: [Errno 2] No such file or directory: '\\\\D:\\a\\...'` ([#6577](https://github.com/flet-dev/flet/pull/6577)) by @FeodorFitsner.
-* Fix `flet build web --python-version 3.13` failing to match any Pyodide-built native wheel. The 3.13 row in the Python version registry was set to Pyodide platform tag `pyodide-2025.0-wasm32`, but Pyodide actually publishes 0.29 wheels under `pyemscripten_2025_0_wasm32` (the `pyodide_` → `pyemscripten_` prefix transition happened at 0.28/0.29, not at 314.0). Corrected to `pyemscripten-2025.0-wasm32` so pip's wheel selection picks up the correct tags by @FeodorFitsner.
-* `flet build` now cleans the build directory when the bundled Python version changes between builds, preventing stale compiled bytecode from the previous version crashing the app at runtime with `ImportError: bad magic number` by @FeodorFitsner.
-* Fix locating Flet controls by their user-assigned `key` in tests. `ValueKey(control.key)` was constructed as `ValueKey<Object>`, and Flutter's runtimeType-strict `ValueKey.==` never matches that against the `ValueKey<String>` the rendered widget carries — so `find.byKey(Key('foo'))` (flutter_test) and `find_by_key('foo')` (Flet tester) located 0 widgets. The `ValueKey` is now built with the value's concrete type (String → `ValueKey<String>`, int → `ValueKey<int>`, …) on both the Dart and Python sides by @FeodorFitsner.
+* Fix `flet build web --python-version 3.13` failing to match any Pyodide-built native wheel. The 3.13 row in the Python version registry was set to Pyodide platform tag `pyodide-2025.0-wasm32`, but Pyodide actually publishes 0.29 wheels under `pyemscripten_2025_0_wasm32` (the `pyodide_` → `pyemscripten_` prefix transition happened at 0.28/0.29, not at 314.0). Corrected to `pyemscripten-2025.0-wasm32` so pip's wheel selection picks up the correct tags ([#6601](https://github.com/flet-dev/flet/pull/6601)) by @FeodorFitsner.
+* `flet build` now cleans the build directory when the bundled Python version changes between builds, preventing stale compiled bytecode from the previous version crashing the app at runtime with `ImportError: bad magic number` ([#6601](https://github.com/flet-dev/flet/pull/6601)) by @FeodorFitsner.
+* Fix locating Flet controls by their user-assigned `key` in tests. `ValueKey(control.key)` was constructed as `ValueKey<Object>`, and Flutter's runtimeType-strict `ValueKey.==` never matches that against the `ValueKey<String>` the rendered widget carries — so `find.byKey(Key('foo'))` (flutter_test) and `find_by_key('foo')` (Flet tester) located 0 widgets. The `ValueKey` is now built with the value's concrete type (String → `ValueKey<String>`, int → `ValueKey<int>`, …) on both the Dart and Python sides ([#6601](https://github.com/flet-dev/flet/pull/6601)) by @FeodorFitsner.
 * Fix `flet build apk` / `flet build aab` with `--arch` packaging native libraries for *all* Android ABIs instead of only the requested ones. The requested architectures are now forwarded to Flutter as `--target-platform` (so `--split-per-abi` builds only the requested splits), unrequested ABI directories are excluded from the artifact via `packaging.jniLibs.excludes`, Android `--arch` values are validated against the bundled Python's supported ABIs, multiple `--arch` values now correctly reach `serious_python` (comma-joined), and stale artifacts from previous builds are no longer copied into the output directory ([#6567](https://github.com/flet-dev/flet/issues/6567), [#6578](https://github.com/flet-dev/flet/pull/6578)) by @ndonkoHenri.
 * Fix repeated `--arch`, `--source-packages` and `--permissions` flags in `flet build` keeping only the values of the last occurrence (`action="extend"` on each) ([#6578](https://github.com/flet-dev/flet/pull/6578)) by @ndonkoHenri.
 * Fix `flet build apk` failing at `mergeDebugNativeLibs` with `N files found with path 'lib/<abi>/libc++_shared.so'` when an app combines `serious_python_android` with another Flutter plugin that also bundles the NDK C++ runtime ([#6570](https://github.com/flet-dev/flet/issues/6570), [#6571](https://github.com/flet-dev/flet/pull/6571)) by @ndonkoHenri.
diff --git a/packages/flet/lib/src/controls/cupertino_radio.dart b/packages/flet/lib/src/controls/cupertino_radio.dart
index 66c442e907..4679c13217 100644
--- a/packages/flet/lib/src/controls/cupertino_radio.dart
+++ b/packages/flet/lib/src/controls/cupertino_radio.dart
@@ -55,6 +55,7 @@ class _CupertinoRadioControlState extends State<CupertinoRadioControl>
     var value = widget.control.getString("value", "")!;
 
     var cupertinoRadio = CupertinoRadio<String>(
+      enabled: !widget.control.disabled,
       autofocus: widget.control.getBool("autofocus", false)!,
       focusNode: _focusNode,
       value: value,
diff --git a/packages/flet/lib/src/controls/radio.dart b/packages/flet/lib/src/controls/radio.dart
index 64ef533ddc..d32477d9ce 100644
--- a/packages/flet/lib/src/controls/radio.dart
+++ b/packages/flet/lib/src/controls/radio.dart
@@ -83,11 +83,13 @@ class _RadioControlState extends State<RadioControl> {
         widget.control.getLabelPosition("label_position", LabelPosition.right)!;
     var labelStyle =
         widget.control.getTextStyle("label_style", Theme.of(context));
-    if (widget.control.disabled && labelStyle != null) {
-      labelStyle = labelStyle.apply(color: Theme.of(context).disabledColor);
+    if (widget.control.disabled) {
+      labelStyle = (labelStyle ?? const TextStyle())
+          .apply(color: Theme.of(context).disabledColor);
     }
 
     var radio = Radio<String>(
+      enabled: !widget.control.disabled,
       autofocus: widget.control.getBool("autofocus", false)!,
       focusNode: _focusNode,
       mouseCursor: widget.control.getMouseCursor("mouse_cursor"),