There have been several rumours posted in the past few months of a team inside Apple working on a version of Xcode for the iPad Pro. Since programming on touch screen devices is kinda my thing, I’m very excited about this possibility!
Apple claims the iPad is its vision of the future of personal computing, but I worry how exactly Xcode for iPad fits into that vision in practice. This essay explores those rumours and looks at the true potential of iPad as a vision for the future of computing.
The Rumours
Mac Stories and Daring Fireball suggest two possibilities for Xcode on iPad: a full-blown Xcode IDE for making full apps directly on the device, or a version of Swift Playgrounds directly on the device. I think both possibilities have some major flaws, but even if these flaws were overcome I’m not sure it bodes well for a vision of the future of computing.
Full Xcode IDE
Here’s a super quick mockup of what a full Xcode IDE might look like on iPad:
This is almost certainly not an accurate mockup, but it’s at least useful to talk about as a concept. Code editor on one side, test app on the other side. While my mockup is devoid of any details (how do you navigate files? how do you edit the code? how do you debug the app? how do you debug iPad apps?), the basic concept is pretty straight forward: It’s like Xcode for Mac, but in an iPad app.** I’m also assuming it’ll be Swift-only, since Apple is pretty adamant Swift is its language for the future. More on that below. Professional iOS developers can make apps, directly on the device.
But I think this is a bad idea. Professional iOS Developers depend heavily on today’s Macs. They make extensive use of keyboard shortcuts and, more than they’d likely admit, the mouse (while the iPad Pro has, optionally, a physical keyboard and the Apple Pencil as a pointing device, it’s hard to use the Pencil while the iPad is propped up by the keyboard).
More importantly, iOS Developers make extensive use of an ecosystem of tools forbidden on iOS, like command line source control tools (Git and its friends), build and testing tools, and design and other specification tools they must refer to while writing code. Although Xcode for OS X provides a lot for developers, we still regularly depend many other Unix tools to do our jobs.
Swift Playgrounds
In John Gruber’s post about Xcode for the iPad, he suggests:
Maybe Xcode for iPad starts out only offering Swift playgrounds — a tool that lets you tinker and learn, but not a full-fledged IDE for apps.
From a learner’s perspective, Swift Playgrounds are way better than the old-fashioned “compile your code and maybe see the output” we’re stuck with as everyday programmers. Live coding is an essential start to learning how to code, but you need so much more for learning programming. Like many live coding environments, Swift Playgrounds on the Mac suffer from many issues.
In his essay lambasting Khan Academy’s live coding Javascript environment, Bret Victor writes:
Programming is a way of thinking, not a rote skill. Learning about “for” loops is not learning to program, any more than learning about pencils is learning to draw.
People understand what they can see. If a programmer cannot see what a program is doing, [they] can’t understand it.
Thus, the goals of a programming system should be:
- to support and encourage powerful ways of thinking
- to enable programmers to see and understand the execution of their programs
While I think Swift Playgrounds score a little better than Khan Academy’s live coding (Swift has labeled method arguments and the standard libraries are more consistently named than Processing’s), Swift Playgrounds fail to meet many of the principles for designing learning environments in Bret’s essay.
It’s hard to read the vocabulary. (what’s a var? what’s a str?) Yes, you can include markdown documentation in your Swift Playground files, but the environment doesn’t let you actively explore and understand the code itself.
It’s hard to follow the flow and see the state. Although Swift Playgrounds show how many times a function is called, and what’s in a variable on a given line, it’s almost impossible to explore how values change as they flow through a program. What are the inputs and outputs? When do they vary? Why do they vary?
Swift Playgrounds offer no tools for creating by reacting or abstracting, aside from copying and pasting or manually refactoring code. Unless a learner explicitly knows about a class name (or scrolls through a huge autocomplete list), they’re unlikely to unearth much of what UIKit has to offer. How is a learner to know to get a line or a circle on screen they must use something called a UIBezierPath? or to animate their given view, they must use a class method on UIView instead of an instance method on the view itself?
Industry vs Enlightenment
Apple could certainly either improve access to developer tools on iPad and make a full Xcode IDE work on iPad, or it could improve Swift Playgrounds enough to make it a vastly more learnable experience. But both of these options are lacking in vision for the future of computing.
I know Apple wants Swift to become the “programming language of our industry for the next 20 years,” and for the programming industry maybe that’s fine. But programming is immensely beneficial for everyone, not just those who wish to become professional software developers.
Let’s look a literacy for a second. We as a society decided reading, writing, and a collective literature should be vital elements of every citizen’s life, not because we want everyone to enter the “writing industry,” but because we recognize literacy as a rich form of expressing and sharing ideas. Writing lets you transmit an idea, but more importantly, we form a different kind of idea when we write, one that allows for rational argument,** Kind of like this essay you’re reading! possibly much bigger than could be expressed by speech alone. It’s wonderful some members of our society become professional writers, but literacy is important regardless of chosen career path.
Likewise, while some people learn programming to become professional software developers, its benefits should extend to everyone. Most of today’s “industrial” programming languages, like Swift, focus on computer resource management and algorithms: the “how” of programming. But, as Alan Kay says:** You may know Alan as one of the inventors of Smalltalk, which he did pursuing his Dynabook vision — essentially an iPad 40 years ago.
Computing is about systems, it’s not about algorithms. It’s not about the “if statement,” it’s about powerful ideas that are made into descriptions so that computers can interpret them. […]
It’s not to get a job — it’s because it raises the level of enlightenment and the kinds of ideas that can be represented.
If Apple wants a true vision for the future of computing, it needs to look beyond Xcode and beyond Swift.
Inspiration
The good news is, if you’re looking for inspiration on personal dynamic media, you need look no further than Apple’s own history for many great examples.** This SIGCHI paper details over a dozen creative tools from Apple’s former Education Research Group.
To be perfectly clear, I’m not recommending using any of these examples directly as they are, but I am suggesting learning from them. Let’s examine what made them powerful tools for thinking and creating, and imagine what they might be like if written for a 2016 era iPad.
The Vivarium project was…
a long-range research program which [used] children’s interest in the forms and behavior of living things to inspire a wide variety of exploratory designs in curriculum, user interface, computer inputs and outputs, and modelling of behavior. (Alan Kay, p1).
Predating Swift by over 20 years, the Vivarium project included a graphical programming environment called Playgrounds where students programmed complex biological ecosystems.** See also Larry Yaeger.
Kid Sim (which later became known as Cocoa** No, not that Cocoa.) was an environment where children…
create their own characters, and they create rules that specify how the characters are to behave and interact. KidSim is programmed by demonstration, so that users do not need to learn a conventional programming language or scripting language.
Interactive simulations, like games, were created mostly graphically, with some statements to help with logic.
HyperCard was a graphical programming environment for everyone. HyperCard took interface cues from the desktop publishing apps of the time, and allowed people to create programs by using drawing tools, or even by copying and pasting interface elements from different programs!
Programs were organized as stacks of cards, which were a mix of graphics and interactive elements like buttons.** The video game Myst was created in HyperCard. A beginner might start off just using cards from somebody else’s stack, but eventually they might like to customize an existing card, or even create their own.
None of the environments presented above would be considered “real programming” by most professional developers, but that’s kind of the point. This isn’t about visual programming vs plaintext programming, this is about programs to manage computer resources vs programs as representations of complex and dynamic thoughts.
These environments aren’t about learning to code and about producing apps, they’re about learning to think and about producing enlightenment.
Visions Matter
Compare the vision of computing as a personal dynamic medium with how Apple sees Swift: one sees programming as a medium for expressing powerful ideas, and the other sees programming as something for industry.
Xcode for iPad, be it Swift Playgrounds of a full IDE may very well be in the works and it may very well be what we get as Apple’s vision for how programs should be created in the future of computing. But why should we set our expectations, our demands, so low? Swift caters to industry, but what we should demand instead is programming that caters to everyone.