The iOS 10 Review: Refining the iOS Experience Both Over & Under the Hoodby Brandon Chester on September 13, 2016 12:00 PM EST
The iPad Pro has become a big part of my daily life. When I'm working, the 9.7" iPad Pro goes everywhere with me as a device for development and taking down information using either Apple Pencil or typed notes. When I'm in classes, the 12.9" iPad Pro is indespensable due to its ability to have two regular size class apps on the screen at the same time, which allows notes to be taken with Apple Pencil while a digital textbook or lecture slides are open on the other half of the display. For me the iPad Pro has replaced my laptop in every way except for one, which is my actual development work. As someone who does mobile development and writes C code for university courses, there's no way to escape using a laptop or a desktop computer to access XCode and Android Studio.
Some people may be wondering why Apple hasn't just brought XCode to the iPad. The simplest explanation is honestly just that bringing the entire IDE to iOS is an enormous undertaking. Apple has brought versions of their software to mobile before, like the iWork suite, but bringing XCode is a whole other story. In many ways it is not clear how to translate the interface of an IDE to a multitouch device like an iPad, and from a functional perspective it would certainly be difficult to bring over all the features that actually enable app development, many of which are just a GUI fronts for tools that are executed in the Unix shell behind the scenes. Allowing a user application to compile code and execute it also presents many questions and concerns regarding security. The list goes on and on, but suffice to say, bringing the entirety of XCode to the iPad is not a trivial feat and it's not near as simple as just making a new UI that works on iOS.
Bringing XCode to iOS might be too large of a project to do without some initial work in place. In many ways, that's where Apple's new Swift Playgrounds app for the iPad fits in. It has two functions. The first is to provide a fun and easy way for new programmers to learn programming concepts. To do this, Apple has provided a way for people in the development community to publish books for Swift Playgrounds that teach users by having them complete programming tasks in a fun and interactive way.
Apple provides two such books for learning the basics of the Swift language. In them you control a character called Byte who must be moved around a 3D world by walking and traversing through portals to collect gems and activate switches. It's a very interactive way of learning to program, and the books start out with the very basics of programming. Once you've gone through the basics, the sections begin to cover more advanced topics including debugging, algorithm design, and function generalization. There's also some coverage of algorithm efficiency, which is often not discussed enough in formal education or online programming courses. If you're someone who is interested in learning to program and you own an iPad, I definitely recommend checking out Swift Playgrounds. With any luck there will be additional books added by the community to cover more specific topics, such as actual iOS app development.
If you're already familiar with iOS development and UIKit there's still a lot that you can get out of the Playgrounds app. The second purpose of Playgrounds is to give programmers a way to test out ideas in a quick and easy manner. That was the point of XCode Playgrounds on the Mac as well, but with it available on the iPad there's now a way to test ideas even if you're not at your computer. When Apple originally announced Playgrounds I assumed it wouldn't have much use for existing programmers due to UIKit being unavailable or accessible only in a limited manner, making it essentially impossible to prototype ideas that will later be put into real applications. It turns out that this assumption was completely wrong, and from what I can tell the entirety of UIKit is available in Playgrounds, along with direct access to the underlying C-based APIs like Core Graphics and Core Animation.
In the video above I've shown how some UIKit APIs can be used in Swift Playgrounds on the iPad. Since UIKit is available, it would actually be possible to write an application of sorts within Swift Playgrounds, although as of right now I haven't experimented enough to say what sort of sandboxing limitations may exist on APIs that send or receive data over a network. In my video above you can see that creating your own playground presents the same split interface between the code editor and the live view. You can actually long press the separator between the two and move it to bring the editor or the preview into fullscreen, and it uses the same sort of UI as multitasking on the iPad so it's a familiar interaction.
For my demo I've made a UIView subclass which also draws a button and a second view that I have poorly masked to look like a circle and filled in with red. My intent was that the circle would pulse inward and outward when the button was pressed. As you can see, I actually made a mistake before recording and started animating the outer view pulsing in and out. Since I was already recording I felt it would be a good opportunity to show the code editing in XCode Playgrounds, so I fixed the bug in the middle of the video and made the circle pulse properly as it should have. This is just a very basic example of what can be accomplished using Playgrounds, and I expect that developers who start working with ViewControllers or bring in Apple's other APIs like SceneKit will be able to create some amazing things on their iPads using Swift Playgrounds.
Experienced programmers may be wondering how well the iPad works as a device for programming given that it doesn't have a physical keyboard or any sort of mouse pointer. Apple has actually done a good job of making the iPad's touch interface usable for programming in Swift Playgrounds. The most significant work has been done to the keyboard. It's a special keyboard with shortcuts to common programming symbols that aren't normally accessible on the iPad's keyboard without going into the symbol menu. To access them you simply put your finger on the key and pull the symbol toward you. This is helpful for accessing certain symbols, but it's still not as fast as having dedicated keys. Thankfully, the editor does a good job of automatically placing braces and matching brackets, and there's also a library of pre-formatted code blocks with placeholders so you can quickly drop in a loop or a control flow statement.
The only big issue with the on screen keyboard is that it takes up a great deal of your workspace. To help mitigate this when users don't have a physical keyboard, the shortcuts bar remains visible on the bottom of the screen unless explicitly dismissed after the keyboard already has been. The autocompletion is also very good, to the point that you can often do your work without actually having the keyboard up. Apple also provides buttons to create a new line or erase an entire line when editing in this mode.
While I said that Swift Playgrounds on iPad has two functions, it's more accurate to say that it has two user-facing functions. I think it has a third function which is specific to Apple, which is to lay groundwork for an eventual version of XCode that will run on the iPad. Swift Playgrounds provides a risk free way to test what the iPad can do with regards to writing and running code, and it allows Apple to experiment with new UI and functionality ideas without having to make the sort of stability and support promises that officially bringing XCode to the iPad would require. Most importantly, it allows Apple to think through what sort of security model is required to allow actual app development on the iPad.
Right now Swift Playgrounds already allows you to do impressive things as a programmer, and for me it is a great tool for testing ideas that come to mind when I'm away from my development machine. Having access to UIKit is huge, and it means that Apple is already giving programmers access to the same API set that is used to develop iOS apps in XCode on the Mac. Expanding this into an actual IDE that can be used to program applications requires Apple to integrate Interface Builder and Clang, plus Apple's own solution for code signing. Of course, even with those, an initial release of XCode for the iPad would be rather simple compared to its macOS counterpart, but the foundation of the IDE will have been laid out to be expanded on in future updates. With Swift Playgrounds Apple has already laid a great deal of that foundation, and I think it's very likely that you'll be able to develop iPad apps on your iPad itself in the not too distant future.