Swift Playgrounds are the multi-touch of programming

When the original iPhone was introduced, like probably most people, I was captivated by its multi-touch interface. Gestures like scrolling and pinch-to-zoom made sense immediately and not only that, they removed a level of indirection from using applications that was part of all computer interaction up to this point. Rather than wiggling a mouse to move a cursor you now touched and interacted with the application directly.

While this may seem like a small detail, the effect on usability is actually quite profound. There is nothing like panning and zooming a map or photo with a multi-touch interface. It feels like a natural interaction.

Multi-touch also had an interesting effect on the process of software creation. There has always been an aspect of UI design that is typically described as “craftsmanship” or “good design”, signifying quality. However, touch interfaces changed the meaning of this in that it truly became about crafting the interface, creating a touchable and almost — if not actually — tangible thing.

Anyone who’s found themselves playing with a UI animation will understand the importance of this. Pulling down a bit on the iOS home screen to tease in the blur and reveal the spotlight search field is akin to playing with a button on a well-designed physical object. Software has become tactile.

Similarly, Swift playgrounds — and iPython notebooks before them — are the multi-touch equivalent of programming. In the same way the iPhone changed how we interact with applications, these development environments, by removing — or rather hiding — the build step, make programming more immediate. They remove indirection, your algorithms come to life side by side or inline with the results.

What seems like a little change actually has a profound effect on how you work with your code, how you model it, tweak it — touch it.

I experienced this recently when designing an iOS component to display occupancy on a train. Rather than use a tool like PaintCode or a traditional build, run cycle I created a Swift Playground and assembled the parts here, starting with a little figure for the passengers:

(The actual draw code is very simple and only hidden from the screenshot for sake of brevity.)

This exercise was a pleasant and fun process and encouraged me to keep going. I needed a need a little badge to show the carriage number and a colour to indicate how busy it is, which is an overlay on the carriage:

This is like lego but with code! Let’s just just take several of those cars and stick them in a train:

It was a joy and a breeze to design this view in a Swift Playground but it’s not just for views that this works very well. As you may note, the badges do not scale linearly with the cars. They are proportionally larger for small sizes so the number remains legible. I used a sigmoid function for this and it’s very easy to show what this looks like and to tweak it in a playground:

I mention iPython notebooks alongside Swift playgrounds, because they’ve been around for longer and I’ve used them to similar effect as Swift Playgrounds. However, I suspect Swift playground will surpass them by far, for two reasons:

Apple’s backing of Swift and the massive interest its open source project has created means it is a language with a very bright future, likely to reach far wider adoption than Python.

The availability of Swift Playgrounds on iPads in addition to the more professional level Xcode on macOS opens them up to an entirely new audience.

Similar to many people now growing up without mice and hardware keyboards as their main input devices, I believe there will be a generation of developers who write code very differently from the traditional edit, compile, run cycle.

One thing holding Swift Playgrounds back a bit at the moment is their limitation to macOS or iOS. While Swift is available on Linux, Swift Playgrounds are not.

The best of both worlds would be a Swift kernel for Jupyter notebooks, essentially making Swift Playgrounds available on any platform that can run an open source stack supporting Swift. Wouldn’t that be an interesting project!