Q:

Strategy for customizing Cocoapods

Note: I can see this question has been asked once before here: Right way to extend or customize cocoapods
but I am unsatisfied with the answer. Some more specifics would be great in the case where rather than simply adding new methods, etc., you wish to fundamentally alter the nature of the pod, and don't really have the time to submit a patch to the original pod owner (nor would they necessarily want to pull your app-specific changes to their generalized project).
Right now I am working on a project that makes significant use of Cocoapods, but currently the project's Pods directory is more or less frozen due to customizations of multiple pods to suit the needs of the app.
Since the customizations were done directly in the pods classes, the Pods project needs to be frozen from new installs/updates because it doesn't seem to be possible to add or update single pods without doing them all at the same time. Doing this naturally results in errors when the customizations get wiped out by the update.
I know that a feature to update individual pods was introduced in a recent version of Cocoapods, but that new version seems to introduce new issues where "Analyzing dependencies" will often error out with incorrect circular dependencies between a single pod and itself. 
And as far as I know, there is no way to add a single pod without updating the others at the same time. 
So then, what are people's strategies for customizing pods without getting into this kind of situation? Do you subclass in your main project while leaving the pods directory untouched?
At the end of the day, are pods really that much better than git submodules?
Thanks for advice as to how to make use of them while still customizing freely and not wind up in this kind of situation. 
Right now my perspective is that pods which will be used without alteration can be imported to the Pods project as usual, but pods that are heavily customized should be added to the main project and separated from the pod add/update process completely.

A:

You should never make changes to any Pod directly.
What you should do, if you really must change the behavior of the dependency (i.e., you can't solve the problem with any other alternative such as composition or even categories), you should create a fork and then make the changes there.
Then, on your Podfile you should add the link to your fork:
pod 'MyLib', :git => 'https://github.com/someuser/MyLib.git'

Also, none of your Pods should ever make reference to your app code. A dependency should be self-contained.
All of these problems you're having is not CocoaPods' (or any other tool) fault. They're happening because you (and your team) misused it.

