Last week I spent some time trying to make my command line app, whereami, working with Cocoapods. Previously this was not possible, since Swift pods were not supported yet. But since Cocoapods 0.36, released a few days ago, it is possible to have swift frameworks linked into the executable. Actually, they are indeed linked as executables, and not compiled statically into the binary, as had been happening all along, since iOS did not support 3rd party frameworks. These was the default behaviour even if you were building an OS X app.
So what I ended up doing was writing the .podspec file for SwiftCLI, the library that handles all command line and option parsing in whereami. And, after 2 days of hitting against the wall and not being able to make it work, I realized what was wrong.
It wasn’t that I didn’t know how to write a .podspec. There was some of that, but after a few tries I got it right. The problem was that it is not possible to make a command line application that links to other frameworks.
Long story short: Due to the way that the Swift runtime is linked with applications, and not installed system-wide (to allow Apple to upgrade it more aggressively without breaking old apps), all apps using swift require frameworks implemented in swift to be linked dynamically, not statically.
On the other hand, since it is a single file binary, a CLI app has no room to hold dynamic frameworks, or other type of resources, that would normally go into the application bundle. This was no problem with Objective-C based CLI apps, as all dependencies are compiled statically.
So, for the time being, much as I would like, I cannot make whereami use Cocoapods, at least not for Swift frameworks. I have opened the corresponding radar (rdar://20250458) but I don’t think this will get fixed, if ever, until Apple deems Swift stable enough to be considered a System framework and all third party frameworks can likewise be installed in a centralized place.