How I choose Flutter packages: best practices explained

How I choose Flutter packages

I've made costly mistakes by rushing into dependencies without proper evaluation. After 5+ years shipping production apps, I've learned that every package you add is a long-term commitment—one that can either accelerate your timeline or become a maintenance burden. In this article, I'll walk you through my exact decision-making framework for vetting Flutter packages before they touch my codebase.

Check maintenance and recent releases

The first thing I do when evaluating a package is check when it was last updated. On pub.dev, I look at the "Releases" tab and the timestamps. If the last release was more than a year ago, I'm already skeptical. If it's been three years, I treat it as abandoned unless it's so stable it genuinely needs no updates.

I also check whether the maintainer has updated the package recently to support new Dart or Flutter versions. When Flutter jumps to a major release, packages need patches for null safety, lint compatibility, or new platform features. A package that hasn't seen an update in six months when Flutter shipped a major version is a red flag.

Recently, I evaluated http versus dio for a trading platform's API client. Both are solid, but dio gets more frequent updates and the maintainer actively responds to issues. That consistency matters when your app goes to production.

I also look at the changelog. A good changelog tells me what bugs were fixed, what features were added, and whether the author takes breaking changes seriously. If someone ships five point releases in a month with vague descriptions like "various fixes," that suggests either chaos or they're iterating faster than their users can follow.

Look at pub points and popularity

Pub.dev shows a score called "pub points" (out of 130). This metric rewards packages that follow best practices: good documentation, unit tests, example apps, and platform support declarations. I aim for packages scoring at least 110 points, and I scrutinize anything below 90.

That said, pub points aren't everything. A niche package with 95 points that solves a specific problem perfectly is better than a general-purpose package with 120 points that requires extensive configuration. I use pub points as a starting filter, not the final verdict.

Popularity measured by likes and pub points matters, but I don't chase trends. A package with 5,000 likes from major companies is probably worth considering. A package with 200 likes from unknown sources might still be solid if it does one thing well. I look for signal, not just noise.

Pub Points	Likelihood I'll use it	Additional checks needed
120+	Very high	Verify it solves your problem
110-119	High	Check maintenance, read issues
100-109	Medium	Read issues, test in a branch
90-99	Low	Strong justification needed
<90	Very low	Consider alternatives or build it yourself

When I was building a ride-hailing app, I found a package with solid pub points and 1,000+ likes for map clustering. But when I dug deeper, the last update was 18 months old and it didn't support the latest Google Maps plugin. I skipped it and built a lightweight clustering layer myself in a weekend. The time investment paid off because I owned the code.

Read open issues

This is where I separate wheat from chaff. I sort the package's GitHub issues by most recently updated and spend 15 minutes reading. I'm looking for patterns: Are bugs reported and then ignored? Does the maintainer engage with the community? Are there unresolved critical issues?

I pay special attention to issues that match my use case. If I'm considering a package for database queries and there are three open issues about transaction handling, that's a signal I might hit the same problems.

Here's what a healthy issue section looks like:

• Bugs get acknowledged within a week
• Feature requests are discussed, not ignored
• The maintainer or team engages respectfully
• Closed issues outnumber open ones significantly
• No issue has been open for years without response

When evaluating a Redis package for a SaaS backend, I found 47 open issues but also saw that 312 were closed. The maintainer was actively triaging new reports. I also noticed the oldest unresolved issue was 8 months old, and in the comments, the maintainer explained it was a edge case that rarely occurred. That transparency gave me confidence.

Conversely, I once looked at a state management package with 120 open issues, only 80 closed, and comments from frustrated users saying "is this project dead?" That was an obvious skip.

Prefer packages from verified publishers

Pub.dev has a "verified publisher" badge. This means the publisher has proven their identity to the Dart team and maintains multiple packages professionally. It's not a guarantee of quality, but it's a meaningful signal that someone credible is behind the code.

Packages from verified publishers like Gskinner, VGV, and Google tend to follow higher standards. They're more likely to respond to issues and maintain backward compatibility. That doesn't mean I only use verified publishers—I've used excellent solo-maintained packages—but I do treat them as lower risk.

For a CRM platform I worked on, I needed a form validation library. I found two options: one from an unverified solo developer with no recent updates, and one from a verified publisher with quarterly releases and strong documentation. I chose the verified one. Six months later, when Flutter shipped a breaking change, the verified publisher pushed a patch within two weeks. The solo package never got updated.

I also check the publisher's other packages. Do they maintain five well-regarded packages or fifty abandoned ones? A publisher with four solid, maintained packages is more trustworthy than one with a portfolio full of dead projects.

Common mistakes

Mistake 1: Choosing a package because it's trendy. I once added a state management package because everyone was talking about it. After two weeks, I realized it wasn't a good fit for my architecture, and ripping it out cost me a day of refactoring. Now I evaluate fit first, popularity second.

Mistake 2: Ignoring dependency trees. A package might look clean, but if it depends on five other packages that each depend on three more, you're pulling in a lot of transitive dependencies. Each dependency is another point of failure. I run pub deps and review the tree before committing.

Mistake 3: Not testing in a real scenario. Reading the documentation isn't the same as integrating the package into your actual app. I always create a small branch, add the package, and build a minimal example matching my real use case. This catches incompatibilities or performance issues before they're deep in the codebase.

Mistake 4: Assuming one size fits all. A package with an A+ score might not fit your needs. I've rejected high-scoring packages because they imposed architectural patterns I didn't want. Choose fit over score.

My evaluation checklist

Before I add a package to pubspec.yaml, I use this checklist:

1. Last release was within the last 6 months (or it's truly stable and doesn't need updates)
2. Pub points score is 110 or higher (with exceptions if the package solves a niche problem exceptionally well)
3. No unresolved critical issues related to my use case
4. Maintainer responds to issues within reasonable time frames
5. Publisher is verified (preferred, not required)
6. Documentation is clear and includes examples
7. Dependency tree is reasonable (no bloated transitive deps)
8. I've tested it in a branch with a realistic scenario

If a package fails more than two of these checks, I either look for alternatives or consider building it myself.

Key takeaways

• Every dependency is a long-term commitment. Vet thoroughly before adding it.
• Check maintenance status first: recent releases and Dart/Flutter version support matter most.
• Pub points are a useful filter, but scores below 110 warrant extra scrutiny.
• Read open issues to understand how the maintainer engages with the community.
• Verified publishers are lower risk, but solo-maintained packages can be excellent.
• Test packages in a branch before committing them to your main codebase.
• Fit your architecture is more important than popularity or trends.
• Sometimes building a small solution yourself costs less than debugging a misaligned package.