How I use CocoaPods
You may not like how I use CocoaPods
Having heard the woeful story of a student who spent six hours on a client project not understanding what libPods.a was and why it was causing a link error I have begun nesting my `.xcodeproj` inside my `.xcworkspace` so it is much less likely anyone new to CocoaPods is going to open the wrong xcsomething and waste time.
Sadly, it’s not really that easy to do.
- `git commit -amwip`
- Create your new project, or have an existing project around. Close Xcode.
- `mkdir MyProjectName.xcworkspace` or skip this step if you already have it.
- `mv MyProjectName.xcodeproj MyProjectName.xcworkspace`
- Edit your Podfile and add the line `xcodeproj MyProjectName.xcworkspace/MyProjectName.xcodeproj`
- I suggest deleting `Podfile.lock` and `Pods`
- `pod install`
- `git commit -amwip`
- Now open the `xcworkspace`, all your files will be red, that’s because you moved the `xcodeproj` but not the files.
This step is laborious, select all the files that are in the same directories and then open the right-hand pane. Below is a screenshot showing what you have to click. Choose the folder that contains those files, unless you only selected a single file, in which case select that file’s location. I suggest choosing the combo option “relative to project” as the relativeness option, though I don’t know if it matters much. - Test everything still works.
Other Stuff I Do
I Commit my Pods
I commit my `Pods/` and my `Podfile.lock`. I didn’t use to, and I even mocked the idea of it a few times:
I changed my mind because I have worked with people who refuse to install the `pod` gem, or who can’t because they broke their Ruby installs. I changed my mind because switching branches may mean that my `Pods` were all wrong and I’d have to `pod update` whenever I changed branch. I changed my mind because unless you at least commit `Podfile.lock` when you go back in history with git bisect you don’t actually have an accurate snapshot of your app from that point in time.
I still don’t like it. It feels gross and inefficient. But it’s the right thing to do, so I now do it.
I Turn Every Self Contained Library I Make into a Pod
Since CocoaPods switched to `trunk` it is super easy to make Pods. When I write code I look at it and if I made it encapsulated and modular, and it seems useful, I make it into a Pod.
I Only Have One Header in my Project
I got so bored with having a million headers. So now I only have `main.h`. All my `@interface`s go in there. And nowadays that’s pretty much all they are since all my ivars go in the @implementation and I use Promises to manage asynchronous state across ViewController transitions.
Then I put that header in the precompiled header. Or more likely nowadays I add `-include main.h` to my other c-flags build setting because I have long since disabled precompiled headers and just use (`@import`) modules.
Much to my delight, Swift behaves like this by default.
I Never Have a `CHANGELOG` file
Seriously, gross. Just make your Git history good. Learn interactive rebase already. Use a good gitx fork.
