Playground Driven Development
Swift Playgrounds are a wonderful thing. They are fast. They allow you to try quickly your code. They allow you to check your UI in a matter of seconds. They can really speed up your development cycle.
This is a brief video of how they can help while prototyping a cell for a collection, for example.
The main gain, in this case, is that you can render your view immediately in the playground. You can change small bits and check how they look. Once you are satisfied with the changes, you can take the playground file and move it to the right place.
However, how can we start using playground in our development cycle, now?
Chances are that you are working on a complex application. The application can be composed of different frameworks and potentially it uses also some Pods, leveraging the Cocoapods’ dependency management.
This article guides you to add a playground to your app so that you can prototype your UI and your algorithms faster than ever!
Note: If you are already an expert on Xcode and dependency management, you can skip directly to the “Adding The Playground” section of this article.
Creating the project
Let’s start with the basics. We have to create an iOS application and, to keep it simple, we can:
- Open Xcode
- Click on
File > New > Project
Appfrom the iOS templates
- Give it a name (I have chosen
- Choose a location on disk and click
Nothing fancy here. Just the usual stuff to create a new project.
Given that we don’t want to actually use storyboards, let’s clean up a bit the template:
- Delete the
- Add the following snippet to the
- Open the
Info.plistfile and remove the two highlighted entries
- Hit the
Playbutton and make sure that the app builds and runs!
Adding a framework
We all like modular applications. They have several pros:
- they build faster: unchanged modules are not rebuilt.
- they encapsulate the logic better: the module exposes only what it wants and requires only what it needs.
- they foster collaboration: many people can work on different modules and the final integration it’s usually easier.
- they push code reuse: if there is a piece of code that is generic enough and that is used in several places, it’s a good candidate for a module.
However, iOS apps in Xcode do not define a Target that can be imported by other modules. This is true also for the playgrounds: if we want to prototype something in our app, we need it to live in a framework. And that’s another reason why we need to create a framework!
So, let’s create a framework where we can implement our UI.
- In Xcode, click on
File > New > Target
- Scroll down until you find the
- Select the
Frameworktemplate and click next
- Give it a name (I called it
Hint: If you have to create a big app, consider creating a separate module for each UX flow or feature… or even for each screen! It really depends on how much you want to push the modularization.
For the sake of this example, let’s take the
ViewController.swift file move it to the new framework. If we try to build the project now, we will incur a bunch of failures. To fix them:
- Open the
SceneDelegate.swiftfile and add
- Open the
ViewController.swiftfile and update the code with the following snippet:
In this snippet, we just make the
public so that we can create it from the app, and we add the required initializers.
Now, we can hit the
Play button again and see that the app is running as before.
Adding some pods
We don’t want to reinvent the wheel. There are many very good libraries out there that can solve common problems in our daily routine.
Cocoapods is one of the most famous dependency management and also the one that we use at Bending Spoons every day. Let’s try to integrate a library into our project.
- In the root folder of our project, create a file called
- Copy and paste the following snippet
- In the terminal, navigate to your project root folder
- run the command
pod installand wait for the process to finish
This process will create an Xcode workspace that has the
.xcworkspace extension. This environment is slightly different from the standard project: it basically collects different
.xcodeproj so that they can work together.
Let’s open the
PDD.xcworkspace and you will see the following situation in the project navigator:
Now, we can access the
PinLayout Pod and we can use it to layout elements of our views!
Adding the playground
Given that we want to be really fast when iterating on the UI, we want to add a Playground to the project.
To start with, let’s create it in the standard way:
- In Xcode click on
File > New > Playground
- Choose the
SingleViewtemplate and press next
- Navigate to the same location where you create your project
- Give a name to the Playground (I decided to call it
- In the bottom of the dialog, select your workspace for both the
Add to:and the
Now Xcode created a new playground we can play with. The playground also supports the
liveView feature that helps us in prototyping everything fast.
However, we now have modified our workspace. What happens if we have to add a new Pod to the project? The
pod install command recreates the
.xcworkspace and, once opened, the playground is gone!
Adding the playground back automatically
If we explore a bit what is a
.xcworkspace file, we discover that it’s basically a folder which, in particular, contains a file called
This file defines the structure of the workspace. A newly created workspace from the
pod install only has the following content:
While a workspace modified by adding a playground has a
contents.xcworkspacedata with this content:
Thus, to automatically add our playground to the workspace, we can cook up a little script (in Swift, of course) we run just after the
pod install command.
The script looks like this one:
To run it, you just have to type
swift integrate-playground.swift in the terminal and let the magic happen.
It basically uses the file manager to retrieve the playground and the
xcworkspace. Then it adds the line to include the playground into the workspace. And that’s it: from now on, we will always have our playground to prototype our views and algorithms!
Prototyping a view
At this point, we can use the playground to prototype whatever we want. For example, we can add the following snippet.
- Add the following code for a view, which uses
PinLayoutto layout the label.
- Create the
- Create the
MyViewand replace the
- Set it as the new
Finally, we can tun the Playground.
It builds and runs extremely faster than the project. We won’t even have to wait for the simulator to bootstrap, install the app, and run it.
We can iterate on the UI until it’s final. Once we are happy, we can just copy the code we just wrote into a proper file of the proper module.
And that’s it! Fast prototyping in a nutshell!
In this article, we walked through the creation of a project with several dependencies: custom frameworks, pods, and playgrounds. The ideas explained will work also with the Swift Package Manager and other dependencies management systems. We also automated the inclusion of the playground into the workspace: this way, we won’t have to add it back manually every time the workspace is re-created.
At Bending Spoons we do not create our projects manually, but we leverage different tools that create the
xcodeproj from other templates. Xcodegen is one of those tools. The ideas expressed in this article apply to projects created with these tools as well.
Playgrounds are truly powerful. I hope that this article can speed up the development of your next app.