In this particular case, the problem is that the plugins require Dart glue code, and a native implementation on both iOS and Android. So if you run into a problem with a component, it's much more complicated to fix it.

In general, using third party components with native mobile apps is pretty straightforward.

Even for full native, I try to keep the number of third party dependencies down and limit them to libraries that fill legitimate voids in system functionality or are only light sugar around system stuff for a few reasons:

- Many libraries have zero guarantees as to how long they’ll be maintained or if their maintainer(s) will keep pace with new system releases, build tool changes, etc

- It’s less unfamiliar code that I’ll need to wade through at some point

- Fewer libraries reduces lock-in that can encumber refactors and other major changes

- I don’t have to waste as much time and energy “translating” things between different libraries with related functions

I used to not be as avoidant of a long dependency list, but over the years I learned that for both iOS and Android, each library represents a liability across multiple dimensions that WILL become a problem at some point, probably sooner than later. Mobile platforms aren’t like their desktop/server counterparts where the various APIs have barely changed in decades, and they aren’t like the web where everything continues to be supported for practically forever. Things change, and it’s important to be able to keep up with that.

This is a lot easier to manage under iOS than under Android, incidentally. Cocoa Touch still sees tweaks but it’s quite mature, and very deep and capable. You can build a world class app with just Cocoa Touch alone without too much trouble. With Android Framework on the other hand, much of what’s built in is incapable, with bits and pieces constantly shifting in and out of being supported, making it the norm to bring in a laundry list of libraries for super basic stuff (e.g. everybody uses Square’s OkHTTP for networking on Android while on iOS, not using the built in URLSession and associated APIs is very strange).

I think this is just a propagation of the issues larger organizations may generally have with dependencies. You don’t want your applications be dependent on the update cycle of other organizations/individuals. What if the bug fix does not get merged into the master fast enough? Do you fork? When do you recombine again?

But otherwise I agree, sharing code and making it better for everyone as well as delegating complicated parts of the application to others are well practices.