Choosing Packages You Can Trust: pub.dev and the Flutter Favorite Program

A Flutter app is mostly a dependency graph. Networking, storage, state, Firebase, animations — almost none of it you will write yourself, and every line you do not write is a line someone else can abandon. Package selection is therefore one of the highest-leverage decisions in a project, and one of the easiest to get wrong: the top search result on pub.dev is not necessarily the package you should ship.

pub.dev gives you three numbers, a scoring model, and a curated badge. They measure different things, they can disagree, and none of them replaces reading the changelog. This post explains what each signal means, what the Flutter Favorite designation does and does not promise, and how to run a repeatable vetting pass before a package enters your pubspec.yaml.

Key technologies: pub.dev scoring (likes, pub points, downloads), the pana analyzer, the Flutter Favorite program, the Flutter Ecosystem Committee, verified publishers, federated plugins, pubspec.lock, flutter pub outdated.

The Numbers on Every Package Page

Every package page shows three scoring dimensions, and pub.dev is explicit that they are not interchangeable:

Signal	What it measures	What it does not measure
Likes	Raw peer sentiment — how many developers pressed the thumbs-up button.	Correctness, maintenance, or how widely it is installed.
Pub points	Quality as judged by automated analysis: conventions, docs, platform support, static analysis, up-to-date dependencies.	Whether the API suits your use case, or whether anyone uses it.
Download count	How often the package archive was fetched from the server.	Distinct users.

The download caveat matters more than people expect. pub.dev caches downloads in PUB_CACHE, so a version is fetched once per developer machine no matter how many projects run pub get — while CI, which rarely keeps the cache, inflates counts. A package pulled in transitively by a popular library can rack up huge numbers with almost no direct users. pub.dev’s own guidance: the download count “should only be regarded as an indicator of popularity.”

Scale check: pub.dev lists 79,518 packages, 65,710 of them Flutter-compatible. No single number will choose for you.

How Pub Points Are Calculated

Pub points are pub.dev’s quality measure, computed automatically by the pana analyzer whenever you publish. The current report awards up to 160 points across these categories:

Category	Points	What earns them
Follow Dart file conventions	30	Valid pubspec.yaml with https: URLs (10), valid README.md (5), valid CHANGELOG.md (5), OSI-approved LICENSE (10).
Provide documentation	20	An illustrative example/ (10), plus at least 20% of public API members carrying dartdoc comments (10).
Platform support	20	Platforms detected from the transitive import graph of top-level libraries, or declared in pubspec.yaml.
Pass static analysis	50	No errors, warnings, lints, or formatting issues under dart analyze / flutter analyze against the standard lints package.
Support up-to-date dependencies	40	Works with the latest stable Dart SDK (10), latest stable Flutter SDK where applicable (10), latest dependency versions (10), and passes pub downgrade at constraint lower bounds (20).

Two modern-toolchain rules are baked into the platform score: a Flutter plugin supporting iOS or macOS only gets full marks if it supports Swift Package Manager, and a package declaring web support earns more if it is WebAssembly-ready.

You can run the same analysis locally before publishing or before adopting a fork:

$ dart pub global activate pana
$ dart pub global run pana ~/tmp/mypkg

pana modifies the directory it analyzes, so run it against a copy. For your own app, flutter pub outdated is the equivalent check on how far your constraints sit behind the head.

What the Flutter Favorite Badge Means

The Flutter Favorite program exists to identify “packages and plugins that you should first consider when building your app.” Read that sentence carefully: first consider, not use.

The docs state the limit directly: “This is not a guarantee of quality or suitability to your particular situation — you should always perform your own evaluation of packages and plugins for your project.” The badge is a shortlist entry point, not a certification, and says nothing about whether the API, licensing model, or release cadence fits your team.

The evaluation metrics

Packages are assessed against published metrics:

• Overall package score on pub.dev.
• Permissive license — including Apache, Artistic, BSD, CC BY, MIT, MS-PL, and W3C.
• GitHub version tag matches the pub.dev version, so you can inspect exactly what source shipped.
• Feature completeness — not labelled “beta” or “under construction.”
• Verified publisher.
• General usability of the overview, docs, sample/example code, and API quality.
• Good runtime behavior in terms of CPU and memory usage.
• High quality dependencies.

The program also documents metrics under consideration: clear platform declarations in pubspec.yaml, support for the latest stable Flutter, AndroidX support, multi-platform support, and integration plus unit test coverage. Today’s badge requires none of them, which is a reminder that the bar moves.

Who decides

The Flutter Ecosystem Committee — Flutter team and community members — decides when a package has met the quality bar. Current members, ordered alphabetically by last name: Abdallah Shaban, Pooja Bhaumik, Hillel Coren, Majid Hajian, Simon Lightfoot, John Ryan, and Diego Velasquez. Anyone can nominate a package by emailing the committee.

Status is not permanent: an author who loses the designation must immediately remove all uses of “Flutter Favorite” and its logo. The complete list lives at pub.dev/flutter/favorites, also exposed as an is:flutter-favorite search filter.

Three Favorites, Read Critically

These are Flutter Favorites with real pub.dev numbers — note how differently they behave:

Package	Version	Likes	Pub points	Downloads	Publisher	License
flutter_bloc	9.1.1	8.08k	160 / 160	2.08M	bloclibrary.dev (verified)	MIT
cloud_firestore	6.10.0	3.78k	150 / 160	1.29M	firebase.google.com (verified)	BSD-3-Clause
built_value	8.13.0	783	150 / 160	14.9M	google.dev (verified)	BSD-3-Clause

What the table teaches:

• built_value has 14.9M downloads and 783 likes. It is a pure Dart library pulled in transitively by enormous numbers of packages: popularity and affection are different axes.
• cloud_firestore scores 150/160, losing points to two Angle brackets will be interpreted as HTML lints — even a Flutter Favorite can ship with deductions. The report was generated 46 hours earlier with Pana 0.23.19 against Flutter 3.47.5.
• cloud_firestore supports 5 of 6 platforms (no Linux) and is federated: cloud_firestore_platform_interface and cloud_firestore_web ship separately, and pub.dev lists “Packages that implement cloud_firestore” so you can swap implementations.
• flutter_bloc scores 160/160 with an example and external docs at bloclibrary.dev — but it is still a state-management opinion you must agree with.

A Practical Vetting Checklist

Run this before adding any dependency, favorite or not:

1. Maintenance cadence. Open the changelog: when was the last version, and is the cadence regular? Check the issue tracker for unanswered bugs. “Published 17 months ago” with 160 pub points reads as stable; the same gap on a fast-moving platform integration is a warning.
2. Pub points and the failed checks. Use the score page, not the badge. A yellow static-analysis section tells you what the maintainer has not cleaned up.
3. Verified publisher and repository link. A verified domain (firebase.google.com, google.dev, bloclibrary.dev) plus a repository matching the published source reduces the risk of a typosquat or abandoned fork.
4. Version tag and license. Confirm the GitHub tag matches the pub.dev version, and that the license is one of the permissive set the Favorite metrics require.
5. Platform support for your targets. The score page marks each platform with a check or a cross; filter search by platform:windows, platform:web, and so on before falling for an Android-only plugin.
6. Null safety and SDK constraints. Read the environment SDK constraint and the Dart versions section. If the floor predates sound null safety in Dart 2.12, the “supports latest stable Dart and Flutter SDKs” check will already have penalized it.
7. Federated structure. Look for a *_platform_interface package and the “Packages that implement X” sidebar. Federation separates the app-facing API from platform implementations, which is what makes desktop or web support replaceable without a rewrite.
8. Test coverage. The Favorite metrics list integration and unit coverage as a future metric, so the badge does not prove it. Check for a CI badge, a coverage report, and an example/ app that runs.
9. Transitive blast radius. flutter_bloc pulls bloc and provider; built_value pulls built_collection, collection, fixnum, and meta. Fewer, well-maintained dependencies beat a deep tree.
10. Upgrade headroom. Run flutter pub outdated after adding it. If its constraints already block the latest version of a shared dependency, you will be fighting dependency_overrides sooner or later.

Best Practices

• Pin ranges, not exact versions. Use caret constraints (flutter_bloc: ^9.1.1) and commit pubspec.lock so every machine resolves the same graph.
• Prefer flutter pub add over hand-editing pubspec.yaml; it writes a valid constraint and runs the resolver.
• Override only as a temporary bridge. dependency_overrides forces a version for the whole app and hides real conflicts; the same goes for Gradle resolutionStrategy.
• Start with the Flutter landing page and the Favorites list when you have no prior opinion — that is what the program is for — then finish the evaluation yourself.

Common Pitfalls

1. Treating the Favorite badge as a guarantee. The docs say it is not one; suitability remains your evaluation.
2. Ranking by downloads. CI re-runs and transitive use distort counts; treat them as a popularity hint only.
3. Expecting 160 pub points. Flutter Favorites routinely ship at 150/160; the report is a to-do list, not a verdict.
4. Checking platforms only on the search page. Confirm on the score page, where detected platforms come from the import graph unless declared in pubspec.yaml.
5. Assuming the badge covers coverage. Test coverage is listed among metrics the program may add, not ones it enforces today.
6. Hand-editing pubspec.yaml and skipping flutter pub get. Without a resolver run there is no lockfile, and teammates resolve different versions.

Wrapping Up

pub.dev hands you three honest-but-narrow signals: likes for sentiment, pub points for automated quality, downloads for popularity. The Flutter Favorite badge adds human review by the Flutter Ecosystem Committee against published metrics — permissive license, matching version tag, completeness, verified publisher, usable docs, sane runtime behavior, good dependencies — while explicitly declining to guarantee quality or suitability. Use the badge as a shortlist, run the ten-point checklist as your own gate, and let pubspec.lock keep the decision stable once it is made.

Sources

• Flutter Favorite program
• pub.dev
• Using packages
• Flutter landing page on pub.dev
• Package scores and pub points
• Flutter Favorites list