JustTheSam

I was writing tests in Swift for a time parsing function, and on the way to getting it right, I saw some very confusing error output, as per the screenshot above. In that screenshot I’ve deliberately broken the test (the times don’t match) to invoke the red error text, but what’s interesting is that the error reports 04:02:15 and 04:03:15 instead of the times I actually used – 04:01 and 04:02 respectively.

When you’re testing time-parsing code, the last thing you want is the test failures giving confusing/misleading figures so I had to get to the bottom of it.

It turns out that GMT and “Europe/London” timezones diverge through history (ignoring daylight savings). In fact, in the year 0 AD they were one minute and fifteen seconds different, and it’s this discrepancy that was showing up in my tests. Note that it doesn’t affect the test results themselves – only the display of NSDate values when there’s a test failure.

I was constructing test times from NSDateComponents and only specifying day, hour and minute, as that was all that was relevant to the tests. However that left the year defaulting to zero. I was also specifying timezone as NSTimeZone(name: “Europe/London”). The error messages from XCode only have an NSDate to work with however, which doesn’t have any notion of timezone, so XCode used UTC/GMT to format for display. And being year zero dates, the time comes out differently. The simple fix for me was to set the year in the NSDateComponents to 2015 to get everything into line.

What would happen if I ran the tests in the summer, when daylight savings is in the effect here in the UK? I’m not sure, but I might end up with times an hour out, for the same reason.

Here’s some code you can dump into a playground to demonstrate. The results are even weirder if you use “Europe/Paris” as the timezone, giving “”0001-01-01 10:35:39 +0000” as the output, just nine minutes and twenty-one seconds earlier, rather than the whole hour earlier that one might expect (and that you get if you use 2015).

// Demonstrate GMT/UTC != "Europe/London" in year zero.
let ukTimeZone = NSTimeZone(name: "Europe/London")!
let ukCalendar = NSCalendar(calendarIdentifier: NSCalendarIdentifierGregorian)
ukCalendar?.timeZone = ukTimeZone

let dateComponents = NSDateComponents()
// Reinstate this to fix things.
//dateComponents.year = 2015
dateComponents.hour = 10
dateComponents.minute = 45
dateComponents.timeZone = ukTimeZone

let date = ukCalendar?.dateFromComponents(dateComponents)
date?.debugDescription // "0001-01-01 10:46:15 +0000"

TL;DR

It’s actually pretty simple, if you know what you’re doing:

• convert project to a workspace if it isn’t already
• add Carthage/Checkouts/SWXMLHash/SWXMLHash.xcodeproj to the workspace
• move playgrounds to the workspace (not a project)
• build the SWXMLHash project.
• import SWXMLHash successfully in your playground, as long as the target you have selected includes the SWXMLHash framework project.

But if you don’t know what you’re doing…

I struggled to “import SWXMLHash” in my XCode Playground. I kept getting an angry red error for the module import. SWXMLHash is a third party framework I wanted to experiment with, that makes XML parsing nice and simple (ish).

Having figured out the trick to getting third party frameworks working in playgrounds, I thought I’d document it and the pitfalls. Really it’s pretty much just a case of following Apple’s own documentation, but I still took a while to get it right, mostly due to still being on the learning curve for the ecosystem. So my instructions are more tailored to the innocent newbie.

In my case I’m using Carthage to fetch and build SWXMLHash, so I have a copy of the framework’s project source in my project’s Carthage/Checkouts/SWXMLHash directory. Which we can use later, but first…

You need to be using a Workspace, not a Project in XCode. I had a project because that’s what XCode gave me when I started my new world-beating app, and I didn’t know any better. Use File > Save as Workspace… to save a workspace file containing just your current project. It seems to be traditional to use the same name as the main project, so we end up with Foo.xcodeproj and Foo.xcworkspace files. From now on, always open the workspace not the project.

Now move your playgrounds out from your project and into the workspace – i.e. up a level. I did this by deleting the playground reference from within the original project, then adding it to the workspace with the + button in the very bottom-left of the XCode UI. That button adds to whatever is selected, so ensure nothing is selected (cmd-click on the currently selected item to deselect it). There are probably other ways. Hell, maybe you can even drag them, but I didn’t try that.

Playgrounds can only deal with Frameworks whose project is within the same workspace. If you’ve only got a .framework file I believe you can put it in with the system frameworks in the right place on disk and it will be found, as a workaround, but I’ve got the project courtesy of Carthage so we’re OK here. Add that project (Carthage/Checkouts/SWXMLHash/SWXMLHash.xcodeproj in my case) to the workspace via that bottom-left + button. Build that freshly added framework project for Mac by selecting the relevant scheme from the dropdown in the toolbar and selecting Product > Build.

Now, in your playground, you should be able to import and use that framework, but there’s one final wrinkle: the currently selected target must include the SWXMLHash framework project. Targets that include the Carthage-built framework don’t count – it has to be the framework project that you added above. So for example, selecting the SWXMLHash target itself works. You want the OSX build, because that’s the variant of the framework that is used in the playground.

It’s also probably for the best that your playgrounds now exist in a workspace rather than in a project, cleanliness-wise. It should look something like the image below, with playground, framework project and my own project in the workspace, and the module import working correctly in the playground