Skip to main content

The Xcode cliff

The Xcode cliff

/

Is Apple teaching kids to code, or just teaching them about code?

Share this story

Illustration by Alex Castro / The Verge

Swift Playgrounds is a wonderful introduction to programming. It introduces imperative logic, functions, methods, loops, and many of the marvelous APIs that are available to iOS developers.

But it’s called a “playground” for a reason: you can’t make an app with Swift Playgrounds. You play with code, you learn about code, and you do indeed code. But if you want to build something useful and distributable, you need to look elsewhere.

Some popular options are Codea, which allows you to build full apps in Lua on your iPad; Pythonista, which offers a Python IDE and a number of popular libraries to work with; and of course there’s always the cloud.

But inside the Apple ecosystem, this “elsewhere” is called Xcode. It’s a huge and complicated application that runs only on Macs, and requires an Apple Developer account to effectively distribute the software you build.

Swift Playgrounds’ penchant for hiding true complexity makes it hard to recommend

I probably wouldn’t recommend a kid learn Swift as their first programming language, not because it’s not a great and interesting language, but because the barrier to distribution and the creation of useful software is so high. The Xcode cliff is a steep one.

For instance, here’s what writing for ARKit in Swift Playgrounds looks like. Mostly you’re dealing with a few pre-written one-liners and a highly ergonomic API:

In contrast, here’s Apple’s introduction for developers on making an ARKit app in Xcode. It’s nested within Apple’s overall application framework, deals with SceneKit, and isn’t scared to inform you that vector math exists.

Does it seem difficult and complicated to you? That’s not because Apple did a bad job on ARKit, it’s because most software is difficult and complicated. Software involving 3D graphics is, if I had to give a ballpark estimate, like, 3x as difficult.

The Swift Playgrounds fantasy of what ARKit is like is closer to an ad than a tutorial. I’ve actually worked on an app using Apple’s ARKit and SceneKit APIs directly. I got stuck when my API call to Apple’s sound playback system wouldn’t work, despite all my best efforts at debugging. Writing software with Apple’s APIs is a powerful but difficult practice, and Swift Playgrounds’ penchant for hiding true complexity makes it hard to recommend for someone who doesn’t want to just “learn how to code” but instead wants to build something.

Apple would do its learners a huge service by providing them an Xcode equivalent on the iPad. Not because it would suddenly be easy to make applications and release them on the App Store, but because it would give iPad-bound learners a chance to engage that challenge and grow into true application developers in time.

Compare this situation to JavaScript. Anyone with access to a web browser can write JavaScript, even write useful JavaScript, and distribute it to everyone in the world. Combine that JavaScript with a small knowledge of HTML and CSS and you have a website, which is kind of like an “app” except that almost any device in the world can access it, and you don’t need Apple’s permission to publish it.

Companies like Facebook and Google, and countless open source contributers, offer free JavaScript libraries (the equivalent, in many ways, to Apple’s platform APIs) to help expand your capabilities beyond simple “vanilla” JavaScript. The best libraries rise to the top, often due to superior documentation, which usually attempts to explain complexity, not hide it.

Apps breed dependence

I’m not trying to denegrate apps or the iPad here. I love apps, and I love my iPad, and I use apps on my iPad all the time. Given a choice between a website and an app, I usually choose the app.

But apps breed dependence.

In the world of apps, if you have a problem you would like to solve, you search the App Store for the solution. A programmer’s approach is something like: I could write software to solve this problem. A user’s approach is more like: I could download and use software which solves this problem. Obviously, both approaches are valid and important — few, if any, programmers write all the software they use. But the user approach, if relied on entirely, is ultimately limiting.

I love Apple’s emphasis on education at its recent iPad announcement event. Obviously, Apple has a commercial interest in competing with Chromebooks for mind and marketshare in schools. But beyond the crass profit motive, learning is fun, and it’s beautiful, and it’s for everyone of all ages, and Apple’s unique perspective on using the iPad to make learning immersive and multisensory is great and laudable.

But you don’t just learn for the sake of learning. Learning is for doing, at least theoretically. And I’m worried that Apple’s penchant for safety rails, epitomized but not limited to the gap between Swift Playgrounds “learning” and Xcode “doing” seems stifling.

Here’s an illustration to help explain what I’m talking about: I wasn’t bad at math in high school. I generally understood the concepts on the blackboard. But my lack of attention to detail held me back in tests, and where my peers accelerated into calculus and beyond, I got stuck on advanced algebra concepts.

But math is so damn useful in the modern world. Want to write a video game? Oodles of math. Want to design complicated electronics? Hello, math. Want to crunch through numbers in a spreadsheet? Totes math. Want to understand advanced programming language theory? Welcome to math.

When I learned math, it was only learning, never doing. My only practical application of math was in a physics class, not a math class. But now I curse my ignorance every day. It holds back my understanding and utilization of so many things.

My fear is that a “learning” approach to coding, in absence of a “doing” application, will lead to students who get great grades at “programming” in school, instead of becoming great programmers in life.

Maybe I’m romanticising that struggle to learn

Maybe this is just my generational blindness: most professional programmers alive today obviously got their start before Swift Playgrounds was a thing. They tinkered on the Commodore 64 as a kid, they hacked their TI-83 in school, they built websites in PHP to earn some spare cash. Maybe I’m romanticizing that struggle to learn, and should be more grateful for slick new learning experiences like Swift Playgrounds. Or maybe I’m super right. Hard to tell.

One of the most influential programmers in the world right now is Sebastian McKenzie. He started a project called 6to5 as a high schooler in a remote Australian town. 6to5, later renamed Babel, translates JavaScript written with modern features and modern syntax into JavaScript that can run on older browsers. Nowadays it’s almost a given that any new JavaScript project will rely on Babel in some way. Millions of developers use McKenzie’s code every day.

Sebastian started the project, in his own words, to “learn” more about JavaScript. Now he works for Facebook. Here’s one of the computers he got his start on:

I, for one, am grateful that Sebastian wasn’t “learning” on an iPad.