I’ve been playing with using an iPad Pro as my daily driver machine recently. This is hardly new. There’s heaps of people out there doing this. I’m a coder however, so getting access to a decent development machine is important. I thought I’d collect some of the tools that I’ve been using to use the machine as effectively as possible. The iPad pro is so close to being a perfect machine. There are still a few annoyances, most of which could be fixed with some improved applications.

iSh

iSh is a Linux shell, running directly on your iPad. Its really quite magical. They do it by emulating a full x86 machine directly on the iPad using syscalls. This gives it huge flexibility. They’ve based it on alpine Linux, giving you the ability to install additional packages, including things like python. But, as it is an emulator, it is slow. Its not going to be usable as your daily machine. I’ve also found that at the moment it can hang occasionally. It also doesn’t have multiple tab support. Still, its something to keep your eye on.

In the end, developing directly on the iPad isn’t an option yet. There are fundamental limits to the performance of iSh. They might improve it a bit, but its never going to be as good as a real laptop. Instead, its probably best to focus on getting good interfaces to remote machines. That’s what the reset of the suggestions here are going to focus on. When I say remote access, I mean “Just like you’re there” access. It should feel instant. There’s a couple of tools now that are making it possible to do this.

For the rest of these options, I’m going to assume that you have a remote Linux host that you develop on that you’d like to access. I use a host running on AWS, but any host will do.

Blink.sh

Blink is a terminal emulator for iOS. Like iSh, it provides a simple shell-like interface. Unlike iSh it doesn’t provide any general computing functionality, instead focusing on giving you a terminal emulator and the ability to ssh into remote machines. It has sensible keyboard shortcuts, and supports tabs via swipe on the screen. It works great, with one minor iPad annoyance. iPadOS will suspend applications when they’re running in the background. This means that any open SSH sockets will be abruptly terminated without notice. This can also happen when your device roams from WiFi to cellular for example.

This is where mosh can help. Mosh uses UDP instead of TCP to make the connection to your server. There are a number of purported benefits, but the big one here is that you don’t need to maintain a TCP session to the server. When you come back to the application your shell may still be operational. I say may because blink hasn’t added support for persistent sessions across app restarts yet. If you kill the application, or iPadOS decides to do it for you, you still might lose your shell.

Combining Mosh with tmux is a good option, to make sure that your session is kept going. That way even if the SSH/mosh connection is dropped, you can always resume it later on. I run tmux on my remote machine using the following command to have just one session that I connect to, recreating it if necessary.

tmux new-session -A -s mysess

I even configure my blink remote host to automatically run this command each time I log in.

VPN

One challenge you have with remote development is getting access to servers that you run. As an example, I am testing out this blog post as I run it by running a local server in draft mode. It opens up an unprotected HTTP server on localhost for me to see the draft copy of the website. This is great If my browser is running on the same host as the server, but if I’m using the iPad that won’t be the case. I’ll be editing on the development server, but viewing on the iPad. Opening up the development server to the world is an option, but that would be fraught with security dangers. I could use SSH port redirection, but as we’ve just discovered the iPad has a nasty habit of closing TCP connections when apps are running in the background.

The work around that I came up with is to use a VPN. I set up my development server as an OpenSSL Server, then I have all my devices (laptops and the iPad) connect to the VPN. That way they can all get to each other over the VPN. Then I set up a firewall on my development server that opens up all ports when accessed over the VPN, but blocks them from the internet. I did this using security rules on my AWS VPC, but you could also do it using any other firewall software if you wanted to.

In order to maintain the performance of my networking when not accessing the devices that are on the VPN (i.e. normal web browsing), I set up the VPN such that it uses split tunneling. By doing I set it up so that when I want to access my private devices I go over the VPN, but all other traffic goes out over the normal internet connection, just like always. There’s plenty of tutorials on how to set that up on the internet, but if you’re curious to know how I did it I have a post.

Using a VPN has one additional advantage that I’ve found very useful. I do a lot of work with devices - cameras and raspberry pis. By hooking them up to the VPN, I can get access to them from anywhere. My raspberry pi could be in the office and I could be at home, and I can still get to it. This makes life very easy for me.

VScode running in your browser.

Now we get to what I think is the pièce de résistance of these tools. A good remote editor. Namely, Visual Studio Code, the current darling of developers the world round. Normally, VScode runs on your laptop, and you do your development there. That won’t work for us on the iPad because our code is actually on the remote server. VScode has remote development capability, but that also won’t work because you still need VSCode to be running on the iPad. They haven’t ported it there, although it would be awesome if they did!

Some enterprising fellows realised however that the front end to VScode is written in HTML/js, and they wrote a patched version that allows you to run VSCode on your server and simply export the UI over HTTP(S). This works really well, especially when you combine it with a VPN so that you ensure nobody else can use your IDE. As the UI is actually running in your browser, it feels fast and you don’t have to worry (as much) about latency as you would if you were developing using remote desktop/VNC.

Once I proved that I could run VSCode in a browser window, I added it to the iOS homescreen so that it appears like its own application. Its pretty awesome.

Some annoyances

The biggest annoyance I have right now is that the iPad hardware keyboard folio does not have an escape key. I can type ^[ or use the on screen keyboard to get there, but my muscle memory is tied to the top left of the physical keyboard. I’ll survive.