Guide
Using an iPad for web development can be easily split into two main parts:
- Setting up the iPad as a thin client
- Working in a remote environment
iPad as a thin client
Due to Apple’s lockdown of iOS and the lack of access to the native file system, you’re pretty much going to have to do the bulk of your development on a remote computer.
Even with good, solid apps for working locally — and I don’t feel these are quite there —the filesystem is the common language that makes web development on a regular OS as efficient as it is. The sandboxing on iOS means that there’s a lot of copying and referencing from one app’s sandbox to another. This adds friction, and is a common reason why others (even non-developers) struggle to move their workflow to an iPad.
Some developers seem to have had success working directly on the iPad using apps like Coda and Working Copy, but I’ve personally never found these to be suitable for my work.
In short, until Apple let us use the native filesystem in iOS — which they may never do — the iPad works best as a thin client, not because it’s the best thin client, but because of the remote environment it requires.
Even if you could use an iPad as you would a MacBook Pro, install your projects locally, work on them with GUI editors and apps, I’d still choose to use it as a thin client. The remote development environment is really the star of the show here, and you’d get the same benefits from using any device you choose in the same way. (Chromebook, Surface, netbook, laptop, desktop, even a phone - sort of…)
Apps
Without apps, you’re not going to get far! Almost all of these are paid, but in most cases I feel that the price is largely justified (and necessary…more on that later). iOS isn’t the ecosystem for you if you’re a devout believer in the “free beer” part of open source — you have to pay to install open source apps like Blink for example. This is because everything must come from the App Store, so you either buy it from there, or buy a developer license from Apple to install your own (open source) apps.
Blink Shell
Without Blink, I’m not sure that coding on an iPad would work. Sure there are other SSH clients for iOS, but Blink offers a lot more. Simple things like remapping keys help align your setup with that of your main computer, even if you’re lacking a much-used escape key…
I’ve mapped my Capslock to Ctrl which makes a lot of my tmux and vim commands much more comfortable. I’ve got access to the escape key in Vim thanks to the native Ctrl+[ binding, along with my own custom binding of jk.
However, I think that the best feature is Mosh support. For the unfamiliar, it’s basically an alternative SSH connection that has incredible “stickiness”. It rarely suffers from disconnects, even when I’m on flaky internet connections.
It also reduces latency by not waiting for the server to respond to a given input. If the server responds with something different, it corrects it. Some people have reported being able to work on a remote server during check-in for a flight, continue working on board from the crappy internet connection airlines offer, and carry on once they land; all without a single disconnect!
If anyone knows more about how Mosh works, or if I’ve got anything wrong, just shout and I’ll update it.
Ergo Web Tools
Browser devtools remain one of the biggest pain points when using iOS for web development. Ergo remains the best option, even though it’s very basic compared to Chrome or Firefox devtools. There’s no ability to extend it with plugins like React or Vue devtools (something I know was invaluable when I was working with them).
From what I can tell, it’s built by a single developer who recently had a baby. That’s made updates infrequent (understandable) and limited to bug fixes.
Whilst it’s the best of a bad bunch, I think there’s definitely room for someone to make the killer devtools app in the same way that Blink stands head and shoulders above other SSH clients.
Coda, Transmit & Prompt
Panic have a long history of making awesome software for macOS, and they were one of the first to jump into making “proper” apps for iOS. That said, they’ve been burnt quite badly by this choice and have decided to hold off on further development for now.
Coda for iOS (originally Diet Coda) is an all-in-one editor that replicates a lot of its desktop counterpart’s functionality. Personally I always struggled with Coda on the Mac, and find it even weirder on iOS.
It still heavily relies on pointer-input rather than keyboard and just feels like it’s designed for some super light static HTML work. Any dynamic app where the URL structure doesn’t directly map to the folder structure of where the template/file is stored doesn’t work. Basically you have to be writing vanilla PHP with a strict file = page structure, something I’m not sure many people still do.
Transmit on the other hand, I find wonderful. I was really sad when I heard that they were killing off the iOS version. If you already have a copy, it still works and will continue to do so, but they’ve pulled it from the App Store. It lacks the new protocols from Transmit 5, but I still think it’s one of the most useful apps for iPad, even if just for accessing S3 buckets.
Prompt is Panic’s version of Blink, and whilst pretty I don’t find it an equal to Blink. It matches it on a lot of features (creation and syncing of SSH keys) and adds a few more (snippets) but overall I find Blink the better of the two.
Personally — without Transmit — I don’t find Panics iOS apps compelling. I think they would do better to concentrate on single purpose tools and keep Coda, Transmit and Prompt separate rather than bundling the latter two into Coda. If they built a stripped back version of Coda that was just a great editor and nothing more, but integrated with the other apps well; they would do better in my eyes. That might not be possible with sandboxing though…
Aside: The fact that Panic have mentioned iOS as “Challenge” in their past four annual reports points to a larger problem within the iOS ecosystem — people aren’t willing to pay for professional quality apps. The result is that there are very few pro-level apps, and people keep thinking that iOS apps aren’t worth much money because they are all simple and not designed for proper work. It’s a vicious cycle that I’ve written about before, and one that Apple will need to address if they want to position the iPad as a credible platform. Apps like Affinity and now Adobe Photoshop coming to iPad should help change the tide, but there are still loads of great apps yet to be built for iOS.
Working Copy
I haven’t had much call to use Working Copy as I do all my development remotely so just use Git from the command line. That said I know many people like it, and use it for both source code but also version-controlled content (with static site generators and the like).
It works with external editors and the Files app, however this is just another area where the sandboxing of apps add friction to what should be an easy process.
What I will say however, is that I haven’t found a UI — regardless of OS — that makes using Git this intuitive.
Conclusion
There’s plenty of good apps available to let you work with an iPad as a think client. Things start getting a little more complicated when you start trying to use the iPad for more than that.
Whilst you can do somethings locally (Coda + Working Copy) you end up with a weird hybrid local/remote setup that only adds to the confusion and disconnect caused by sandboxing.
Personally I think that until (if) iOS is opened up a little more, working remotely is the sweet spot.
The Remote Development environment
I won’t go into this too much, as there are a multitude of options available depending on your preferences.
If you’re comfortable with using the command line, I’d recommend setting up a server on something like Digital Ocean, AWS or a dedicated provider like Hetzner.
Equally, you can also use a server that you host yourself, which could just be an old laptop. With some fiddling with dynamic DNS I’m sure most people could set up their own “server” at home using whatever hardware they have to hand. The advantages of this approach is the lack of a monthly cost and ease of external backups (although backups don’t get easier than DO’s snapshots). Potential drawbacks are slow/unreliable connections compared to a datacenter and less protection (most datacenters will have a degree of DDoS prevention built in).
If you’re not comfortable with a terminal, and prefer graphical editors like Atom, VSCode or Sublime then you can still work this way, but it’s not going to be as pleasant. Remote desktops are much heavier on bandwidth, often feel laggy and don’t work well on an iPad due to the lack of cursor input. You end up using your iPad as an oversized trackpad and it’s just not a great experience.
That said, if you’re committed to the iPad lifestyle but don’t want to get your terminal-fu on, there’s cloud development environments like Cloud9 and codeanywhere that run in the browser.
I’ve only really used codeanywhere, and that was a few years ago, but I found it to be very good. You’ll lack some customisation options within the environment but it provides plenty of sensible defaults and many of the common developer tools.
Aside: one studio that I worked with actually did everything on codeanywhere despite all having top of line iMacs sat on their desk. The unified environment, easy collaboration and ability to share a WIP project with a client were many of the benefits that they cited.
Reading List
There are now tonnes and tonnes of articles online. The release of the iPad Pro pushed the idea of the iPad as a full-time machine, even for demanding users like developers, into the mainstream.
Back when I first started researching this and trying it out (2011) there were literally two people talking about this online. To be honest, not much has been added to the conversation since then, despite large tech-publishers throwing in their tuppence. Most people still use the same (or similar) setup outlined in these first few articles.
Yield Thought, I swapped my MacBook for an iPad+Linode
Yield Thought, iPad + Linode, 1 Year Later
These two articles from Mark O’Connor are what convinced me that this setup is not only workable, but preferable. They were written in 2011 and 2012 respectively, and a lot has obviously changed since then, the introduction of the iPad Pro being the most obvious. These articles are now hard to find in Google, they’ve since been buried by a lot of Medium posts and mainstream articles that have greater SEO juice. I consider these to still be the best at explaining the how and the why.
Bonus article: Yield Thought, Setting up an iPad+Linode
Giving the iPad a full-time job – freeCodeCamp.org
This is a really interesting take on the subject. Justin’s methods are largely the same as others, but his motivations are quite different. He started - and carried on using an iPad - because he felt that it allowed him to focus more and even be a calmer, less stressed and more patient person. I haven’t noticed changes to that degree, but I do feel I focus better on the iPad and perhaps am a bit more chilled because I don’t fight my OS the entire time?
Creating A Remote Development Machine
A great article from Thoughtbot, walking you through step-by-step in setting up a remote development environment. If you’re unsure on how to do that, this is where you should start. This article leaves you shortly after your first SSH into the new droplet. If you get stuck here, I’d suggest looking at Digital Oceans articles about setting up, securing and hardening your server (will vary based on your distro/setup of choice).
Is anyone doing all their development on a server with vim via ssh? : vim
Whilst this Reddit thread doesn’t touch on iPads, it went a long way to convince me that working remotely is not as “out there” as it initially seems.
The iPad Pro as main computer for programming
Jannis covers all the bases of “how” and “why” with some awesome illustrations to boot!
Decoding
Zsolt has an interesting take on his choice of tools. He prefers new, reimagined ones like Coda over “old” ones like Vim. I can’t say I’ve come to the same conclusions RE: Coda, but I do agree there’s less cruft accumulated on iOS. The whole environment feels fresh and modern, which is also why it’s limited and lacks the flexibility some people need — it’s still a very young ecosystem!
Web Development with an iPad Pro – 48 Pixels
Another person in the pro-Coda camp.
Have a look around Google. You’ll find loads more, but I consider these to be some of the best starting points.
Why I work from an iPad
I’ve always liked iPads, even though I was very late to the party. My first iPad was the first-get 12.9” iPad Pro. They feel like pure magic in the same way that the first iPods did. They pack a silly amount of power, storage and battery life into a very small, well built package.
I know that other devices like Chromebooks, MacBook Airs and Microsoft Surface devices do the same (or even more!) but I’ve always had a preference for iPads.
That said, I will be the first to admit that they are still hamstrung as “proper work” tools. They have never quite managed to escape that “consumption vs. creation” debate despite the leaps and bounds that have been made.
As I mentioned above, I feel that’s largely due to the lack of pro-software and the instilled notion that iOS apps should be free or only cost £0.99. Apple along with third parties like Adobe, Affinity and Bear do seem to be tackling this and are starting to iterate that apps on an iPad can actually be better than their desktop counterparts by embracing features of the platform like multi-touch.
Most of the progress has been made with design or art focussed tools. Us developers have been largely left behind. This may change if Apple decide to one day upgrade Swift playgrounds into a fully-blown Xcode replacement. It’d be a herculean task - simplifying that UI enough for touch - but I think would herald the start of a new life for iOS. That along with a good photo editor/manager like Capture One would leave me with little reason to continue using macOS. That said, my favourite development environment isn’t actually iOS or macOS — it’s Linux.
However, I’ve unfortunately found Linux on the desktop to be an utter sh*t show. I know there are many happy desktop Linux users out there, but I am just not one of them. I’ve done a fair bit of distro-hopping over the past 3-4 months and have yet to find a distro or desktop environment that I could get on with. They all require a lot of fiddling or a blind eye towards the many inconsistencies between programs, UIs, typefaces, animations, etc.
The more you dig into fixing these issues — and that’s a huge rabbit hole to delve into — you realise just how broken things are. There’s X vs. Wayland, disputes between distros, outright arguments between developers supposedly working together, competing standards, etc. Most distros I never got audio, bluecoat or wifi working as it should, and none of them would work with a webcam (hardware to blame in that case though). As you’d expect from such a fragmented and divided ecosystem the experience is equally disjointed.
This is how I’ve settled on my iOS - Linux hybrid setup. I get to use Linux for everything it’s good for —package management that makes macOS and Windows blush, a solid shell environment, access to loads of open source software and great reliability and performance.
The joy of having an always on, incredibly powerful computer that’s exactly as I left it is hard to explain unless you’ve experienced it yourself. I can tap into this environment from wherever I am, whatever computer I happen to have in front of me, and it’s setup exactly as I like, ready to deploy a hot fix to a crashing website, run some tests on a codebase, leave long-running queries running whilst I get another coffee.
I work for myself and am responsible for all the software I produce. That means I’m effectively on-call all the time, which means that I need a computer to hand all the time in case of urgent issues with production sites/apps. Going to stay at a relative’s, going into town for a coffee, popping to the beach, no longer means carting my laptop with me in case theres an issue I need to urgently fix. Being able to administer quick fixes from my phone or iPad is liberating.
Sidenote: when you have these responsibilities, you don’t skip writing tests! 
Mark O’Conner’s articles (above) are what really sold me on this workflow. The device your using in many ways becomes irrelevant, but it allows me to choose the client that’s right for the rest of my needs, rather than have my work requirements dictate the hardware I purchase.
For everything else like web browsing, email, photo management, design/drawing, video calls I get to use a simple, lightweight and forward thinking OS with some awesome apps.
In many ways, it was Linux’s inability to work well as a desktop, let alone work well on a mobile device like a tablet or laptop that drove me to this setup. I don’t care about tweaking my browser. I don’t want to spend an hour of fiddling to get my email client working properly. I don’t want to boot up my computer to find that X.org isn’t playing ball today.
It looks like an unusual and complicated setup if all you’ve experienced is local dev on your laptop, but I actually find splitting the two responsibilities (development & everything else) makes for a much simpler setup. This is no different to how we reduce dependencies and coupling in our codebases.
Your thoughts
@AstonJ asked me to put together this wiki, but it’s just a starting point.
- What are your experiences on working in this way?
- Have you found any more good articles?
- If you haven’t read much about this before, what are your thoughts now that you’ve read this (now very long!) wiki?
