Swift playgrounds have been around for years, but I haven’t found them all that useful so far. I’ll spin up a playground now and then when I want to quickly see how a particular api works or iterate on a small function, but they’ve never been a crucial part of my workflow.
I was watching a Point-Free episode the other day and I noticed they had a playground in their Xcode project that also had full access to all the types in their app target, which I didn’t know you could do! A little searching shows that I missed this was added over a year ago in Xcode 12.5.
The setup is really simple, just open your project, then go to Xcode > File > New > Playground, and be sure to select the option to add it to your existing project. I found I needed to close and reopen the project afterwards to get the playground to actually work. But after reopening, the playground can access all of your app types. You can even access packages that your app target depends on as well if you import them.
This ends up taking playgrounds from a seldom used tool to being something I’ll integrate in every project from now on. As I write more SwiftUI, I find myself seeking the speed of that feedback loop in every part of development. Often I want to either explore how an existing thing works (like what kind of output do we get from this method) or figure out some new functionality (like spike out a new protocol), and doing it within the full app flow is too slow and tedious.
Now I have a built-in, live executing environment for exploring existing code, adding new code, and iterating on my app without needing to run the whole thing. You can even test views as well. Playgrounds still aren’t perfect — and I hope we see more improvements this year — but this gets a lot closer to the SwiftUI flow and so far is a big overall improvement to my workflow.