After spending some evenings investigating how Swift Playgrounds worked in Xcode (parts I, II and III), particularly with live views for iOS, I knew enough about them to create a proof of concept reimplementation. Of course, the proof of concept quickly turned into the much larger goal of creating a fully-functioning Mac app. That Mac app is now in a place where it does just enough to be shown off. Here’s a short example of it in motion:
Right now JungleGym can open, save and run iOS playgrounds with one source file. This means it doesn’t support additional Swift code in the Sources directory or anything in the Resources directory, nor can the playgrounds import third party frameworks. I’d like to add all of this in the future, and you can see the current list of outstanding work on Github.
My long term goal for JungleGym is to try to make playground-driven development of larger iOS apps easier. For example, one small hiccup is that it’s not normally possible to select a device to run your playground on. This means it’s not possible to see what your view looks like on an iPhone X display as you develop it. JungleGym already allows this, although it will need the auxiliary source support I mentioned to do this with a playground that lives in a Xcode workspace. Another frustration is the loss of the short feedback loop once code is moved from a playground during initial development into a framework to use in an app. This is a more difficult problem, but I have some ideas to try for this too.
The iOS platform is often derided for it’s long feedback cycles during development, especially with the Swift compiler’s slow compile times. There are other attempts to improve the situation, like Injection, but I’ve had mixed success with them. I started making JungleGym because I wanted to see if it was possible to run a playground on an iPhone X display, and there’s been a lot of investigation and learning since then. I’m hopeful that this becomes a tool used for real development.