Write SwiftUI Entirely on an iPad Using Swift Playgrounds
You don’t need to open Xcode or even own a Mac to get started with Apple’s new declarative design framework. Write and test simultaneously!
Here are the basics of what this tutorial is about:
When Swift first appeared in 2014, it was designed to be an easy first programming language. Semi-colons aren’t required to end each line, conditional statements don’t need to be inside brackets, and it’s not necessary to end every case of a switch statement with a break. This makes it easier for kids to write their first code without needing to constantly look out for missing punctuation. The language was made more accessible when Apple released the Swift Playgrounds iPad app in 2016, making it even easier to learn the basics in a classroom or at home, even without a computer.
Until June 2019, the only way to design a user interface for a Swift app was using storyboards, a drag-and-drop interface that stored its data in a complicated XML file. This all changed when Apple announced SwiftUI, a declarative language for designing user interfaces that can be instantly previewed. The Swift Playgrounds iPad app has recently added support for SwiftUI, as well as the Combine framework which provides new ways to handle asynchronous events.
Let’s see what SwiftUI allows us to do on iPad now that we could never do before.
If it isn’t already on your device, download the free Swift Playgrounds app.
When you open Swift Playgrounds, you go straight to the New Playground page. If you have opened the app before, you’ll see your previous Playground files here. If not, the screen will be mostly empty. Either way, there is a panel at the bottom of the screen that has the title Other Playgrounds. Tap the blue ‘See all’ button at the right end of this panel, and the panel should expand to show the Swift tutorials Apple provides. Scroll down to the Starting Points row, and tap the blue ‘See all’ button for that.
Now you should be able to see all the example projects that Apple provides, although there isn’t an example for SwiftUI at the time that I’m writing this.
You have two choices that will work as Starting Points for this tutorial. Blank will create a new
.playgroundbook file that can be opened in Swift Playgrounds on an iPad, but cannot be opened by Xcode on a Mac. If you‘re fine with using your iPad independently, this is probably the format for you. If you can see yourself transferring to Xcode, this is where the Starting Point called Xcode Playground comes in. This uses the same
.playground file type that Xcode uses, giving you the ability to edit the same file on both devices.
Swift Playgrounds seems to store its documents in iCloud by default, so it’s easy to see how you could access the same file from either device without having to email or AirDrop it to yourself each time. The New Playground page of the app has a blue Locations button in the top left that allows you to browse using the Files app, allowing you access to other cloud providers, such as Dropbox, Google Drive, and Microsoft OneDrive, too.
Again, if you only want to learn SwiftUI in a safe sandbox on your iPad, this won’t matter to you as much.
It’s possible to write SwiftUI in Playgrounds without a preview window. To do this, you simply import SwiftUI and create a struct that conforms to the View protocol, with the required body variable that returns ‘some View.’ Playgrounds has some code completion and can help you correct your SwiftUI with automatic fixes for common mistakes. But the real power of SwiftUI in Xcode is the ability to see a live preview of what you’re creating, so we need two more lines to make that happen on iPad.
PlaygroundSupport gives you access to
PlaygroundPage, which allows configuration of your iPad coding environment. Only one Playground page is active at any given time, so this static instance is accessible through
PlaygroundPage.current. This gives us the ability to set the live view, which runs continuously on the iPad, to the
ContentView that we created above.
Now you should be able to press the ‘Run my code’ button and see that the app turns into a split view. On the left is the SwiftUI code, and on the right should be the live view that shows ‘SwiftUI on iPad’ in bold text in the centre. Now you’re ready to build your user interface, which will make use of many of the controls that come with SwiftUI.
First, we’ll need to use
State variables, which basically store data locally in the SwiftUI struct and redraw the
View whenever their values change.
Add these inside the
ContentView struct brackets but before the declaration of the body property. This is all we’ll need to store the state of all of our controls.
Togglethat changes whether a
Buttonthat alternates between red and blue each time you tap it
Stepperthat increases a displayed number
TextFieldthat displays what you wrote in a
Sliderthat displays its value in a
You can add these in any order, but they must be inside the brackets of the main VStack. This is because the body property has to be one single
View, so you can’t just list a load of controls. VStack makes this different by allowing you to arrange up to ten
Views inside it, while still satisfying this requirement of being one
View for the purposes of the body property. It makes sense that the controls be below the
Text you wrote originally since this is the title, but this is not required.
Every time you add a control and there are no errors, the live view successfully updates itself. You should be able to try them out and check that they do what you expect. You might notice that the split view has a handle in the middle. You can drag this to change how big the two halves of the screen are, just like you can when multitasking with two apps on your iPad in Split View.
When you make the live view big enough, it suddenly becomes fullscreen, which might be useful for previewing more complicated interfaces. You’ll see an arrow in the middle of the left side of the screen, which you can tap to return to split view. Similarly, swiping the split-view handle to the right can make the code fullscreen, which probably makes it easier to focus on writing and debugging the code before testing it with the live view.
A great starting place to learn more is Hacking With Swift’s SwiftUI by Example. These tutorials are always up to date and easy to follow. You may occasionally come across bugs in the iPad app, as SwiftUI support has only just been added. In my experience, the live view on iPad actually seems to be faster at refreshing than Xcode’s preview canvas, possibly because it can’t be used to inspect and configure
Views. In other words, the iPad can display the SwiftUI, but you can’t tap on an element and get a drop-down window of properties you can modify, like in Xcode.