FE webdev on iPad Pro (2018)
A deep dive on iPad productivity.
Be sure to check out the 2020 version of this article (there is also a 2019 version).
Could I recommend using an iPad as a good platform for doing front-end web development?
No.
Unless you build within a narrow style of projects, almost certainly not – or at least not yet.
So why add the proviso? What really pushes me back to my MacBook & what can you successfully get away with on iOS?
My productivity varies wildly depending on what type of project I’m working on, and I’d represent the differences in two diagrams.
The first diagram is about the many methods you can use to build front-end web projects and how suited the iPad is to build them, considering that editing and running the code (ie, compiling and running a development web server) are quite separate issues on iOS. The thickness of the bars is to represent how common these types of projects are; presenting a fun little side project on glitch.com as having parity with an 8 hour-a-day/5 days-a-week day job just seemed dishonest.
If you’re building a site in a “flat” method (ie, with HTML/CSS/JS) you can get quite a long way on an iPad alone, either with preview servers or uploading to a Virtual Private Server (VPS). If your workflow needs compilation (ie, GULP, Webpack, etc), you’ll need to have a VPS somewhere online to run the tooling & server. Next are JAMstack style services where you upload templates and content and then something like Netlify, GitHub pages or GitHub webhooks does the rest for you. The last type of work is where you work all online, either within the browsers, in the terminal, or sometimes with a companion app (eg Codeanywhere).
The second graph is about the the client-side dev tools. Essentially the more you rely on dev tools, the more frustrated you’ll be on an iPad. There are lots of half-measures and narrow scenarios that are doable, but otherwise it’s just not a great experience. You could draw the same graph if you currently need to do lots of graphics work, although this area is improving rapidly (1).
So what are the blockers, and how do you get around them?
Blocker 1 – importing or sharing files across apps
I’ve already posted about the messy landscape of options for moving and accessing files in iOS. The only way apps should be doing it currently is with iOS 11 style file APIs, but many apps have either legacy file solutions, bespoke (ie, confusingly different — and differently-abled) file pickers or would rather pull you into their own cloud platform.
The disparity in ways that file selection is presented or obstructed in apps is bewildering and frustrating. It forces me to become the expert on file picker UI and capabilities from app to app — time consuming, pointless knowledge that should be learnt once at a platform level.
Of the legacy methods; copying/sharing from iTunes is prehistoric, duplicating files between apps is barbaric, and sharing files between apps with WebDAV is soporific. If you have better options, use them.
Many apps offer some specific integration with a cloud service — some to widen your options, others to steer you to their own eco-system (Dropbox, iCloud, Google Drive, OneDrive, Adobe Creative Cloud). Other apps give you access to sFTP or such. These are fine options if your workflow can be based within these remote services, you enjoy editing directly on production servers or you survive life outside of a source control system.
But like most webdevs, git is the start of all my workflows. A few editor apps can hook into cloud providers like GitHub or BitBucket and there are several git client apps available. But seriously, give yourself a break and just download and learn Working Copy. Thank me later.
Working Copy is pretty much the role model for how I’d like any pro iOS app to fit into a workflow. It fully supports iOS file APIs, so the repos you clone into it are available through the file app and to any app that properly supports the modern iOS file picker (eg Textastic). No hacks, no funny handshakes to pass files between apps. Accept no substitute.
NB: Through this article, I’ll be including videos to illustrate different aspects of workflows. I’ve labelled them “recipes”, because you shouldn’t take them as the best way to do something, but as a way to decide what is important for you so that you can construct your own workflow.
The ideal fix
Apple need to evangelise the right way to do this before basic file management turns off the potential users before they get to the inspiring parts of iPad usage. But to really make it work, app developers need assistance to update older apps to the latest APIs. Many app devs spent huge amounts of time building custom solutions before any good options existed, only to see little in terms of revenue to encourage them to rewrite their app as new APIs came along. The iPad Pro marketplace needs to be turning a corner in terms of viability to bring these apps back into the modern iOS world.
Oh, and file renaming plus column view in file.app. Please.
Blocker 2 – Not being able to run any Node tooling
Modern front-end tooling is a constantly evolving behemoth. Whether you’re into webpack, gulp, roll-up or the next big node-based thing, it’s all about compiling code with tooling.
If you’re looking to run any of these locally on an iPad, you’re simply out of luck. If you are in a PHP or Python world you have some limited options (DraftCode & Pythonista), and if you want to build a basic Node app you might get get away with Touch Code Pro (or online services like glitch.com). But for us front-end devs, trying to build a design system on top of compiled/transpiled code – no dice.
Running your pipeline or stack off-board on a VPS (virtual private server) of some type is currently your best option, and there are some great resources about how you might want to do that. I’ve tried it and it can feel pretty smooth – once it’s all set up. But I’d unsubscribe from vultr.com in a heartbeat if I could just npm install by some method on an iPad.
The alternative is to build “flat”. No compilation, no helpers, just HTML, CSS and JS. When I’ve had the option, I’ve found it rather liberating to dispense with the endless tooling. You can get a local flat file web server running on iOS in a number of ways, although pretty much all of them have their downsides.
The ideal fix:
Apple is never going to give you command line access to the Unix underpinnings of iOS so that you can brew install node, so get over that. What would be possible – in theory – is a first or third party app that runs a node environment in its own sandbox, with NPM, local web server and iOS files picker on the top to allow direct access to cloned git repos. That doesn’t appear to be too far from what a Node IDE app like Touch Code Pro does today. Someone, please, pretty, pretty please.
Blocker 3 – Background operation timeouts
If you’re attempting to run a local server or a VPS SSH session, you’ll quickly run into the next problem. iOS is ruthless at killing background processes. Most categories of third party background processes are killed after 3 mins unless they come to the foreground again, meaning you might start your web server or VPS session, do a bit of HTML hacking in an editor, try and view the results in Safari and – ugh – the server isn’t running any more.
The workable solutions revolve around one of two possibilities:
- Finding a limited suite of apps (up to two, or three if you like working in cramped spaces) that you can keep in the foreground, so there are no background processes to timeout.
- Resigning yourself to the possibility of the timeout, and instead trying to minimise both it’s frequency and the disruption when it inevitably happens.
The ideal fix
It’s not rocket science – iOS needs more categories of background process that can remain without being killed after a short period. Memory and CPU are in no way the constraints they used to be on iOS hardware, so a more flexible background process policy should be up for discussion, as long as the battery is not gasping and the memory is capped at a reasonable level.
Blocker 4 – A lack of good client-side dev tools
The thing that really is the final nail in the coffin for me is client-side debugging. Good web apps live or die by how good browser dev tools are these days, it’s as simple as that. Desktop versions of Chrome, Firefox, Safari and Edge all have solid dev tools that are by-and-large comparable in functionality.
But on iOS, there are no dev tools in the one and only browser engine (webkit) unless you attach a cable to your Mac and remotely debug your window with the full Safari/MacOS dev tools.
Third party apps exist specifically to fill this gap such as Inspect Browser, Webtools & MIH Tools. But they’re far from providing a comparable iOS substitute for desktop dev tools, at least so far.
Inspect Browser is close in several areas. In particular it now has an excellent DOM inspector that allows tapping an element to inspect it and CSS rule editing (yay). It’s responsive design tools are good and I even noticed a loading time indicator, so maybe performance tools are in the pipeline. The console logging is one of the better ones, it parses JS objects in logs and also shows logs in webworker threads. But in some of my webapps I rely a lot on logging, I need to filter log messages down and colour them.
When I wrote a similar article a year ago, Webtools was the pretty one of the batch, it has a neat professional design that belies that fact that it’s DOM inspector has fallen behind the functionality of Inspect Browser, plus it has an in-app payment for a console function that so far has proved next to useless to me.
On the other hand, MIH Tools is a disjointed toolbox of powerful functionality in an app design that only a dev could love, but it has proved just too buggy to be of much use to me. Most of the time I have to uninstall and reinstall it just to stop it launching with a totally black screen (before crashing 30 seconds later). Maybe that’s a 10'5" Pro thing.
Many text editors that have their own preview/browsing features also have consoles, but they’re not terribly useful away from casual use (Working Copy’s is the best, Coda comes close).
What I really need is a good DOM inspector/editor and a great console on first page load and every reload. That rules out any Safari/iOS sharesheet extension – like the one MIH Tools installs – which you can only activate after a page has loaded.
And this is just the entry price of web app debugging. It’s before we get into adding breakpoints and performance analysis – both a regular part of my toolbox on my Mac.
In search of good console logging, I actually found that Firebug Lite (a JS version of the daddy of all web dev tools) was a good option for me. Firebug Lite hasn’t been updated in 10 years, but it’s creaky javascript still matched all the “native” console log apps on iOS in terms of usable functionality, and was clearly better than them after I hacked it around to be a bit more touch-interface friendly, and to add a few more modern features (multi-line logs, coloured logs, dark mode).
The problem with Firebug Lite is not simply that it’s JS trying to debug JS (not ideal), but that it’s ten year old JS that is supposed to help me debug my flaky ES6 JS. That’s crazy, and it does not add up to a reliable narrator to debug your web apps. The last drawback is that it’s console will only log on the main thread, so any webworker/serviceworker logging is no-go.
The ideal fix:
Safari on iOS could have a dev tools panel (revealed by a gesture?), ported across from the Mac. Or the third party apps like Inspect Browser, WebTools and MIH Tools could get a lot better. Or — in a crazy world — Apple could finally open up the browser engine options to third parties and we could start seeing full native Chrome or Firefox, plus their dev tools, appear on iOS.
Bonus blocker – No multi-file search
This problem is simply weird. Most of the editors on iPad are pretty solid apps when it comes to basic functionality, and yet none seem to have multi-file search and replace. Why is this common functionality in every desktop editor, but absent in all iOS editors?
The only app I’ve found so far that does have multi-file search (but not multi-file replace) is Working Copy (2). I just wish it existed where I need it – in the text editor, not the git client. (edit: Textastic says they are exploring adding it in).
The online life
What if you went the whole hog and did all your editing, compiling and serving off-board? Ok, it makes the whole point of doing it on iPad fairly pointless, but hey, whatever works for you.
If you’re a command-line nerd, all you need is a server somewhere out there (VPS or otherwise) and an SSH client – and you’re pretty well furnished with a selection of solid terminal apps. But you’ll still need to beware of the background time-out issue when you leave the terminal to check your site in a browser. Some apps (eg, Panic Prompt) warn you with notifications when they’re about to time-out, others try to keep the connection open by hackery like using mosh & location services – but I haven’t tried them (eg, Terminus, Blink shell – both have solid reviews).
Online based services like glitch.com or Codeanywhere allow you to do everything through the browser. That sounds clunky, but you’d be surprised how good the online editors are with solid line-tabbing and tag closing. However, other parts of the experience aren’t so wonderful; no-momentum scrolling frames, right-click actions and touch target size aren’t always catered for well. Plus text selection in Safari is notably worse than in other apps. Codeanywhere actually has a companion iPad app that is supposed to give a better experience – and only partly succeeds. They might have been better served just making the regular site work better on smaller screens and touch interfaces (3).
Thoughts on the single app workflow
It’s possibly because of all the app interoperability problems already discussed, that lots of developers to try and build a vertical workflow into a single iOS app. If you find yourself with the right project, you could download it, edit, upload, SSH in to a server, and even run a preview in a browser with basic dev tools, all within a single app. That means no sharing files within the toolchain and no background timeouts to worry about.
This is possible in several apps including Panic Coda, Textastic and even Working Copy (and Koder is in the ballpark).
But getting the UI right in this sort of workflow is not easy. I say that because the dev process is all about the round-trip. The round-trip requires the developer to make a code edit, see the result in a browser and then return seamlessly to the same line of code to make further edits. Reducing friction and time in this short process is paramount because a developer will do it hundreds of times every hour.
The desktop application workflow works so well because having separate apps actively enables the mental context switch between the editing and the feedback, by both physical separation of windows on the desktop (or screens) and with the “alt-tab” key-stroke that you could do in your sleep, enabling and indicating the mode change. Plus you never change the state of the editor, so when you return to it, that cursor is blinking exactly where you left it.
Most of the iOS apps that “preview” code try to mimic this seamless mode switch – with different degrees of success. Some lose the cursor on return because they swap the editor out for the preview. Some have animations that simply slow down the round-trip. Some need to re-spawn the local server – loading the page from blank, leaving you with no “before & after” comparison. It’s not a blocker if it’s not perfect, but the round-trip needs to be the core of the UX work of any app that aspires to this workflow, and I’m not sure I see anything that doesn’t make me want to return to a windowed, alt-tab world. Not quite yet.
Stringing together iOS apps into a workflow
The flip side of having all this vertical integration in apps is that coming up with a good toolchain on iOS is so damned hard when all the apps keep trying to do so many things.
On desktop computers, applications in the dev field are generally single purpose and you arrange them by windows to that end. Here’s your git client, here’s your editor, your sFTP client and your web browser with it’s dev tools. You try a new application and if it improves on your old tool, it simply replaces it.
But iOS apps in this area tend to have multiple features, so do I use the terminal function in the text editor, or get a separate app for that? Do I use the editor in the git client? Do I use the browser interface in Working Copy or Textastic because they have basic JS consoles, or do I stick to Safari? Do I upload through a dedicated app, through the editor app or via Working Copy spotting a file change and auto uploading? Which combination is the best for managing any potential background timeouts and screen real-estate?
Each feature in these apps has pros and cons, different abilities and quirks. When you then try to mix them together you need lots of time and endless patience to try out all the possible options to find the right balance in your workflow. If you can’t decide between Sublime Text and VSCode on a Mac, you’re going to hate trying to find the right toolchain on iOS.
I’m not saying all these extra features are bad and that iOS apps should stay “single use”, but having so many possibilities in every app sure makes it difficult to feel secure that the workflow you use at any time is the right one for you. There’s always another combination, often with the exact same apps you’re using.
In this article alone, I’m expecting several app developers to inform me where I’m going wrong in my usage of their app — and they’d be right. That’s why I’m labelling the attached videos as “recipes” – they are one way to do things, quite possibly not the best way.
Conclusion
So as of writing this, Adobe has announced Photoshop for iPad. The 2018 iPad Pro is benchmarking faster than almost all new MacBook Pros. 2018 could well mark a turning point in how iPad Pros really get shit done.
But that’s only if you’re a photographer, or a designer, a music/video maker or an illustrator.
Web development is a massive industry. But if webdevs want to be part of this turning point for the iPad, we have some pretty serious roadblocks to remove before we can get our job done effectively. iOS13 in 2019 needs to open some very specific doors so that app devs can fill the gaps.
Is anyone listening?
Be sure to check out the 2019 update to the state of iPad webdev here.
Footnotes
- Graphical workflow on iPad. You can preview and even import PSD files into Pixelmator for iPad or Affinity Photo (as well as Adobe apps – plus full Photoshop is coming in 2019). You can’t open Sketchapp files, but there does exist an app for you to preview them (Insight). Affinity Designer can open Adobe Illustrator files.
- Multi-file search in Working Copy edit. I’d previously complained that WC’s multi-file search was a little esoteric, but it turns out I’d only seen one of two ways to do it in Working Copy – and this is the one I should have been using.
- Codeanywhere companion app. A weirdly slow touch response time occurs often for me, and scrolling areas have no momentum — suggesting it’s actually partly an electron port of the website with a specific stylesheet. But that doesn’t explain the lack of basic functionality (there is no project delete function, you need to go to the website on a desktop and right-click on a project to see that), or the fact that almost any setting change kicks you out to a webview that requires you to log-in for a second time. This is such a missed opportunity.
- Textastic’s problem with linking local files to remote files more than one level deep might be related to using a file system within Working Copy (via iOS file APIs), not in Textastic’s file system. The developer has graciously looked into it and a fix is on the way in Textastic 7.1.2. Yay!
This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.
Follow our publication to see more product & design stories featured by the Journal team.
