blog.mazur.me

How to get Playground Driven Development working with Carthage

2019-02-09T00:00:00+00:00

I introduced Playground Driven Development on the last project I worked on. It sped up my development and forced me to write view controllers in a decoupled way. But before I was able to reap the benefits of PDD I hit a roadblock: Xcode Playgrounds kept throwing a Couldn't look up symbols error, because it couldn’t see Carthage-built dependencies. Here’s how to fix this issue.

Identifying the problem

Initially I wasn’t sure what the source of my Playgrounds problem was, so I made a sample PDD project without Carthage. Next I installed Carthage and added a single dependency¹. This reproduced the problem:

Fixing the couldn’t look up symbols issue

I knew Playgrounds were missing some symbols, and I knew this was Carthage related. It became clear that Carthage supplied dependencies weren’t being seen by Playgrounds. What wasn’t so obvious to me is how to fix this issue in a way that wouldn’t require any kind of Xcode project restructuring.

I reached out to the iOS community with the sample project that reproduced the problem, and it turned out that Logan Moseley was having the same problem. Within a day Logan figured out the simple fix I was searching for. Thank you Logan! Here are the steps:

Select Xcode → Project Settings → Targets → your main AppFramework target
Click on the Build Phases tab
Add a Copy Files phase
Select Products Directory as the Destination
Drag all Carthage-supplied frameworks in from the project navigator’s frameworks group
Clean and re-build the project, open the project playground and start playing

Here’s how the new Copy Files phase should look:

We’re done. Playground Driven Development with Xcode and Carthage should now work. 💫

The master branch has a self-contained Xcode project with working PDD. The carthage branch installs Carthage and shows the problem (you still have to run carthage bootstrap). The fix is on carthage-fix. ↩

Tracking dependencies with DEPENDENCIES.md

2019-02-03T00:00:00+00:00

A growing list of third-party libraries is something most development projects have to deal with it. On many projects it can be hard to figure out why a certain dependency was added, or whether it still makes sense to keep it. We can track dependencies through a DEPENDENCIES.md document just like we track changes via a CHANGELOG.md.

Writing a dependencies document

There needs to be a good reason for why a dependency gets added to a project. That reason is what we need to write down.

Here’s an example:

The above example shows how we can differentiate between different types of dependencies. As an added benefit we can have a a nice overview of what licenses our dependencies use.

This is a technique I’ve used for a few years on a past project, and it saved a lot of my time when re-evaluating whether some dependencies should be removed.

Hello, World!

2019-01-05T00:00:00+00:00

I’ve always put off creating a blog, but no more. Hello, World! I imagine this blog will mostly be about software development (for the iOS platform especially, so Swift, Xcode, UIKit, and so on). Then again, who knows - I’m not putting any constraints on this blog, so lets see where this journey takes me.