url_launcher: platform intent with a fallback contract

url_launcher is useful because it focuses on canLaunchUrl, launch modes, web URLs, and unavailable handlers. The important engineering move is to place the package behind a clear boundary, so your Flutter UI depends on a stable capability rather than a vendor-shaped API.

What the library should own

• Keep package calls inside a named adapter or feature boundary.
• Make lifecycle, errors, and loading state part of a testable contract.
• Expose only the capability the app needs; hide implementation details from the whole tree.

A focused starting point

final uri = Uri.parse('mailto:support@example.com');
if (await canLaunchUrl(uri)) {
  await launchUrl(uri, mode: LaunchMode.externalApplication);
} else {
  showUnsupportedAction();
}

Production checklist

1. Read the README and changelog for the exact version you pin.
2. Add one test for lifecycle, failure, and app background/foreground behavior.
3. Verify every platform your product supports, not only the developer machine.
4. Record ownership, upgrade cadence, and rollback notes in the repository.

Common pitfall

A canLaunch check is advisory; still handle launch failure and configure platform query declarations.

Takeaway

A good open-source library does not replace architecture. It makes one difficult boundary clearer, observable, and easier to replace.