Bump to Flutter 3.44.7 (1.4.2), fix Platform.isTvOS in debug builds - #41
Merged
Conversation
Flutter 3.44.7 contains nothing that reaches the tvOS engine, so the
engine artifacts are republished under the new name rather than rebuilt:
v1.0.1-flutter3.44.7 is byte-identical to v1.0.1-flutter3.44.6.
What is actually in the 3.44.6..3.44.7 range: one functional change,
Android-side (FlutterRenderer.java, texture SyncFence lifetime). DEPS is
byte-identical (same SHA1), the Dart submodule is unchanged, and
darwin/, ios/ and impeller/ are untouched. The remaining four commits
are CI config and changelog text. An unchanged Dart submodule is what
makes this safe — the SDK hash our AOT artifacts embed does not move, so
gen_snapshot and the patched flutter_patched_sdk stay compatible.
Verified rather than assumed, using the artifacts as published and
fetched fresh through precache with the local artifacts/ cache moved
aside to force the download path:
AOT/profile, physical Apple TV 4K (tvOS 26.5)
operatingSystem=tvos isIOS=true isTvOS=true
defaultTargetPlatform=TargetPlatform.iOS
JIT/debug, tvOS 17.5 simulator
runs clean, zero "Target OS is incompatible"
verify_artifacts.sh passed, incl. designated-requirement signing
CLI suite 297 passed; analyze reports no errors/warnings
The 17.5 run matters because tvOS 26 tolerates a wrong metallib triple
and older runtimes do not — it confirms the issue #38 fix still holds.
Also recorded a pre-existing limitation found while probing: Platform.isTvOS
compiles only in profile/release. Debug compiles against the stock Flutter
SDK, which has no such getter, so an app using it fails to build in debug
with "Member not found: 'isTvOS'". Reproduced identically on 1.4.1, so it
is not introduced here. Platform.operatingSystem == 'tvos' works in every
mode.
The README tells apps to distinguish Apple TV with Platform.isTvOS, but
that only ever worked in profile/release. A debug build failed with
`Member not found: 'isTvOS'`, which reproduces identically on 1.4.1, so
this has been broken since the getter was introduced.
TvosArtifacts pointed the patched flutter_patched_sdk override at
precompiled modes only, reasoning that debug resolves platform identity
at runtime via the device engine so the compile SDK is irrelevant. That
reasoning holds for the *values*: in JIT, dart:io comes from the engine's
own patched core libraries, which is why operatingSystem and isIOS were
already correct in debug. What it misses is that isTvOS is a member the
stock SDK does not declare at all, and the frontend server type-checks
against the compile SDK before any of that runtime resolution happens.
So debug now uses the same non-product patched SDK as profile. The
host_debug_unopt artifact already shipped it — verify_artifacts.sh has
been asserting the isTvOS patch is present in it all along; nothing was
wiring it up.
Verified, since the old comment's worry was disturbing the proven debug
path:
debug compile, Platform.isTvOS builds (was: Member not found)
debug run, tvOS 17.5 simulator isTvOS=true, isIOS=true,
operatingSystem=tvos,
isAndroid/isMacOS unaffected
AOT/profile, physical Apple TV 4K unchanged
hot reload Reloaded 1 of 755 libraries, 190ms
CLI suite 297 pass; analyze clean
The two tests asserting debug fell through to stock resolution encoded
the old decision and failed, which is what they were for; they now assert
the patched SDK, plus a case for a null mode resolving to the non-product
SDK rather than silently picking the product one.
DenisovAV
approved these changes
Jul 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two independent changes, one commit each.
1. Flutter 3.44.7 — no engine rebuild
Nothing in 3.44.7 reaches the tvOS engine, so
v1.0.1-flutter3.44.7is byte-identical tov1.0.1-flutter3.44.6, republished under the new name rather than rebuilt.What's actually in the range:
FlutterRenderer.java, textureSyncFencelifetime)engine/src/flutter/DEPSdarwin/·ios/·impeller/The other four commits are CI config and changelog text. The unchanged Dart submodule is what makes this safe — the SDK hash our AOT artifacts embed doesn't move, so
gen_snapshotand the patchedflutter_patched_sdkstay kernel-compatible. (Patch bumps have needed a rebuild before, when Dart did move.)Tagged
v1.0.1, notv1.0.0: av1.0.0-flutter3.44.7would read as though it predates the metallib fix.Verified rather than assumed — artifacts fetched fresh through
precachewith the localartifacts/cache moved aside to force the download path:The 17.5 run is the one that matters: tvOS 26 tolerates a wrong metallib triple and older runtimes don't, so it's the only place the #38 class of bug is visible.
2.
Platform.isTvOSnow compiles in debugThe README tells apps to distinguish Apple TV with
Platform.isTvOS, but that only ever worked in profile/release — a debug build failed withMember not found: 'isTvOS'. Reproduced identically on 1.4.1, so this has been broken since the getter was introduced, and it's unrelated to the version bump.TvosArtifactsapplied the patched-SDK override to precompiled modes only, reasoning that debug resolves platform identity at runtime via the device engine so the compile SDK is irrelevant. That's true for the values — in JITdart:iocomes from the engine's own patched core libraries, which is whyoperatingSystemandisIOSwere already correct in debug. What it misses is thatisTvOSis a member the stock SDK doesn't declare at all, and the frontend server type-checks against the compile SDK before any runtime resolution happens.Debug now uses the same non-product patched SDK as profile.
host_debug_unoptalready shipped it —verify_artifacts.shhas been asserting that patch is present in it all along; nothing was wiring it up.Verified, since the old comment's stated worry was disturbing the proven debug path:
The two tests asserting debug fell through to stock resolution encoded the old decision and failed — which is what they were for. They now assert the patched SDK, plus a case covering a null mode resolving to the non-product SDK rather than silently picking the product one.