meshagent_flutter_desktop_updater 0.51.5

Shared desktop update bridge for MeshAgent Flutter apps.

meshagent_flutter_desktop_updater

Shared desktop update bridge for MeshAgent Flutter apps.

This package owns the Flutter-facing update state machine for MeshAgent Flutter desktop apps that need custom in-app update UI. Apps provide update configuration through Dart defines. The package checks for updates on startup, keeps polling while the app is running, and exposes update states that can drive a banner or custom UI. Apps can use DesktopUpdateRestartBanner for the standard MeshAgent update UI, or render their own UI from DesktopUpdateController.state.

The macOS implementation uses Sparkle 2. The Windows implementation uses MSIX/App Installer APIs and requires an App Installer install source.

Apps should call DesktopUpdateController.startUpdateChecks() once during startup. A positive UPDATE_POLL_INTERVAL_SECONDS value performs an immediate check and then starts recurring polling.

The controller also keeps native desktop update commands synchronized with its state. macOS places the command in the application menu; Windows places it in the window system menu. Applications listen to DesktopUpdateController.applicationMenuActions and open their normal update dialog for check actions or call restartToUpdate() for install actions.

Environment

• UPDATE_URL: exact Sparkle appcast URL for the current app and flavor. Required on macOS; Windows uses the MSIX App Installer source recorded at install time.
• UPDATE_CHANNEL: flavor/channel name, such as life, com, prod, or local-life.
• UPDATE_POLL_INTERVAL_SECONDS: update check interval while the app is running. A positive value checks immediately at startup and then repeats at that interval; omit it or set it to 0 to disable update checks.
• UPDATE_DEBUG_READY_VERSION: test-only version string that simulates a downloaded update and shows "Restart to update" without an update payload. Restarting relaunches the current desktop app without installing anything. Pair it with a positive UPDATE_POLL_INTERVAL_SECONDS value when testing through normal app startup.

macOS Sparkle setup

Apps must provide a Sparkle public EdDSA key in the macOS app bundle with SUPublicEDKey. Powerboards and Studio wire this through the SPARKLE_PUBLIC_ED_KEY xcconfig value.

Sandboxed macOS apps must also enable Sparkle's installer launcher service with SUEnableInstallerLauncherService and allow the Sparkle XPC services in app entitlements:

• $(PRODUCT_BUNDLE_IDENTIFIER)-spks
• $(PRODUCT_BUNDLE_IDENTIFIER)-spki

Sparkle reads the appcast URL dynamically from UPDATE_URL, so each app/flavor can point at a different feed without separate native code. The appcast should use Sparkle channels matching UPDATE_CHANNEL when a feed contains multiple flavors.

For local UI testing on macOS without a signed appcast, use UPDATE_DEBUG_READY_VERSION with a positive UPDATE_POLL_INTERVAL_SECONDS; that path bypasses Sparkle installation and relaunches the current app directly.

Windows MSIX setup

Windows updates are handled by MSIX/App Installer. Configure one MSIX identity and App Installer feed per app/flavor. The native bridge checks the current package's App Installer feed, reports updateAvailable or updateRequired, and starts the App Installer update flow when the user presses the banner button.

The repo-level Windows packaging flow lives in scripts/windows. It keeps signing certificate details and hosting URLs out of app pubspec.yaml files while still publishing flavor-specific .appinstaller feeds.

The MSIX manifest must include the restricted packageManagement capability so the app can call the App Installer update APIs.