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).
- 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).