Using the iPad for: Web Development

I wrote previously about how I write blog posts and deploy my (statically-generated) site using an iPad. That article also covers how I stage the site; i.e. create a temporary test version of it while I make edits, to check how everything looks before I actually update the main site.

That’s all well and good for writing articles, but periodically I make tweaks to the site’s appearance, design, and structure. While I could certainly do so using the workflow I described in the aforementioned piece, there are better options available — without leaving the iPad.

My tool of choice for web work is Coda, and it’s worthy of your attention. It’s a programmer’s text editor, a terminal with SSH, a preview browser, and an interactive JavaScript environment/console in one. It can edit files on a remote server directly, over a secure connection. It can keep your SSH passwords or keys on your iPad, encrypted, with the app protected by its own passcode (and Touch ID). It can handle multiple sites too. It can even keep working copies of sites, for local editing and then remote sync/update later.

Here are screenshots of a terminal tab, and a preview browser tab too.

It has snippets, code-completion, dual local/remote file browsers, Markdown support and live reloading for previews, and it works on the iPhone as well as the iPad. It also talks to its Mac counterpart, as you’d expect. Pretty good. The one thing it doesn’t yet do is support Dropbox as a local file store, which I’d really like — but my specific setup sort of obviates the need for it (I have Dropbox on my server too). Panic, Coda’s makers, have said they’re considering it.

So far, so good. The two things I need to do during/after tweaking the site, though, are checking responsiveness on various screen sizes and devices, and browser testing in something other than Safari. The iPad essentially only runs Safari (unlike on the desktop, even the iOS version of Firefox uses WebKit, and the iOS version of Chrome uses Safari’s own variant of WebKit, not Chromium’s). Thus, your options are: use a desktop computer with some browsers (and virtual machines, for browsers on other operating systems), or use an online remote browser testing service. There are lots of those services, some free (usually static screenshots, in a queue), and some quite expensive (which pretty much let you VNC into a freshly-spun-up VM), and you can find them yourself by searching online for “browser testing”. I haven’t checked which ones work via Safari on iOS yet.

Responsive testing, though, is something you actually can do on the iPad, up to a point, with Web Tools. It lets you resize the viewport, or choose from a set of popular device sizes, and it also has a rudimentary built-in web inspector with DOM tree and editable CSS attributes (and a JavaScript console, as an in-app purchase). It’s basic, but you can readily use it to see how your site responds as the browser window resizes, or on different screen sizes than your own. I think there’s a big opportunity here for iOS app developers to create something a bit more full-featured.

Lastly, you can also grab the incredibly-customisable iCab for iOS, which can spoof user-agents, and which includes Firebug Lite.

With so many validators, references, code samples, and in-browser testing services available online now, you can do a hell of a lot without recourse to a desktop machine. I’ve made CSS and template changes to the site in the last week, and all entirely from my iPad.

There’s also Adobe Comp, Autodesk Graphic, OmniGraffle, Pixelmator and more for site design and graphics work. We’ll talk about that stuff in a future instalment. You can keep up to date with new articles by following me on Twitter.

Thanks for reading, and I’ll see you again next time.