[caption id="attachment_131017" align="aligncenter" width="1000"] Third-party libraries seem great to developers, but are they?[/caption] Libraries are part of every developer’s workflow, but writing your own can be tedious. Third-party libraries are a quick, easy workaround that can save you a ton of time, but are they worth it? There are arguments to be made for either side. Independent developers trying to make a living on the App Store might find it easier to get an app built and shipped by relying on third-party libraries. Those libraries are often open-source, and widely available via popular dependency managers such as CocoaPods or Node. A counter-argument: when something isn’t yours, it’s not yours. If the library changes and it affects your codebase, you'll need to do some custom refactoring on the fly. You’re no longer in control of your own app, having ceded a major component to someone else, and that’s treacherous. Ben Brooks of Martian Craft underscores that point. In a blog post, he advocates for eschewing third-party libraries at almost every turn, instead urging that developers take the time to create their own. Granted, Martian Craft has a team of developers (making it easier to write/manage libraries), but his words are applicable to any developer:

The decision to give away control is almost always financially motivated. Because the argument to select a third party code base is one of expedience — it is just faster to drop this in than to write it ourselves. I rarely, if ever, hear the argument that the code is better than what could be done in house (can’t imagine any engineer ever saying that either). Time is the crucial factor and whether it is time to ship, time of contractors, or time before the next funding round — time is a factor of expenses. This isn’t about reinventing the wheel, this is about whether or not you want your team to fundamentally understand every line of code, or whether you just want to drop in the things which work. There are times when we will always advocate for libraries we don’t own or write – especially so in specialized cases like encryption. No one needs that headache. But all too often we see people fighting against using third party libraries, which leads to unproductive arguments and ultimately letting non-engineering managers make financially motivated decisions.

Third-Party Libraries Aren't Bad, But Tread Lightly

As Brooks points out, some disciplines are just not in your wheelhouse. That’s why libraries and APIs exist in the first place. In those instances, a developer would likely be wasting their time trying to write their own libraries (and it’s not as if cryptography will go out of style). Still, there are best practices everyone can follow. Popular libraries with an active community tend to be more reliable. If changes are coming that might alter or break an app’s functionality, library managers tend to feel more responsible to communicate that fact to larger communities. Developers should also "read the room." If a really neat library with all the functionality you’ve been dreaming of just launched, but the developer or team responsible say it’s a "project" they opened up because they were too busy, it may be best to pump the brakes. A good library grows with community involvement and interest, but if the managers aren’t interested in supporting it, you may be back to square one on your next update. Why start all over with a new library six months down the road? Your best bet will always be to create your own services. The extra work will be worth it if you’ve got larger aspirations for whatever you’re creating. If that’s not possible, going with widely-used libraries that have dedicated, engaged communities is the best way to ensure system-breaking changes don’t sneak up on you. Those from larger companies such as Facebook are also less likely to be pulled if there’s no synergy around them, which is as safe a bet as you can get when you’re giving up some control.