First impressions of Swift Playgrounds for iPad

Exploring iOS 10 (beta 1)

One of the most exciting announcements at this year’s World Wide Developers’ Conference was that Swift Playgrounds, a feature of Xcode on the Mac since version 6, is coming to iPad. Although presented at the WWDC keynote as being primarily an educational portal, with a storefront where users can download content along the lines of iTunes U or the interactive textbooks of iBooks, as the Playgrounds session video makes clear, Playgrounds on iPad is an immensely versatile app. It promises to blur the boundary between developer and consumer, and as such there are at least three ways it can be used. First, there is the aforementioned downloadable content. Second, users can create their own playgrounds in-app, starting from a blank page, or from a number of templates. Finally, Xcode developers can author content in the new Playgrounds Book format, and will be able to distribute it via the storefront. In this series of post I’ll just be looking at the second of these use-cases, using iPad Playgrounds as a stand-alone developing tool to create playgrounds from scratch, in-app. Throughout the series I’ll focus on the question, is iPad Playgrounds a serious developing tool?

What an iOS IDE addiction looks like

First impressions of Swift Playgrounds on iPad

First, the good points.

For iPad-based coding Playgrounds represents a number of firsts. For starters, you have the complete iOS API available to you. Second, your code is compiled on the iPad before it is run, flaunting Apple’s rule barring third-party code-compiling apps from the App Store. Whether this means that third-party iPad IDEs will also now be able to compile code is anyone’s guess.1 There is an impressive degree of interoperability, Xcode 8 playgrounds run fine in iPad Playgrounds and vice versa. Currently Air Drop is the easiest way to send playgrounds between Mac and iPad, though iCloud support is coming apparently (and might already be here if you’ve installed the beta of MacOS Sierra?)

If you’ve not used Xcode Playgrounds for a while, then you might not be aware of a significant change that was introduced at the start of this year when the beta of Xcode 7.3 arrived. Apple announced that Playgrounds would become interactive from Xcode 7.3 onwards, meaning that views assigned to the playground liveview can now accept various user interactions. This was a big change, and was probably the first hint of what was to be unveiled at WWDC 2016. Prior to this, you could, say, mock-up a UIView in Xcode Playgrounds, but then once the playground was running, it wasn’t possible to interact with the view, except via various workarounds. Since Xcode 7.3, and now with iPad Playgrounds, playgrounds with liveviews can accept various types of user input, from gesture recognizers to UIControl targets.

This means that for certain development scenarios, say for instance a single-view app without complex asset requirements, a great deal of the app could be built in a playground.


I was worried that the performance wouldn’t be great on my iPad Air 1, but it’s actually not bad at all (these comments about performance are entirely subjective and unscientific). Playgrounds seem to compile fairly quickly (in Xcode 8 too, playgrounds seem snappier), and once they’re running it feels like we’re getting close to native performance. I’m happy to say that if you want to run an iOS-specific playground, iPad Playgrounds is much, much better performing than running the same playground in Xcode Playgrounds, as Xcode has to run iOS Playgrounds via an in-line iOS simulator (nb, of course if you’re not using any iOS-specific APIs and you’re wanting to run your playground in Xcode, then set it up as a MacOS playground to avoid the simulation step).

Not the most taxing of scenes, but here’s metal-backed SceneKit running at 60 fps

But for iOS-specific playgrounds, this is huge. As an iPad IDE junky, I’m something of an advocate for doing at least part of the development of your app on the platforms that it will actually run on. Developing in this way lets you iterate the design of your app, testing as you go on a real multi-touch, multi-oriented device, without having to wait for the app to build and deploy to the device, or run it through a stutter-y simulator that doesn’t have multitouch.

The coding experience

The iPad Playgrounds coding experience feels very similar to the Xcode Playgrounds one. In terms of error-checking, you get the standard build-time warnings and prompts, along with the “Fix-it” tappable auto-fix suggestions that are familiar from Xcode. As with Xcode playgrounds, as your code runs, you see an object icon appearing in the right-hand margin of the screen next to each line as it is run. These can be tapped to give you an idea of the object’s state during runtime. With run-time errors you get a varying amount of help. If your code crashes, you get a somewhat unhelpful alert saying “There was a problem encountered while running this playground. Check your code for mistakes.” Sometimes though, there will be a crash log available in the right-hand margin. If not, you can often at least tell where the code execution halted by where the trail of object icons in the right-hand margins stops. Although this is far from being a full break-point debugging system, a lot can be gleaned from the right-hand margin. You can watch how many times a given function is being called and so on, getting a feel for the control flow of your code.

Continuing with the good, the Playground coding keyboard is fantastic, by far the best implementation of an extended keyboard on iOS. Again this is in part because Apple is flaunting its own rules here. iOS 8 brought custom keyboards with it, but they are independent of any specific app. I’m not aware of any API that lets you have a custom keyboard specific to an app, that displays as the standard keyboard in that app. This means that in Playgrounds, the keys are a lot less crowded with extra symbols than rival iPad dev tools, as these competitors have to try and squeeze all those extra keys into a custom key-bar that sits above the standard keyboard. I hope that in future Apple makes custom app-bound keyboard into an API open to developers. It would really help declutter not just coding apps, but all kinds of writing apps that currently have extra keyboard bars.

The second great thing about the keyboard is that unlike other implementations, instead of pushing your finger toward the desired symbol, you pull your finger back in the opposite direction, and then release, as if you’re firing a pinball (or an Angry Bird). This simple reversal of the usual mechanic is wonderful. For one, and apologies if this sounds weird but you’ll just have to try it, flicking your finger back is faster and more natural-feeling than pushing it forward. Second, it means that your finger doesn’t obscure the symbol you’re aiming for. I wonder whether Angry Birds was lingering in the subconscious of the UX designer that came up with this mechanism? Gamification of UX, anyone?

Now for the not-so-good.

Having given us this fantastic keyboard, Playgrounds spends a lot of time hiding the keyboard from you. Touching almost any part of your code seems to result in the keyboard sliding out of view, leaving just the autocomplete bar at the bottom of the screen. It is as if the UX only wants you to use the keyboard for entering variables names, and the autocomplete bar for everything else (although, if your Mac is close at hand, make sure its keyboard isn’t surreptitiously pairing with the iPad). The autocomplete bar works for smaller playgrounds whose namespace has not yet become too cluttered, but if you have an object that inherits from NSObject, scrolling through scores of methods is not really practical.

A handful of extra shortcuts on top of the standard ones

I’ve not yet used Playgrounds much with an external keyboard, but it seems to support the standard text selection shortcuts. You can move through autocomplete suggestions with the tab key. Annoyingly though, there is no way it seems of commenting out a selected block of code all at once. Cmd / has no effect. You have to use the /* */ block-comment syntax instead.

Although both iOS 10 and iPad Playgrounds are in general already fairly stable for the first beta release (I’ve had two no-warning black-out reboots since Friday), certain APIs seem very buggy in iPad Playgrounds. SceneKit is a particular offender (more on this in a future post). I’m filing lots of bug reports, and I urge other users to do so too.

While we’re nitpicking, I love that Xcode 8 finally has a colour picker (and colour literals). But in iPad Playgrounds, the colour picker is missing the “other” button that its Xcode counterpart has, meaning that colour literals on the iPad are restricted to the (admittedly very nice) preset palette.2 Come on Apple, give us a full colour picker. Let those lucky iPad Pro owners explore the full range of their wide-gamut panels!

In the next post I’ll look at creating simple single-view playgrounds using SpriteKit, SceneKit, and an interface mock-up using UIKit’s UIStackViews.

Update (25 July 2016)

Not long after iOS 10 beta landed, a new iOS IDE for C# and F# called Continuous launched. Like Playgrounds, it lets you “code native”, addressing the full iOS SDK, via Xamarin (the cross-platform initiative now owned by Microsoft). I write a bit more about it in my SpriteKit post. According to Frank Krueger, the developer of Continuous, his app compiles the C#/ F# to Intermediate Language. So it seems that as long as the IDE doesn’t compile down to ARM, it’s within the App Store rules. Exciting times for iPad coders!

  1. To date, iPad IDEs such as the superb Codea and Pythonista have only been able to use interpreted languages, such as Lua and Python. JIT has not been allowed either. See update above though.

  2. There is a workaround here. If you comment-out a literal, its inner workings are revealed, and can be edited. Un-comment the line, and behold your new, custom colour literal.

Built with Jekyll      © Salt Pig Media