Use case

There is currently no reliable way for a Flutter application to know which version of it is actually running:

• On Android/iOS/macOS, plugins like package_info_plus read the version from the installed binary — reliable, but requires a plugin and a platform channel for a value the tool knew at compile time.
• On the web, it is broken by design: package_info_plus fetches version.json from the server at runtime (with a cache buster). That file reflects the currently deployed version — not the (possibly stale, cached) bundle executing in the browser. A stale client therefore self-reports as up to date, and every "please update" gate or version display built on it silently fails for exactly the users it exists for ([Bug]: [package_info_plus] Web: Version info returns next version in server fluttercommunity/plus_plugins#2675, also Support text selections #225, Import path.dart as path rather than p #456). This is silently shipping wrong version numbers in production apps today, through a Flutter Favorite package.

We hit this in production: users stuck for weeks on an outdated web bundle because the minimum-version gate compared the server's version against the server's minimum.

Proposal

Complete a pattern the tool already implements. flutter_tools already injects as dart-defines:

• FLUTTER_VERSION, FLUTTER_CHANNEL, FLUTTER_GIT_URL, FLUTTER_FRAMEWORK_REVISION, FLUTTER_ENGINE_REVISION, FLUTTER_DART_VERSION → exposed as FlutterVersion constants in package:flutter/services.dart
• FLUTTER_APP_FLAVOR → exposed as appFlavor

The application's own version: from pubspec.yaml is the single missing field — even though the tool already parses it (FlutterManifest.buildName/buildNumber) and already embeds it into version.json, Info.plist, and build.gradle on every build.

Proposed: inject FLUTTER_BUILD_NAME / FLUTTER_BUILD_NUMBER (from --build-name/--build-number, falling back to the pubspec version) exactly like FLUTTER_APP_FLAVOR, and expose them as appBuildName / appBuildNumber constants in services.dart. A compile-time constant is by definition the version of the code that is executing — it cannot diverge from the running bundle, works offline, and needs no platform channel.

Privacy/size note: like every String.fromEnvironment constant, these are tree-shaken when unreferenced — nothing ships in the binary unless the app actually reads them. (The tool also already embeds strictly more metadata unconditionally via FlutterVersion, including the SDK git URL.)

Prior art / history

• "Static" versioning in flutter web #149725 asked for exactly this and was closed as a "Dart language feature request" after a supportive comment from the web team — but the value can only come from the front-end that parses pubspec.yaml, which for Flutter apps is flutter_tools, not the Dart SDK. The thread is now locked, hence this issue.
• Have a way to retrieve the version from pubspec dart-lang/sdk#38855 — the same request on the pure-Dart side, open since 2019. A companion proposal there covers dart compile (servers/CLIs); neither side subsumes the other since Flutter does not build through dartdev.
• [WEB] Web Cache invalidation based on pubspec.yaml version #149031 — the broader "tell the user a new web version exists" problem, which is unsolvable without knowing the running version.
• feat(package_info_plus): add opt-in compile-time package info accessor fluttercommunity/plus_plugins#3874 — package_info_plus is ready to consume these defines the moment they exist, making the fix transparent for the whole ecosystem.

Implementation

A PR implementing this (tool injection mirroring the kAppFlavor guard pattern + services.dart constants + tests) is attached.