Last weekend at CocoaConf DC, there was one refrain that really caught my attention: be wary third-party code. Avoid CocoaPods. Do things yourself. Speakers said it. Conference attendees said it. It seemed to be everywhere.

I don’t buy it.

Developers on other platforms thrive by making good use of third party, open source code. The Ruby community is a great example. You can find a gem for just about anything. Some are great, some are terrible, and a lot lie somewhere in between. But the existence of all these gems means you don’t have to re-invent the wheel for every new application. You can spend your time focusing on the things that are unique to your app.

Unfortunately, there seems to be a fairly deep cultural difference in the Objective-C community that rejects third-party code.

There are some key differences between writing a web app in Ruby and an iOS app in Objective-C that may account for the do-it-yourself sentiment. Most prominently, web developers have control over the system their app will run on. Servers can be configured with the exact OS and language versions that the app was designed and tested on. If developers keep the OS, language, and gem versions constant, the gems should continue to work correctly. (That said, web developers certainly use things like jQuery that rely on the browser, which changes under them all the time.)

On iOS (or the Mac), developers have much less control over the OS version that their apps run on. Sure, you can set a minimum requirement, but that doesn’t stop things from changing in the future. If Apple makes major changes in iOS 8, it could break third-party code. That lack of control over the complete environment does make third-party code a little more prone to headaches in Objective-C.

So should that dissuade iOS and Mac developers from using third party code? I don’t think so. Changes in the OS could just as easily break code that you wrote yourself, and when that happens, you’re on the hook to fix it yourself. Moreover, good third-party code shouldn’t break in catastrophic ways. Well-designed, well-maintained code should keep up with major OS releases. Apple gives ample time for beta testing before major updates, and rarely removes functionality without warning.

Just as on other platforms, the key to taking advantage of third-party code is to use it carefully and judiciously. Look first to widely-used, actively-maintained libraries. Plan how you use third-party libraries so you could replace them if necessary. Of course, don’t rely on them for everything. There’s always a time to do your own work. The power of sharing code is that you can spend more time on what makes your app unique, and less time reimplementing work others have already done.