upgrader: a Flutter widget that nags users into a new app version

Why nag users at all when stores auto-update

The upgrader package is described as a Flutter package for prompting users to upgrade when there is a newer version of the app in the store. The overview explains when that is worth doing.

With today's modern app stores, the README says there is little need to persuade users to upgrade, because most are already using the auto upgrade feature. The cases it names are narrower. Sometimes an app needs to be updated more quickly than usual, and nagging a user will entice the upgrade sooner. And with Flutter supporting more than just Android and iOS, it becomes more likely that users on other app stores need to be nagged about upgrading.

That second point is the design rationale. Flutter's cross-platform reach means apps land on desktop and web stores where no auto-update mechanism exists, and on those platforms nothing prompts the user at all. A package that checks and prompts fills a gap that the platform leaves open.

The feature list in the README is small. When a newer app version is available in the app store, a simple alert prompt or card is displayed. The text is localised in many languages and supports customization, and the release notes are pulled from the store so the prompt can show what changed rather than a bare version number.

The audience is a Flutter developer shipping to a platform where the store will not do the nagging for them. The licence is MIT, with a LICENSE file at the repository root, and the last push to the repository was on 2026-10-03 with the repository not archived. The package is published on pub.dev as upgrader, with a codecov badge and a donation link in the README.

The platform table separates store checks from the appcast feed

The platform support table is the most useful thing in the README, and it has two columns that answer different questions.

The first column asks whether the platform is automatically supported, meaning the store handles the upgrade. Android and iOS are marked as yes. Fuchsia, Linux, macOS, web and Windows are marked as no.

The second column asks whether the appcast is supported, and every platform in the table is marked as yes. The appcast is the fallback source of version information, and the fact that it works everywhere is the point: on a desktop or web build there is no store page to scrape, so the appcast is how the package learns a new version exists.

That split explains the package's shape. On Android and iOS the version comes from the store. On the other platforms it comes from an appcast feed you host, which is the standard RSS-style mechanism for application updates outside the mobile stores.

Then there is the note that undercuts any assumption of a native integration. The package relies on scraping public Play Store pages for Android, and it does not use the native Android In-App Updates API or the Huawei AppGallery API.

That is a significant constraint, and it is the one to think about first. A native in-app update flow is a first-party API that Google designed for this exact purpose, whereas a scrape depends on the public page layout staying the same and on the app's listing being publicly visible. The package trades that for cross-platform coverage, which is a reasonable trade for an app that also ships on Linux and Windows, and a poor one for an Android-only product that could use the supported path.

Three buttons, and what each one commits you to

The widgets come in two flavours. UpgradeAlert is the popup alert prompt and UpgradeCard is the inline card widget, and the README says the card has a width and height of 0.0 when no update is detected, which is how it disappears from the layout without a conditional in your build method.

Both present the same three buttons, IGNORE, LATER and UPDATE NOW, and the difference between them is what state they leave behind.

Tapping IGNORE prevents the alert from being displayed again for that version. That is per version, not permanent, so a user who ignores version 1.2 will still be prompted about 1.3 later.

Tapping LATER just closes the alert, allowing it to be displayed sometime in the future, so nothing is recorded and the same prompt will reappear on the next check.

Tapping UPDATE NOW takes the user to the App Store on iOS or the Google Play Store on Android, where the user is expected to initiate the update process. The phrase expected to initiate matters: the button does not install anything, it opens the store listing and the user does the rest.

The behaviour is also customizable at the level of which buttons appear. The UpgradeAlert parameters listed in the README include showIgnore, showLater and showUpdate-style toggles alongside showPrompt and showReleaseNotes, so a product that wants a single dismissible prompt can hide the other two, and a product that does not want the release notes body can turn that off too.

Wiring the alert in takes one wrapper and one ordering rule

The integration is deliberately shallow. You wrap your home widget in the UpgradeAlert widget and it handles the rest, with one constraint the README states clearly: make sure UpgradeAlert is below MaterialApp in the widget tree.

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Upgrader Example',
      home: UpgradeAlert(
        child: Scaffold(
          appBar: AppBar(title: const Text('Upgrader Example')),
          body: const Center(child: Text('Checking...')),
        ),
      ),
    );
  }
}

The ordering rule exists because the alert presents itself as a dialog or a route, and a route pushed below MaterialApp has no navigator to push onto. It is a small constraint that will bite anyone who reaches for the wrapper before reading the note.

The card variant is even simpler, since you return it from your build method:

return Container(
        margin: EdgeInsets.fromLTRB(12.0, 0.0, 12.0, 0.0),
        child: UpgradeCard());

For a Cupertino look, the dialogStyle parameter takes UpgradeDialogStyle.cupertino, and the README notes that this style is used only by UpgradeAlert and works on Android and iOS. That is a narrow statement worth heeding, since the package is otherwise about platforms beyond the two phones.

Release notes come from the store, and the appcast is the other path

The release notes behaviour differs by source, and the README spells it out.

The release notes are displayed by default when a new version is available. On Android they are taken from the What's New section on Google Play when available, and otherwise the main app description is used. On iOS they come from the App Store What's New section. For the appcast path, the release notes are taken from the description field.

That fallback chain on Android is worth understanding, because a user seeing your entire app description under a heading like an update prompt is a common and slightly absurd outcome. It happens whenever the listing has no What's New section populated, which is easy to forget after a release.

Theming is where most of the customisation lives, and it goes through the standard Flutter theming rather than through a bespoke options object. For the alert, you change the DialogTheme on the MaterialApp or override methods in the UpgradeAlert class, with examples for both in the example directory. For the card, you change the CardTheme on the MaterialApp or override methods in the UpgradeCard class, again with examples.

So a product that wants the prompt to match a brand palette has two routes: override the theme the widget reads, or override the widget's own methods. The example project covers both, and the parameters list for UpgradeCard includes margin, maxLines with a default of 15, and overflow with a default of TextOverflow.ellipsis, which tells you the card is designed to be truncated in a bounded space rather than to expand a list.

Where upgrader is the wrong tool

The first wrong-tool case is an Android-only app. The package does not use the native Android In-App Updates API, so an app that could use Google's own supported mechanism is choosing to scrape a public Play Store page instead. That is a worse position for a production Android product: you depend on page layout, on the listing being publicly visible, and on your own package name resolving to the right listing.

The second is a desktop or web app where you already have a release channel. If your Linux build is delivered through a package manager with its own update mechanism, or your web build is a service worker that refreshes itself, the appcast plus prompt is solving a problem you have already solved.

The third is a product that cannot tolerate a network call on startup. The version check has to reach the network, and the README's example shows a body that says Checking, so the app is doing a lookup before it can tell the user anything. A package that must not delay first paint, or that runs in an environment with restricted networking, needs this to be opt-in and tolerant of failure rather than a default.

The fourth is a team that wants the store's own update UX. On Android, the in-app update flow is a system-provided dialog with a store-managed download, and users recognise it. A custom Flutter-drawn alert for the same job is more code to localise, more to theme, and less familiar.

The fifth is a project where the appcast is not under your control. The appcast is the only version source on the platforms without a store, which means someone has to publish and maintain an RSS-style feed of releases. If your release process does not already produce one, adding this package adds a publishing step.

The alternative worth naming is doing the check yourself, which for most Flutter apps means a version endpoint on your own API and a comparison against the installed version. That is a few lines, it gives you control over the comparison semantics, and it does not depend on a store's page layout. The upgrader package is worth it when you want the store's release notes, the localisation and the widgets for free, and when you are on a platform where that is the only mechanism available.

Editorial conclusion

upgrader fits a Flutter app shipping to a platform without automatic updates, or one that needs a version prompt faster than the store's own mechanism, and it gives you a themed alert or card with localised release notes in a few lines. It is the wrong choice for an Android app that can use the native In-App Updates API, and the wrong choice for any product that cannot tolerate the version check being driven by scraped store pages. Before adopting it, read the platform support table to confirm your target is covered, and check whether the appcast feed is a better source of truth than a store scrape for your release process.

Frequently asked questions

Official sources

1. Issues
2. larryaasen/upgrader on GitHub
3. License: MIT
4. README