How to use AlamoFire and SwiftyJSON in Xcode 7’s playground

Or, a collection of an hour’s worth of {StackOverflow, personal websites, and NSHipster}-ing.

Part 1

Since I really should be using this Medium thing for something other than a casual 20 min browse between classes, I’m going to start by writing about bothersome witchcraft and bamboozles I’ve come across and how to solve them.

For this issue, irritatingly enough, Apple’s documentation isn’t terribly clear on what you should be doing (or at least, it wasn’t for me. I’m also writing this for the inevitable day I do this again. There’s a relevant XKCD, but I can’t find it. Would really appreciate a link, though).

Today, I was working on a personal project of mine — a Swift library for the Lob API. Obviously, hitting the endpoints with the right requests in your methods is a major part of any API wrapper, so my first thought was to write test cases for my networking code, and absolutely none of them worked, for reasons that should’ve been obvious to me. Alamofire is asynchronous, meaning your standard setUp → testCase → tearDown is not going to fly if you opt for no mocking. I found this to be a nice read if you’re interested: Testing Asynchronous Code in Swift. This piece is a lot more about what my second thought was…

…which was the playground! REPL’s are tons of fun, and I honestly wish JetBrains included REPL’s for the langs/runtimes they vendor (i.e Python, Ruby, Node, PHP etc), but c’est la vi.

So, if you have a completely CocoaPodded setup like I do up here:

I’m guessing that you’re thinking about all of this stuff as a hindsight (20/20, right?) so extrapolating off myself I figure this is what your projects looked like at that moment. If not, for those with a fresh-faced Xcode-created project, the difference is one

pod install

in your root project directory away.

If you’re not on CocoaPods…you need to manually create/save project as workspace and add all your shenanigans (playground, project/framework) into it. (Or so Apple’s docs say, but those are probably far more applicable than I am.)

Part 2

Pretty simple. Create a playground in your project directory, and then add the file. Which should leave you looking like this:

From here, you can import your classes into your playground. Except for, I think, the ones explicitly declared as private. Should be all good, right? I’m going to use my GitHub metadata as the JSON string to be parsed.

I clearly seem to be sending a GET request to the endpoint, but no JSON to be found….hrmmmm.

Remember me saying Alamofire is async? Playground doesn’t wait around for your results to come back, so you need to tell it to. So you add two lines to the top of your playground contents (I think it’s pretty self explanatory), and:

Hooray, you now have a JSON object fetched by Alamofire and parsed with SwiftyJSON that you can now tamper with at will in Playground! Links to AlamoFire and SwiftyJSON for the lazy.

Bonus Error

After modifying your Podfile, you may be very unpleasantly surprised by this little guy:

diff: /../Podfile.lock: No such file or directory
diff: /Manifest.lock: No such file or directory
error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.

I managed to get through it because I actually remembered and applied some knowledge from an intro class on software tools (never really thought I’d say that) and by reading the debug messages. For our future friends who find the 101 methods SO and the GitHub issues page for CocoaPods prescribes, here’s the compilation of band-aids so far:

1.

rm -rf Podfile.lock Pods/ <YourProjectName>.xcworkspace && pod install

2. Is your Podfile.lock in version control? It should be.

3. The tried and true Command — Q and open again

4. Go for the nuclear option — Remove CocoaPods in its entirety.

5. What worked for me: Requires a little bit of outside knowledge, but the tl;dr is that the $PODS_ROOT variable got nuked or wasn’t set for some arcane reason ($PODS_ROOT represents the full path to the root Pods directory, so something like User/SomeRandomPerson/Desktop/Projects/SwiftyProj/Pods/). Your project build settings, specifically, should look like this (open User-Defined settings if you initially can’t see it) :

PODS_FRAMEWORK_… and PODS_ROOT need to be present ON THE .XCODEPROJ’s build settings otherwise you will go crazy. Not on the Targets’ settings, the Project’s. You can get the values for which to set PODS_FRAMEWORK…. and PODS_ROOT from the Pods-<YourProjectName>.debug.xconfig file that CocoaPods generates for you, under the Pods/ directory under <YourProjectName>.xcodeproj.

Other things: PODS_ROOT is typically defined as ${SRCROOT}/Pods.

Hope this was helpful. First Medium post, woo!