CocoaPods announces Auth Server

http://blog.cocoapods.org/CocoaPods-Trunk

by orta • 12 years ago

32 24 12 years ago

blog.cocoapods.org

Massive congrats and thanks to all the CocoaPods team for this. Such an important project in the Cocoa community. New way of publishing pods looks much smoother.

orta• 12 years ago

It's a long post but the auth server (trunk) is important for the community, it has taken about a year to make and should make it super easy for library authors to update their own libraries without our intervention.

We're really glad to remove the human aspect, some of us can finally get some sleep again.

alloy8• 12 years ago

While on the topiZZzzzZzzzzzzzzz…………

AshFurrow• 12 years ago

This is a serious win for the iOS community. A huge step forward in terms of the maturity of the ecosystem. Congrats!

mikeash5• 12 years ago

While we're talking about it, can anyone explain why CocoaPods is so popular? I don't understand the appeal at all. Adding third-party libraries is something I don't do frequently at all, and it's not difficult to do manually. Automating the process doesn't seem to be even remotely worthwhile.

quesera3• 12 years ago

Just convenience, I think. Auto-updating rather than re-cloning and dragging files back into your project. This is fraught, of course.

CocoaPods also functions as a discovery engine. The experience is very unpolished, but it will surface the code that other people have written with the explicit intention of offering as a library to other people. Which is a subset of "code other people have released on github", obviously.

I'm a skeptic too. I've played with it, but requiring a couple dozen additional ruby gems and editing my Xcode project files underneath me creeps me out, so I won't use it for personal or client work.

I've been hired into existing projects that used it though, and it works fine as long as you manage it as a glorified drag-n-drop. You can blow yourself up if you trust it like a vendor-approved auto-upgrade mechanism. That's as much a factor of the ecosystem as the tool, and I hope Pods and Pod authors will coalesce around a level of maturity that's useful in shipping code environments.

al_gore• 12 years ago

Auto-updating rather than re-cloning and dragging files back into your project

That's the least usable way to do it, though. Use static library projects in submodules and a workspace/nested projects, and updated submodules will Just Work (unless there are breaking API changes, but Cocoapods can't help you there).

The main advantage of Cocoapods is shared dependencies. If you don't have those, it doesn't offer you much besides a non-git-native way to manage dependencies. Also, not having to manually edit your Xcode project to get the correct, single component path (instead of an absurd relative one) for a static library after changing to BUILT_PRODUCTS_DIR (why this has never been fixed, I have no idea).

alloy8• 12 years ago

editing my Xcode project files underneath me creeps me out

You can use the `--no-integrate` flag and it never touches your project, leaving integration of the Pods Xcode project up to you as you see fit.

alloy8• 12 years 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-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• 12 years ago

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

mikeash5• 12 years 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.

CocoaPods announces Auth Server

Related Stories