After about a year of work, with the release of CocoaPods 1.0, the corresponding Mac App is also ready for public usage.
This is no big reveal, we've been advertising it's existence on our websites for a while. I've already talked a little bit about the tech behind the Mac App, so this post is the one that makes you say your team "we should use this instead of the gem".
So let me put my best hat on, and try to pursuade you that using the CocoaPods Mac App is a great idea.
What problem does this solve?
CocoaPods exists within the ruby ecosystem. The majority of Cocoa developers don't have much overlap with writing ruby programs. Installing and maintaining multiple versions of command-line tools like CocoaPods is something that people have to learn in order to use CocoaPods effectively.
This creates a problem which Bundler solves really well, but now you're starting to really dive into the ruby ecosystem and the pre-requisite knowledge to contribute raises again. While I'm on my soap-box, if you're using the CocoaPods and Fastlane gems in an app, you probably should be using Bundler.
So the CocoaPods app hosts everything. Literally, it has it's own self-contained copies of
zlib. This allows the CocoaPods team to ensure consistent behavior across all user setups.
This concept is not new for Cocoa developers, as Xcode has been embedding its own dependencies inside it's
.app since it moved to the Mac App Store. The advantage from a user's perspective is that it works, and you can install your own crazy version of
ruby, and it just works.
What does it do well?
Glad you asked, 'cause it does two things really well:
- Editing a Podfile
That was basically the spec for the app from day 1. Once @alloy had proved that
pod install/update was working, @nate_west and I took over and started working on the latter.
Some of these features are mundane, "hey, wow, syntax highlighting</sarcasm>" but others are really fascinating deep levels of context-specific integration that you'd expect from an IDE.
We've started out with syntax highlighting, and then added useful examples of auto-completion results that show how to use the Podfile DSL.
The app will auto-complete your pods, including private pods. This feels magical when you don't expect it. We've been having discussions about ways to introduce more of the internal CocoaPods knowledge into the auto-complete like this - you're welcome to help out.
The app will generate an overview of what your integration will look like without needing to be installed, so you can understand what CocoaPods will do before it has done it.
The app provides a UI for updating your Specs repos, you can find out a little bit more about why this is needed in our Master spec-repo rate limiting post‑mortem.
It also has the ability to start a new CocoaPods project, or to even remove CocoaPods from a project entirely. I don't want to give away all of the app's secrets though, so you should give it a test run.
It wouldn't be an announcement without a thanks to people involved, it's a fascinating project to work on due to the interesting layers of tech involved, but one of the coolest things about building this app, is that it provides a project for people who are Cocoa developers to contribute back without learning a new language. So we've been recieving a lot of PRs to the app, and it is always a joy to work with more.
I want to specifically call out Nate West, who has been working with me on the app through-out 2016. His contributions to this project have been significant, and through this he's contributed to more of our core projects.