5 ms·

You assume that any code installed through CocoaPods will be created by ‘third-parties’, this is incorrect. Dependencies are simply that. You can use your own,

by alloy 12y ago

You assume that any code installed through CocoaPods will be created by ‘third-parties’, this is incorrect. Dependencies are simply that. You can use your own, like many companies have been doing successfully internally. E.g. http://dev.hubspot.com/blog/architecting-a-large-ios-app-with-cocoapods http://dev.hubspot.com/blog/architecting-a-large-ios-app-wit... Regarding “it’s not difficult” to do; Indeed it’s not, but it can be time consuming when you do want to quickly try out some libs. Especially once you have committed them to SCM and later on decide to remove them, because they weren’t what you wanted after all. This becomes even more a factor if you want to see a community that builds stuff together, instead of everybody re-inventing the wheel and/or vendoring their dependencies inside their lib leading to the mess that brings (at linker and runtime level), because then you need actual transitive dependencies and calculate a graph. It is my experience that the lack of a tool and an ecosystem, such as CocoaPods, has led to the Objective-C OSS community staying minimal, in terms of working together. This can be noticed by the instant feedback people get on their projects when they release a library through CocoaPods and the decline of monolithic frameworks. Whether or not your situation asks for this is another question. In consulting you’ll notice the benefit of quickly adding your dependencies, while on your own (single) product that’s probably a negligible amount of time. YMMV and all are fine.

kylef 12y ago
http://supermar.in/modular-objective-c/ http://supermar.in/modular-objective-c/ is a great article too.
mikeash 12y ago
It shouldn't be time consuming to manually integrate a dependency either. Add it to your project and go. I further don't understand how it's a problem if you commit them to SCM and then decide to remove them. If you decide to remove them, then remove them, and you're back where you were. Perhaps this is the gulf in understanding: when you talk about transitive dependencies, my immediate reaction is that if you have so many different dependencies and dependencies-on-dependencies that it becomes difficult to manage by hand, you're doing something terribly wrong and setting yourself up for a world of pain.
- alloy 12y ago
  > It shouldn't be time consuming to manually integrate a dependency either. Add it to your project and go. I’m not going to play the yes-no game with you on this. > I further don't understand how it's a problem if you commit them to SCM and then decide to remove them. If you decide to remove them, then remove them, and you're back where you were. You will have to spend time to figure out which build-settings originate from which library. Or you do it properly upfront with a xcconfig, which also costs you time. > Perhaps this is the gulf in understanding: when you talk about transitive dependencies, my immediate reaction is that if you have so many different dependencies and dependencies-on-dependencies that it becomes difficult to manage by hand, you're doing something terribly wrong and setting yourself up for a world of pain. You’re simply making too many assumptions then. Also see: http://guides.cocoapods.org/using/faq.html#cocoapods-is-bad-for-the-community-because-it-makes-it-too-easy-for-users-to-add-many-dependencies http://guides.cocoapods.org/using/faq.html#cocoapods-is-bad-... I’m still planning to port that old blog post, by my then-colleague, to an iOS context and post it on our blog. This assumption you make is a common one and tends to leave sour tastes with everyone.
  - mikeash 12y ago
    I don't understand your "build settings" comment. Why would there be any build settings originated from a library? As for "making too many assumptions", it sure would be nice if you could, say, explain yourself instead of just saying I'm wrong and that my wrongness upsets people. Your FAQ link doesn't explain anything. To explain my side: third-party code tends to be of low quality and interact with other third-party code in interesting ways. When things go wrong, and they always do even with the best programmers and the best code, the more bad third-party code you have, the more you have to dig through to find and fix the fault. This objection largely goes away if you only use dependencies of extremely high quality, but to be brutally honest, there aren't enough such projects out there to be able to make a mess from them.
    - quesera 12y ago
      > third-party code tends to be of low quality and interact with other third-party code in interesting ways. Absolutely. There are less than a half dozen libraries I'll use without hesitation. The others get evaluated carefully on author, size, criticality, and my domain knowledge, with the default choice being: "no, don't want to deal". But that's a criticism of all package managers everywhere, and I think it's clear that popular ones promote higher quality libraries, over time. CocoaPods is young yet. Package management for compiled and linked executables might turn out to be too hard or wrongly marketed. But a strong ecosystem of third party Objective-C code is a laudable goal.

by alloy 12y ago

kylef 12y ago

http://supermar.in/modular-objective-c/ http://supermar.in/modular-objective-c/ is a great article too.

mikeash 12y ago

It shouldn't be time consuming to manually integrate a dependency either. Add it to your project and go. I further don't understand how it's a problem if you commit them to SCM and then decide to remove them. If you decide to remove them, then remove them, and you're back where you were. Perhaps this is the gulf in understanding: when you talk about transitive dependencies, my immediate reaction is that if you have so many different dependencies and dependencies-on-dependencies that it becomes difficult to manage by hand, you're doing something terribly wrong and setting yourself up for a world of pain.

alloy 12y ago
> It shouldn't be time consuming to manually integrate a dependency either. Add it to your project and go. I’m not going to play the yes-no game with you on this. > I further don't understand how it's a problem if you commit them to SCM and then decide to remove them. If you decide to remove them, then remove them, and you're back where you were. You will have to spend time to figure out which build-settings originate from which library. Or you do it properly upfront with a xcconfig, which also costs you time. > Perhaps this is the gulf in understanding: when you talk about transitive dependencies, my immediate reaction is that if you have so many different dependencies and dependencies-on-dependencies that it becomes difficult to manage by hand, you're doing something terribly wrong and setting yourself up for a world of pain. You’re simply making too many assumptions then. Also see: http://guides.cocoapods.org/using/faq.html#cocoapods-is-bad-for-the-community-because-it-makes-it-too-easy-for-users-to-add-many-dependencies http://guides.cocoapods.org/using/faq.html#cocoapods-is-bad-... I’m still planning to port that old blog post, by my then-colleague, to an iOS context and post it on our blog. This assumption you make is a common one and tends to leave sour tastes with everyone.
- mikeash 12y ago
  I don't understand your "build settings" comment. Why would there be any build settings originated from a library? As for "making too many assumptions", it sure would be nice if you could, say, explain yourself instead of just saying I'm wrong and that my wrongness upsets people. Your FAQ link doesn't explain anything. To explain my side: third-party code tends to be of low quality and interact with other third-party code in interesting ways. When things go wrong, and they always do even with the best programmers and the best code, the more bad third-party code you have, the more you have to dig through to find and fix the fault. This objection largely goes away if you only use dependencies of extremely high quality, but to be brutally honest, there aren't enough such projects out there to be able to make a mess from them.
  - quesera 12y ago
    > third-party code tends to be of low quality and interact with other third-party code in interesting ways. Absolutely. There are less than a half dozen libraries I'll use without hesitation. The others get evaluated carefully on author, size, criticality, and my domain knowledge, with the default choice being: "no, don't want to deal". But that's a criticism of all package managers everywhere, and I think it's clear that popular ones promote higher quality libraries, over time. CocoaPods is young yet. Package management for compiled and linked executables might turn out to be too hard or wrongly marketed. But a strong ecosystem of third party Objective-C code is a laudable goal.