Coding on an iPad

I wanted to see if I could make my iPad Mini into a reasonable coding environment for an upcoming road trip. Most of the posts I found about iPad coding were from 2010–2012, and described a set of development apps that were nearly all now unsupported or in two-star rating territory. After much experimentation, it turns out a few newer apps make the iPad into a pretty good development setup, even for something like Go where I expected support to be the worst. You still need a remote shell for building and testing, since iOS forbids compilers, but even that is a fairly reasonable step at this point.

A recent tipping point seems to have been iOS 8's “document provider” extension concept, which lets one app — say, a text editor — interact with a document provided by another app — like a git client. At the end of last year, a new iOS git client, Working Copy by Anders Borum, put this feature to use for developers, and coding on an iPad became a lot more practical. While no one app provides everything you need, iOS 8's extensions seem to make it much more possible for a few smaller apps to work well together towards a larger purpose.

Yesterday I tweeted about coding this way, and heard from a couple of other people who use the same setup:

Apps you’ll need (or want)

To make an iPad work well for development, there are four apps you’ll either need or very likely want (all links go to the App Store):

• The aforementioned Working Copy, which is a git client that supports Github and Bitbucket repos.
• As a code editor, Textastic won out for me — while it offers only limited code completion (for PHP, HTML, and a few others), it does syntax highlighting for almost any language.
• Since iOS doesn’t allow compilers, Panic’s Prompt 2 is needed to build, test, or run code.
• While it’s not absolutely needed, Panic’s Transmit makes uploading for build and test a lot easier.

Note that Prompt and Transmit are sold as a bundle for a slight discount.

Update: Justin Weiss also recommends Dash for iOS, for local documentation lookups.

Getting set up

Working Copy doesn’t have a very intuitive UI, but if you start with Settings -> SSH Keys -> Connect With Github, you’ll be prompted to log in. Clone a repo you want to edit.

Working Copy, set up and ready to go.

Next, head over to Textastic. You’ll do your editing here (preferably with a Bluetooth keyboard, but it works either way). From the main file picker pane, choose “Open…” The first time through, you’ll have to choose “More” at the bottom, then enable “Working Copy.” Click “Done” and then choose Working Copy from the popover.

Importing a document from Working Copy to Textastic for editing.

You’ll see a list of repos and files that Working Copy knows about. Choose the file you want to edit.

The nice thing here is that while you edit in Textastic, Working Copy still owns the document, and notices any changes you make. You don’t have to push them back into Working Copy — when you switch apps, your changes will already be in your local clone.

There are two disadvantages, though: you can only have one “External Storage Provider” file open at a time, and for those files, you can’t use Textastic’s file upload tools, like SFTP, to copy the file to a remote shell for building and testing. Fortunately, there is a “Recent Files” menu at the top left which makes switching between files fast. For upload, I’ve turned to Transmit instead, using the “Open In…” option of the sharing menu.

First choose “Open In..” from the Sharing menu, then choose “Transmit” to upload your file.

In Transmit, as well as in Prompt, you can set up a new server definition with your project directory as the default on startup. In Transmit, use the “Root Path” field to set the project directory, and in Prompt, use the “Startup Command” Server Setting to `cd` to the project directory on login. In both cases, name the Server config for the project, instead of the host, so you can jump between multiple projects more quickly.

Uploading a source file to a project directory.

Transmit unfortunately requires quite a few taps to upload, especially after the initial upload — I count six taps to upload a file. Uploading multiple files this way isn’t practical at all, but if you’re mostly developing in a single file for a while, it works.

Unfortunately there’s no way to skip the overwrite confirmation step.

From here, it’s easy to switch into Prompt and do whatever build and testing you want.

For a few compile and run commands, Prompt is painless; for, say, Emacs, it’s not very practical.

Assuming everything is working, head back to Working Copy to commit and push your changes.

Tap the “Push” button in the upper right, then the “Commit” button, to do both of those at once.

That’s all there is to it. One useful thing to remember is that a four-finger swipe left or right will move between recent apps; I find myself swiping between Textastic, Prompt, and Working Copy very easily.

I’ll still prefer a laptop for development most of the time, but when space is limited and a long-lived battery is needed, developing on an iPad has gotten to the point that it’s really fun. All of these apps run on iPhone, too, so if you really want to save on space, you can.