Using Packages from pub.dev

Flutter's standard library is deliberately small. Almost every real app pulls in packages from pub.dev for HTTP, storage, state management and platform features. Choosing well matters — a dependency is code you did not write but must still maintain.

Adding a dependency

# Preferred: resolves the latest compatible version and edits pubspec for you
flutter pub add http
flutter pub add shared_preferences intl

# A dev-only dependency (tests, code generation, lints)
flutter pub add --dev build_runner

# Remove one
flutter pub remove http

dependencies:
  flutter:
    sdk: flutter
  http: ^1.2.0
  shared_preferences: ^2.3.2
  intl: ^0.19.0

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: ^5.0.0
  build_runner: ^2.4.13

dependencies ship inside your app. dev_dependencies are used only while developing — test helpers, linters, code generators — and are excluded from the release build.

Version constraints

The caret constraint relies on semantic versioning: the first number changes only on a breaking change. For packages below 1.0.0 the rules shift — ^0.19.0 means >=0.19.0 <0.20.0, because pre-1.0 the second number signals breakage.

Keeping dependencies current

# What is outdated, and what can move within current constraints
flutter pub outdated

# Upgrade within the constraints in pubspec.yaml
flutter pub upgrade

# Upgrade past them, rewriting pubspec to the newest majors
flutter pub upgrade --major-versions

# Fetch what the lockfile already specifies (what CI should run)
flutter pub get

Judging a package before you adopt it

Every pub.dev listing shows likes, pub points and download counts. Those are a starting signal, not an answer. Before depending on something, check:

• Last publish date. A package untouched for two years may not support the current Flutter SDK, and will not have been updated for recent platform requirements.
• Open issues and how they are answered. Many unanswered bug reports is a stronger warning than a low score.
• Platform support. The listing shows which platforms are supported. A plugin that is Android-only will block you the day you add iOS.
• Publisher. Packages under dart.dev, flutter.dev and tools.flutter.dev are maintained by the Flutter team. Verified publishers are a good sign.
• Size of the problem it solves. Do not add a dependency for something twenty lines of Dart would do. Every package is code that can break, conflict, or be abandoned.
• Licence. Check it is compatible with your project, especially for commercial work.

Packages vs plugins

A package is pure Dart — intl, collection, http. A plugin also contains native platform code — camera, shared_preferences, url_launcher. The practical differences matter:

• Plugins usually require a full restart, not a hot reload, when first added.
• Plugins may need platform configuration — permissions in AndroidManifest.xml, usage descriptions in Info.plist.
• Plugins can fail to work in plain Dart unit tests, because there is no platform to talk to. You mock the channel instead.
• Plugins may not support every platform, including web.

A reasonable starting set