Web dev options on an iPad (2017)

14 min readJan 2, 2018

Be sure to check out the 2020 version of this article (there is also a 2019 and 2018 version).

Can you be a web developer with an iPad?

Sure, on one hand it’s a powerful internet connected device with an app store full of text editors. Do a bit of CSS here, a dab of JS there, upload and hey presto.

On there other hand as a professional front-end web-dev, putting down my MacBook Pro with its IDEs, Node servers, pipelines, package managers and source control and jumping on an iPad is just not possible.

Here’s the twist. I have no long term iPad Pro web-dev experience to offer you. But I’m asking you to join me in my trying to understand how it works and if I should spend my own money on an iPad Pro. Could I possibly justify it as second dev box as well as a my couch connection to the internet?

The iPad finally feels like a platform on the brink. The iPad Pro benchmarks faster than the latest MacBook i5 for 40% less cost (including the same 256GB storage). Add to that the small matter of 120Hz/P3 gamut displays, touch/pen input and built-in cellular options…

Of course, this doesn’t tell the whole story. Although based on a UNIX core and with much of the familiarity of OSX, iOS — and especially third party apps — are very restrictive. Saving files from one app and opening them in another is not straight forward, let alone curl-ing down and running a command line app. To it’s credit, iOS11 has brought new workflows and file finder options, and there’s some hope for more dev related workflows with the app store possibly allowing executable third-party code.

But this is all just tech-spec hand-waving. The question is not “can” your do web-dev on an iPad. The question is really “would you want to?”. Even if my workday continues on the MacBook, can I work with an iPad the rest of the time — and enjoy it? How would that work in practice?

What do we want?

Lets break down what I do as a front-end dev, and hence, what I want:

I need to pull and commit to a remote repository that I share with my team.
I need to edit HTML, CSS, SASS, JS, JSON with minimal idiotic errors.
I need that code to compile and run on a web server
I need to browse and debug those served pages.
I need to work with my team through Slack, Jira, Basecamp, Google Docs.

This is how that looks (if you squint), we have one remote server hosting the repo, but all the real work is carried out on the Mac.

Option 1: The local server

If we replicate this on an iPad, we get quite a long way. We can use the Working Copy app for Git, an editor like Textastic or Coda, basic browser debugging tools like MIHTool or Inspect, plus access to all the normal collaboration tools via app or web-app:

Translating that workflow directly to an iPad

The obvious missing piece is running any sort of compilation or server on the iPad. We need an app to create an environment that can access the files checked-out in Working Copy, run node and install node modules from NPM, run a gulp pipeline (or webpack, etc), and allow an HTTP server to be addressable by other iPad apps. If some one could get on that small task, we’d appreciate it…

Admitting that option 1 is currently not possible

In the meantime, what can we do? The answer is to off-board the missing pieces, to move them to the cloud. This is often using a virtual private server (VPS), and services such as AWS, Digital Ocean, Zeit or others are often mentioned. But any server instance you can use to run node (or ruby, etc) will do, inside or outside your business VPN. We can then edit on the iPad, push to the VPS, test back on the iPad and commit to our git repo. Sweet.

But let’s not kid ourself, this is a compromise. The mere mention of moving work to the cloud is often assumed to be a natural progression. But here it just introduces latency, takes away offline working, adds an extra price tag (VPS cost, cellular cost) and most importantly adds another cog in the machine that needs maintainance. This all equals frustration and friction against getting work done. Minimising this is the priority.

So here are the workflow patterns I could possibly use with a VPS:

Option 2: The cloud upload

This is the most obvious route. Working Copy checks out code and it’s worked on locally on the iPad, before being uploaded to the VPS. The VPS fills the previous hole by being a node server and gulp pipeline that watches for the updated files, processing and serving them. Then we debug the results on the iPad.

It sounds simple, but we need to get a few kinks ironed out. Joining up the app sandboxes on the iPad is the first step. The text editor apps need to edit the files downloaded with Working Copy, which provides a few possible access routes:

The first is a file provider extension, which means that Working Copy appears in the Files app (and compatible apps) as an addressable file system. Textastic is one of these apps, and this is simplest and most robust route.
Alternatively, Working Copy can start a webDAV server which other apps can hook into (Coda 2 can use this method, for instance). This looks and feels like a regular filesystem to the editor, with one exception — iOS is ruthless at cutting background processes, so five minutes into editing a file you get a message that the webDAV server has shut down and you need to re-enable it again. The way around this is to keep Working Copy in the foreground by docking it at the side of the screen — but you’ll have to accept the compromise of less screen space for your editor (and my old iPad mini 2 won’t even support two concurrent apps, so this is based on a hunch).
The last method is to copy the files from Working Copy into your file editor, but the thought of dealing with multiple versions of files on the local environment — not even including a VPS and a repo — seems insane.

So now we’re editing and saving files locally. Next step is to get those up to the VPS, by sFTP, SSH, or another method. We could use another app (Like Panic Transmit) to upload them, but most good editor apps have built in methods to connect and synk local files with a remote server. Coda’s implementation is possibly the simplest (love that green tick button), but Textastic isn’t too far behind.

So the files are now on the VPS, and I’m leaving all the set-up to process and serve the files up to your skillset. I’d use a terminal app like Panic Prompt to npm install the project, run gulp and assume that the watch processes are doing their job when I upload a new file.

Now the last step — viewing and debugging the results. Safari has no devtools built-in until you plug the iPad into a Mac (negating the whole point of this exercise). Chrome for iOS also doesn’t have it’s excellent devtools, probably due to a combination of appstore rules and having to use Apple’s iOS flavour webkit, not blink, as it’s underlying engine. We have to look elsewhere. A quick fix is the Firebug Lite (or the MIHTools Safari extension, which appears to be the same thing), although it’s support has been ended and it was never designed for touch devices. MIHTool is often mentioned, but I’m more fond of Inspect, which feels more solid, less a hotch-potch of OSS code and has excellent responsive design tools. I’m not going to get the level of feedback I would expect on my MacBook with all it’s tools, but as a second dev environment, it’s enough to get 80% of my work done.

Option 3: The Github push

This is a varition on the above that is sometimes mentioned. It’s clever in that it in theory removes a step from a cycle by getting GitHub to push code to the VPS when anything is pushed to GitHub, so you don’t need an upload step (but you will need to configure the GitHub webhook to trigger an action). It doesn’t really work for me because I want to test before I commit any code, not after. Oh, and our projects are not on Github. But it might work for you.

Option 4: Save direct to cloud

This is a variation that also removes the upload step, by never checking-out files to the iPad in the first place. Instead, you open and save the files directly on the VPS through the editor app’s remote file connection interface (sFTP/SSH, etc). The upshot of this is that you’ll need to do your git work on the VPS too, probably doing commits, pulls and pushes via the command line on a terminal app that is connected to the VPS.

Option 5: The CLI terminal

This option is the natural extension of the previous option by continuing to move everything to the cloud, including the editor (eg VIM). The only things you’d need on the iPad are a terminal app and a browser/inspector to see the results. It’s an interesting idea and the simplicity will appeal to a large slice of developers that come from the CS side. But not me — even if I learnt VIM and brushed up on CLI git, it feels anachronistic on this platform, I might as well be on a VAX terminal (sorry).

Building a better workflow:

All this chat amounts to finding ways around the tricky bits. But the future of web dev on iOS doesn’t need to be like this.

We need someone to convince Apple that the Section 3.3.2 of the Appstore guidelines (about downloading and running executable code) can make the “Pro” in iPad Pro true for a whole new industry. And someone with the courage to build an app that makes a local node-based dev environment that (with hooks into working city and editors) a reality.
Coda is a huge achievement that tries to satisfy thousands of developers who have hundreds of differing workflows. What I’m saying is that the compromise doesn’t wholly work for me — yet. The most important improvement I want is it to hook into Working Copy’s file provider without needing a webDAV client. Secondly, I appreciate the file stystem UI is probably meant for an iPhone, but on the iPad I’d really like a “left column file-list, right column editor” layout that you find everywhere else. Lastly, Coda is the one and only editor I’ve found with auto suggest, but it’s pretty broad— If I type the CSS property flex-direction, it would be nice that it typing “C” would suggest “column”, and not offer me “capitalize”.
I think Textastic could do with a horizontal tab interface like Coda’s, when I’m working on modular components, I want easy access to the markup, CSS and JS, and given the screen size of an iPad, tabs are the only logical way to do that.
Google Chrome (or even Mozilla) could win over all developers on iPads (or Android tablets) with a meaningful subset of it’s devtools.
Linting, for both JS and CSS. And that naturally leads to the question of extending editors with third party extensions. I know this falls foul of appstore rules, and I’m not clear if the Section 3.3.2 clarification changes that, but to justify the pro badge in any creative endeavour that includes coders, a mechanism to customise your toolset needs to exist.

Hardware

One thing we haven’t talked about is the device itself.

The iPad range gives lots of options, but I’m gravitating — probably unsurprisingly — towards a 10.5" pro. The regular iPad could certainly do the job, but that 50% extra benchmarked speed (read longevity) helps enormously. To put it into perspective, I’ve been doing this app research on my 2012 iPad mini 2 and overall it’s ok when it comes to speed, for example, syntax highlighting large files results in a visible wait, but not embarrassingly long. A 2017 iPad Pro is at least three times the speed of my aged iPad. If an iPad Pro could feel usable after another 5 years like my iPad Mini 2, I’d be more than happy to pay the extra over a regular iPad. Plus, like I said before, it benchmarks higher than the more expensive MacBook i5, which makes it seem a relative bargain, despite being an expensive iPad.

The marginally larger screen of the 10.5 and the good speakers, not to mention pen input (for notes, if nothing else) swing it.

On the other hand the iPad Pro 12.9" would definitely improve productivity and promote less app switching, but I don’t believe the increased weight and awkwardness would be a fair trade off – this is not meant to be my primary (ie only) dev machine after all, but a couch surfer that I can also transform into a reasonable dev environment. At least until iOS is ready to prove that “Pro” moniker.

After having two iPads in the past with a cellular connection and barely ever using it, I can’t believe I’m thinking of doing it again, but the VPS workflow and the reasonable cost of PAYG data here in Sweden might just convince me.

More interesting to me is the hardware keyboard. It’s a must as anyone will tell you after they have opened an editor app and seen the soft keyboard take over 70% of the screen.

The apple smart keyboard doesn’t really appeal to me, it’s incredibly light and thin-ish, but that doesn’t seem to justify the ZX Spectrum keys, or the weird origami flip manuevre you have to learn every time you open/close it. Add to that the unlit keycaps (Sweden is dark) and inability to use it on your lap, and I start to think I was never the target audience. Maybe if hyper portability was the number one priority.

I’m pretty sold on the Brydge keyboard range. The mini MacBook look, the function keys, the balance (to stop tipping it actually needs to be just slightly heavier than the iPad) and adjustable hinge all seem right. Trying to make the iPad into a MacBook felt like a conflict, until I realised the keyboard would be needed whatever it looked like, and the benefit of not being in a shell would be that I could rip it off and be back to a real iPad experience (and weight) in microseconds. And that flipping to iPad-only mode justifies the extra weight in the bag for me.

Investigations lead to some disturbing reviews of missing taps, but the optimist in me hopes that was early production problems as later reviews don’t mention it much. And now that iOS focuses on gestures that swipe up from the bottom there screen, hiding the bottom edge the screen on the brydge seemed problematic, until you realise that both getting into control centre and revealing the dock can be done with simple keyboard commands (home key double tap, and apple-alt-D).

This transformational quality of a keyboard is really starting to appeal to me. I just wonder if I should get the Nordic layout like on my work laptop. I know I really need to, but it must be pretty cramped with those three extra letters in a sub-size keyboard.

List of apps talked mentioned here (and a few more):

Working Copy
This is the hub. It’s a fairly fully featured git client tailored to iOS, and the developer is obviously commited to not just ticking the boxes, but to leveraging iOS’ latest features to provide a genuine dev workflow.
Coda
An iOS version of the popular Mac IDE from Panic. It has tabs, previews, terminals, playground, outstanding upload tools and a solid IDE. The UI and functionality is deeper than at first appearence (I recommend their tutorials), and it works best if you build flat sites without pipelines/compilers, but it’s a serious iOS app, not just a cross port.
Textastic
The current favourite amongst pioneer iOS web devs, mainly because it doesn’t try to achieve all the things that Coda does, but instead sticks to being a sublime/atom like app that can save to the cloud. The close integration with Working Copy also helps.
MIHTool
The swiss army tool of debugging a web page. What it lacks in polish it makes up in features. Love the paint and composite rects.
Inspect
Solid web developer’s browser tool with ways to inspect DOM and style, console and responsive design. For DOM inspection, I prefer it over MIHTool.
Firebug lite
A basic javascript version of the grandaddy of all web devtools, Firebug. Firebug is no longer supported as a project, but the Lite JS is still the do-all bookmarklet you can drop into any browser, even on iOS. But, it’s definitely not built with touch targets in mind — it’s not easy to use.
Ergo web tools
Lots of potential — it’s almost like a more beautiful version of Inspect, but hasn’t so far quite got all the latter’s features.
Prompt
The terminal app from Panic — a more fully featured version of the terminal in Coda.
Transmit
Completing the triumvirate of apps from Panic, this is the iOS version of the venerable Mac FTP client. A cut-down version is integrated into Coda, but if you really want to start messing around in sFTP servers, this is what you need.
Slack
I mention this app because it’s so crucial to our workflow. It’s very close the desktop version (mostly in that it’s based on the webview), but one important difference we’ve noted is that it can do an audio call, but not a video one. At least not yet.

Epilogue

I think I’ve almost justified the first step of buying an iPad Pro, pen and keyboard to see if all this conjecture works (assuming I don’t wait for v2 with the A11X). I’ll keep you updated with the verdict on if I can make it work for me.

But I do think this is just an intermediate step. All the movement with the App Store rules, iOS11 features and even just the “Pro” moniker makes it clear that workflows like mine might not need kludgy workarounds in a year’s time. My Mac certainly won’t be disappearing from my life any time soon, but the iPad is rising as a pro platform.