In my last blog post, I want to share how we approached working with APIs in the Flutter ecosystem. No matter how passionate we are, it’s nearly impossible—now or in the future—to build a complete app without relying on external data or third-party functionalities. This is especially true for features like authentication, maps, augmented reality, and more.
That’s why it was frustrating to realize that almost everything required a compatibility layer. Anyone familiar with Flutter knows that sometimes, instead of struggling with an incomplete package, it’s easier to interact with an API as you would in a web app. But in my opinion, that approach contradicts Flutter’s core philosophy. If we had known this from the start, would we have just built a web app instead? It certainly feels like we did, considering the number of intricate—and at times even sketchy—HTTP-based workarounds we had to implement. For example, getting Google Places API’s autocomplete to work required a lot of effort, even though the native Android/iOS APIs offer much more out of the box.
API Restrictions: Not Exactly
The issue here doesn’t lie with the APIs themselves but rather with how independent developers implement them. Some don’t seem to prioritize quality—take ar_flutter_plugin_updated, for example, which we ended up using.
On pub.dev, each package has a Scores section that provides insights into its quality, and that’s where things start to fall apart.
A closer look at each category reveals some frustrating issues:
Only 92 out of 171 API elements are documented, meaning just 53.8% of the API is accounted for.
The documentation lacks any examples.
They score 20/20 for platform support, even though they have 0 support on iOS. That’s right—0/0, which means iOS support (or the lack of it) has no real impact on the score.
Static analysis flags unnecessary try/catch statements, which doesn’t seem like a difficult issue to fix.
The final check for compatibility with up-to-date dependencies doesn’t even account for crucial packages like state management libraries (e.g., Bloc). So what’s the point?
There’s no real incentive for independent developers to go the extra mile with their packages. A score of 130/160 already looks great at first glance, even if the package has significant flaws. If the scoring criteria were stricter, it would help ensure that, even when a package is abandoned, one of the following would happen:
The package is standalone and remains functional through future updates with minimal maintenance.
The package follows strict quality standards and is open-source, making it easier for another developer to take over—something quite common in the community.
Restrictive API's: The Real Bummer
This chapter needs to be put into contrast. On one hand, we have packages that are too new, forcing apps to target the latest Android versions without any backward compatibility. This contributes to the growing pile of outdated devices, effectively rendering them useless—unless you’re willing to dig deep and find a workaround yourself. While iOS and web ecosystems handle this issue slightly better due to more controlled update cycles and broader browser support, it still leaves a significant portion of users out in the cold.
Then, there’s the dependency chaos—the constant struggle of packages refusing to install because another dependency requires a different version. The worst part? The package manager would rather not install anything at all than attempt to resolve conflicts intelligently. This dependency in-fighting turns what should be a smooth development experience into a frustrating puzzle.
On the other end of the spectrum, some packages force you to downgrade your app significantly, whether by requiring outdated dependencies or locking you into legacy versions of essential frameworks. Needless to say, we refused to take that route. For a deeper dive into this issue, I’ll redirect you to the following article: Augmented Reality: A Sad Reality?
Conclusion
Working with APIs in Flutter has been both a necessity and a challenge. While they provide access to essential functionalities like authentication, maps, and augmented reality, the way they are implemented—particularly by independent developers—can make or break the development experience.
The reality is that no app stands alone, and relying on third-party packages is inevitable. However, the lack of quality control, dependency conflicts, and restrictive API requirements make it frustrating to maintain stability while keeping up with modern standards. Packages that are either too new, too outdated, or poorly documented only add to the problem, forcing developers to choose between breaking compatibility or creating workaround after workaround.
So what’s the takeaway? The Flutter ecosystem needs stricter guidelines for package quality and compatibility. Scoring systems should reflect real-world usability, and independent developers should be incentivized to maintain their packages properly. Until then, building a stable Flutter app will continue to feel like a constant balancing act between innovation and technical debt.
