The new iPad Pro is out and the review are pretty consistent. The hardware is amazing, but held back by the limitations of the software, and that software limitation prevents certain workflows from being viable. Every year that list seems to get a little shorter; Dom Esposito was able to produce his iPad Pro review for YouTube on it (in 4K, no less), Shawn Blanc is doing production photography work on an iPad and a Leica camera, and of course there’s Federico Viticci’s ever-evolving list of workflows to get the most out of the iPad’s multitasking capabilities. With Apple’s silicon team doing some of the best work in the industry, and with GeekBench scores rivaling laptops in bursts, it’s not hard to see why people want to replace desktops with these things; I’ve argued for three years (to the day, apparently) that the iPad Pro needs Xcode.
But there is one type of workflow that, for 8 years, has been difficult to hit on an iPad. Building software.
You don’t want to be limited by the availability of pre-programmed cartridges. You’ll want a computer, like Apple, that you can also program yourself.
Apple print ad, 1978
In many ways, this is a foundational part of the definition of a computer. Apple’s said as much in their ads. The Macintosh has always been an open, developer-friendly platform. And Apple has an excellent and compatible web engine in WebKit that developers can run web apps on. Apple’s history was one that helped small and large companies build Macintosh software, and with Cocoa helped many new developers (including me) build amazing apps for its general purpose computers. But in 2018, it’s an unsolved problem on iPads, one that is viable on competitor tablets like Microsoft’s Surface line and Google’s Pixel tablets. What’s holding it back?
When the iPad launched in 2010, it followed the iPhone’s lead as a locked-down platform where third party apps were limited by Apple to those that met the standards of the App Store Review Guidelines. This document has been evolving every now and then as new types of apps launch, such as setting the standards for cryptocurrency apps. Along with the guidelines that specify what you can build, Apple has published SDKs that developers use to build iPad apps that inform how apps can be built. In many ways, the review guidelines and the limitations of the SDKs prevent developer tools from really existing that would enable building most software.
On desktop, developers use a variety of tools to build software, but many of them share some common types of features.
- Typically you want to fetch code from a source code repository, often (but not always!) using Git, and store a copy of it on your device. Usually this involves security credentials like an SSH key. Once you make changes, you need to clean them up, commit them, and push them. And fix whatever merge conflict chaos you’ve created.
- Once you have the code, you need to make changes to it, often with context-aware editors that change based on what’s being edited. For mobile apps, websites, or servers, this might be a text editor with syntax highlighting or code completion. User interface design might involve a visual layout editor. Game development might involve multiple views of a scene.
- After making changes, you need to test them. With mobile apps/games and websites, this means launching to a device emulator, onto another test device, or onto the iPad itself. There’s also server software which might not have a UI at all, but instead run as a Node.js service or a Docker container.
- Once it’s running, it will break, so being able to poke at why is crucial. Setting breakpoints and variable watchpoints, inspecting the web page, intercepting network traffic, and logging are all essential tools. The more tightly you integrate these into the editor, the more productive you can be; web developers who have live reload can rapidly iterate on changes without spending minutes rebuilding are able to work far faster and stay in the zone much more easily.
- Software needs to be packaged and distributed, whether that’s with compilers, bundlers, or just plain old zip or rsync. Sometimes that comes in a monolithic system like Xcode or Unity, and sometimes it’s an interlocking set of parts like, such as having TypeScript + Babel + Webpack with a pile of loaders.
As it stands, some of these pieces do exist today on iPad. Working Copy is a wonderful app for working with Git. Textastic helps when highlighting and editing code. MIHTool lets you inspect web pages (though arguably this should be built into Safari). But some of these aren’t doable by developers, and cannot be, because of limitations in the iPad SDK and the App Review guidelines.
- Developers cannot spawn subprocesses. This affects interpreted developer tools like Node.js or Python, and compiled languages like Swift or Go. It also means that an iPad cannot build other iPad apps and then run the built app. Even if there was some way to do all of this inside of a single executable, you’d have a single process and a single memory space, which would make developer tools either very crash-prone or very slow.
- iPad apps are largely monolithic, which certainly fit some apps, but many existing developer tools are designed around smaller interlocked pieces, which makes porting more complicated.
- Apps are limited in how much they can communicate with each other, especially with files. Most file interactions need to be UI driven, which gets very tedious for lots of files.
- Apple’s review guidelines say they reject apps that download and execute code. There are some hints that this is relaxing, but it’s difficult to invest time and money into a platform if you don’t know how the rules will be interpreted against you.
As an aside, some people are building developer workflows that bypass some of these limits for certain types of programming by using a Virtual Private Server, or VPS, which is basically a Linux virtual machine running in the cloud somewhere. For $5 or $10 a month you basically have a small Linux server that can run whatever you want on it, and coupled with an app like Prompt or an SFTP app, it can make a lot of web and server work viable. Of course, the iPad here is more of a dumb terminal connected to a mainframe, which means there is extra latency and bandwidth involved, and you won’t necessarily be able to work in places that don’t have Wi-Fi (or LTE if you get the cellular iPad). But if that’s all you need and you don’t care about the philosophical discussion of what “real” computers do, and aren’t afraid of the command line, then it appears that this works for front-end web development and server stuff.
For me, I’d like more of an integrated experience. I’m not trying to get the iPad out of the way; it would be fantastic to have a touch-powered developer machine, and if you’re just dropping down to command line tools, you might as well pick up a cheap Chromebook. If you can edit photos and videos and podcasts on an iPad with a first-class touch-driven experience, why not source code?
At the time that Xcode came out, the world was lost in a sea of confusing Java tools that were crammed full of a thousand features that nobody used. Apple changed how IDEs should look and work in the 2000s. In recent years we’ve seen a resurgence of developer tools like Visual Studio Code and Atom that are trying to redefine how developers build software for the next decade. Apple can do it here, but they need to commit and support developer workflows beyond just their own platforms. The iPad is a pro computer; if a developer wants to build something for another platform, an iPad should be able to do it. If a Mac can build Android apps, there should be no technical or policy reason that an iPad can’t. Otherwise it’s never going to shake the “not for real work” meme that haunts the iPad 8 years after its launch.
Apple is in the unique position to recreate the developer experience not just for a new device or a new interface, but for an entire new generation of developers who will never know what editing on a PC was like. Until that happens, an iPad will never be a suitable work machine for the 20 million registered developers they brag about, and the countless millions building web apps, servers, games, and more. But when it does happen, that will be an exciting day for all of us who make software.