(1) As a general rule I dislike any build system which requires a list of third party libraries to be maintained separate from the source base you’re building.

This violates the rule that you should be able to rebuild your source kit at any time so long as you have the compiler tools and the contents of your source repository, and get the exact same executable every time–as part of your source kit is stored elsewhere, in off-line databases stored across the Internet.

(2) Because your libraries are stored elsewhere, unless you are very careful with your configuration settings you cannot know if, in the future when you rebuild your project, you won’t get the exact same application. This makes final testing impossible because you cannot know the code you compile when you build for shipping your product is the exact same as the code you compiled when entering the final QA phase.

(3) Cocoapods in particular works by manipulating the settings file and project files of your project in invisible ways. I currently have a project where Cocoapods broke my ability to view inspectable views, and it required some fairly obscure setting hacking.

Unless a tool like Cocoapods is built into Xcode and is made an integral element of the Xcode ecosystem as it ships from Apple (as Gradle is a part of Android Studio), it is inevitable that future releases of Xcode will be broken by Cocoapods, and broken in ways which are nearly impossible for all but the most skilled hacker (or user of Google Search) to resolve.

(4) There is an entire mentality that has evolved around Cocoapods and Maven and other such library management tools that if you don’t have at least a dozen different libraries included in your project, you’re not engaged in software engineering.

I’ve seen projects which didn’t need a single third-party library, and once I handed them off to someone else (or worse, in one project, another developer started working on the code I was working on without management telling me he immediately gutted a bunch of my working code and replaced it with a handful of third party libraries that added nothing to the party.

Now it’s not to say there aren’t a lot of very good third party libraries. In the past I’ve used SLRevealViewController and iCarousel with great success. But in both cases I’ve simply downloaded the class which provides the implementation and included the sources directly into my application.

But I’ve also seen people include libraries which may have been useful during the iOS 4 era but which provide little value over the existing iOS 7/8 API. For example, there are plenty of network libraries which provide threaded networking access–nearly a necessity when the only APIs available to users to do HTTP requests was the event-driven version of NSURLConnect class, which required an intelligent implementation of NSURLConnectionDataDelegate, or rolling your own calls using Berkeley Sockets and POSIX Threads.

However, today we have Grand Central Dispatch and, when combined with the synchronous version of NSURLConnect, can make downloading a request from a remote server as simple as:

	dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
		NSURLRequest *req = [[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://www.google.com"]];
		NSData *data = [NSURLConnection sendSynchronousRequest:req returningResponse:nil error:nil];
		dispatch_async(dispatch_get_main_queue(), ^{
			[self processResult:data];
		});
	});

Do we need CocoaAsyncSocket anymore? FXBlurView given that the current iOS tools do not build before iOS 7? Do we need the other various iOS networking solutions given that it now takes 6 lines of code to perform an asynchronous network connection?

And really, do we need SLRevealViewController? The problem with the UI design that SLRevealViewController allows you to implement makes the problem of “discoverability” hard for users: by hiding a screen in a non-obvious place, it makes it hard for users to know what he can do with his app–which is why Facebook’s mobile app, which first promoted the side bar model that SLRevealUserController implements, has moved away from that design in favor of a standard UITabBarController. (Yes, they’ve kept the same UI element with the list of users on-line hidden on a right-side reveal bar–but frankly that could have also been handled by a simple navigation controller push.)

By the way, Maven is worse, as is the entire Java ecosystem: I’ve seen projects that rely on no less than 50 or so third party libraries–which creates an inherently fragile application in that all of those libraries must be compatible with the other libraries in the collection. And all it takes are two of those 50 or so which require completely different and incompatible versions of a third party library–which I’ve seen, when two libraries suddenly required completely different versions of the same JSON parser library.

(Ironically, the incompatible third party library which triggered this issue was a replacement of Java’s built in logging facility. So we had a completely broken and somewhat unstable build simply because some developer working on the project wanted a few more bells and whistles with an internal logging tool that was not actually used in production.)

Most programmers out there that I’ve encountered today are “plumbers”; rather than build an application with the features requested they immediately go searching for libraries that implement the features they want and glue them together.

While there is something to be said about that when it comes to doing something that is either tricky (such as what SLRevealViewController does), or which requires integration to a back-end system that you don’t control (such as Google Analytics), it has been my experience that programmers who reduce the problem of programming to finding and snapping together pre-fabricated blocks they barely understand using tools they hardly understand and the most cursory understanding of how components work does not result in the best quality applications.