CocoaPods announces Auth Server
blog.cocoapods.org
CocoaPods announces Auth Server
1–10 of 26 posts
Re: CocoaPods announces Auth Server
#2Massive 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.
Re: CocoaPods announces Auth Server
#3It'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.
Re: CocoaPods announces Auth Server
#4It'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.
While on the topiZZzzzZzzzzzzzzz…………
Re: CocoaPods announces Auth Server
#5This is a serious win for the iOS community. A huge step forward in terms of the maturity of the ecosystem. Congrats!
Re: CocoaPods announces Auth Server
#6While 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.
Re: CocoaPods announces Auth Server
#7While 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.
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.
Re: CocoaPods announces Auth Server
#8While 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.
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", obviou…
> 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).
Re: CocoaPods announces Auth Server
#9While 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.
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.
Re: CocoaPods announces Auth Server
#10Earlier quoted context omitted.
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", obviou…
> 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 m…
Yes, CocoaPods can’t fix API breaking changes, but as we use semantic-versions and encourage authors to follow those, it can at least be mitigated more easily. E.g. A version requirement of: ‘~> 1’ should then install the latest v1.x.x, but not v2 which has API breakage.
Obviously this is not fool-proof and many are still getting used to it.