UPDATE: (10/12/15) While the strategy below works, you may also want to checkout https://github.com/devxoul/CocoaSeeds, which seems to be a much simpler way automate what I was doing here. (Haven’t used it, but it looks much cleaner than this kludge).

So we want to use 3rd party swift code. But we aren’t ready to drop iOS 7.0.

Currently, your only option seems to be to use git submodules. But anyone that has dealt with git submodules, before…they are serious pain. That would involve changing our own build process and getting all of the developers to have to include extra steps when they pull in new code.

Currently, Cocoapods 0.36 will support Swift — but ONLY as a dynamic framework. Which won’t work if you still need to support IOS 7.0+.

We already use Cocoapods to pull in 3rd party Objective-C code (Shimmer uses 12 external pods now, all of them great!).

What I ended up with is a bit of hack, but it works pretty well.

Create a subdirectory in your current project’s source directly. We are going to create an entire “dummy” project environment inside this directory. But it should NOT BE at the same level as your current “Pods” directly (assuming you use Cocoapods). Create a new dummy iOS project. I called my project “DummyProjectForSwiftPods”. And just used the XCode project wizard to create a new IOS app here. Keep it small and simple. (The “SingleView” application is good.) Now that you have a new project, we are going to add a second Podfile for our dummy subproject. ex: Now run “pod install” on your subproject.

Podfile

You should now see an entire subproject, workspace, and Pods directory. But we aren’t going to build this project. It’s just there so we can use a second Podfile to import Swift code. Leave all your Objective-C code inside your app’s primary Podfile. This second Podfile is ONLY for Swift Code.

5. Now return your original app project. Make a new Group. Maybe call it “ExternalSwiftCode”.

6. Then select “ExternalSwiftCode” and click “File -> Add Files to “TargetName”. Under the “Added Folders” option, select: “Create Groups”.

7. Navigate into the “DummyProjectForSwiftPods” directory, into it’s “Pods” directly and find the name of the directoy of the pod you wish to add. (ex: “FutureKit”).

You should now pull in all the source files from that pod directly into your top level project. You may have to add/remove files from the project everytime you “pod update”.

Add a new “Check Swift Manifest.lock” in your Build Rules

Find your Application Target. Go to Build Phases Add a “New Run Script” Build Phase. Add the following script. You will have to change the directory names to match your sub-projects podfiles.

Check EXTERNAL Swift Pods Manifest.lock

rename the script to something like “Check EXTERNAL SWIFT Pods Manifest.lock”

Move the script so it executes just after your existing “Check Pods Manifest.lock” script file.

Warning: Your app and the cocoapod MUST be using the same variant of Swift. So you can’t currently pull in swift 1.1 code, if your app is using swift 1.2 (or visa versa). Most pods are moving to swift 1.2, so this hopefully won’t be a limitation for long.

Some limitations: This may not pull in any static resources the pod may contain. (Ex: images, internationalizations, etc). You may have to manually link those. It seems to work well when the pod contains pure swift code.

You also are pulling an entire “external” framework into your application, so you may have namespace conflicts with your existing code.

I have a working example of a project here: https://github.com/FutureKit/Swift-CocoaPod-iOS7-Example

Yes — it’s a bit of a giant kludge. But if iOS 7 is holding you back from using some great swift code out there — don’t let it!

You can probably pull the same trick using Carthage. But since we were already using Cocoapods, we didn’t want to have to add yet another tool.