The short answer is: no. (Or, at least, not without a lot of headaches and a seriously subpar experience.) However, given the option between missing out – yet again – on an IndieWebCamp or knuckling down and trying to make it work, I chose the latter. At the very least, it turned into a conversation starter with a few people 😅

iPad's are very good writing devices, and I found pairing mine with a solid Bluetooth keyboard (I'm extremely happy with the Logitech K780) was a great setup for taking notes during group discussions, writing up thoughts later on, or quickly searching around online to find a useful site or resource for someone. For that side of the conference, this was a clear success! A smaller footprint than a laptop, excellent battery life (I don't think it dropped by more than 5% an hour), and a very comfortable typing experience – it was great 👍

But day two of the event was a "hack day", and whilst non-code activities like writing, content editing, project managing etc. were all encouraged, I'd set my sights (and heart) on some development projects. So could I create an equally viable code editor?

The options

The first stage was to look for native iPadOS apps that might work. I'd honestly expected to find at least a couple of decent solutions, but whilst there are a few dedicated apps, they all had critical flaws. I won't list the exact reasons why a specific solution wasn't right for me, but the general hurdles that many seemed to trip up on were:

• Not actually enabling local code editing, but rather using some kind of web tunnel connected to a third-party service, which didn't fill me with joy (nor did I want to end up self-hosting my own server!);
• Lots of poor reviews, missing documentation, or other general red flags;
• No access to a terminal interface for CLI tools, which I consider an (unfortunate) necessity when using things like Git or local development servers;
• Poor plugin ecosystems or no support for "common" build/developer experience tools like Prettier or spellcheckers.

I did watch a few videos and read a few articles where people seemed to have found apps that work for them, so I'm not saying it's impossible, but given that most of these services lack free tiers (even as a trial), it was hard to justify pulling the trigger and experimenting with any of them.

What I really wanted was a way to use Visual Studio Code on my iPad. There are things that I dislike about VS Code but, overall, there's nothing major that I would change, and I'm very used to it. I was honestly surprised that no one had ported it^[1] over to iPadOS, but Apple does have some weird opinions about how much productivity you're allowed to have on their supposed productivity tool, so maybe that animosity, combined with a relatively low potential user base, has never made it a worthwhile investment of time.

Thankfully, in my various online searching to see if such a thing as an "iPad version of VS Code" existed, I realised that one potential solution was sitting right in front of me. I vaguely knew that you could share your VS Code instance via the browser – a feature pitched as a team coding/pair programming tool – but it's not something that I've ever tried before. Still, in theory, if I could share an instance of VS Code between two computers, why not share it between one computer and an iPad? I began digging around and discovered that VS Code actually has native, free tunnelling built in. With a simple terminal command, you can generate a tunnel powered by some Microsoft server somewhere, and have it automatically made accessible from a generated URL. Any device that opens that URL in a web browser can then use VS Code exactly as you would from the original instance, with all of your extensions and personal settings preconfigured and running.

Setting it all up

I had expected that this would be a world of pain, but in reality it was incredibly simple. All of the heavy lifting is done for you by the application itself. I think you can do this entirely from within the VS Code GUI, but I found the CLI the easiest method. Just pop open a terminal, navigate to the folder that contains your codebase, and enter the command:

code tunnel

And that was it^[2].

Magically, this even handles local development environments and test suites, automatically creating additional "tunnels" for each port being used to serve local content. As a testing tool, then, this is great, because not only can someone else remotely view, edit, and comment on your code, but you can share a local version of a site or app and let them run it on whatever device or browser combination that they (or you) want!

I decided to put this through its paces at home. I made sure that I could still access the tunnel from any combination of 4G, Wi-Fi, and wired Ethernet. I checked that I could have the output of the local development server running on a separate device to the one being used as a code editor, and that updates to the code were synced across all three systems instantly. I left the tunnel running overnight, with no open connections on any devices, then confirmed I could still connect it to from a separate network the next morning. I even tested whether I could run the tunnel from a computer set to a sleep state. That last one unfortunately didn't work, so to use this technique you will need to have one computer permanently turned on, with VS Code (and a tunnel) running, and with a live internet connection. But everything else worked flawlessly.

I remain most impressed by the fact that code changes sync so well. There is something that feels almost unbelievable about typing some CSS into your iPad and seeing multiple secondary devices immediately update, all across different operating systems and browsers, and without even having to hit the Save button 🤯

But that was how things went at home. How did it fare on the day?

Time to throw out the MacBook?

Well, my glowing praise may have already been slightly tempered by the first line of this article. Can you code on an iPad? No. Not really.

The tunnel worked pretty damn well, all things considered. My Windows PC successfully maintained the connection throughout the weekend, and I was able to work on the projects that I'd hoped to and get something up and running for the demo session at the end of the event. But I wouldn't trade out my laptop for the iPad any time soon. Yes, it's a lot lighter, and easier to move around, and I actually quite liked swapping a trackpad for a touchscreen (most of the time), but the flaws outweighed any benefits.

The first issue is actually getting to the tunnel from the iPad. There may be some way to customise the generated URL – or even use a vanity URL – for the tunnel, but if the setting does exist, I couldn't find it. So you have to come up with some way of remembering the URL instead. I got around this by using synced tab history in Firefox, but it was a bit of a pain. This was annoying, but far from a deal-breaker.

The second problem is the size of the screen. To be fair, I have a 2020 iPad Air, and it's more than big enough to run VS Code. But to run VS Code within a browser? That's a taller order. In their infinite wisdom, Apple don't seem to give you any way to manually hide or remove the browser chrome in Safari^[2]. Sure, on a regular web page that massive URL bar and second massive toolbar disappear as you scroll down a page. But the page served by the tunnel auto-sizes to the available viewport; no scrolling necessary. This is definitely the right move on VS Code's part, but it leaves you stuck with about 20% less screen real estate.

I did discover that you can work around this by "saving the website to your home screen", which is Apple's long-winded way of effectively turning any site into a PWA. You can access this from the Share menu (who knows why it's situated there) and once done, the site loads without any browser chrome at all. Huzzah 🎉

You might think that's problem two solved then, but actually it just creates problem three: the overaggressive resource management of iPadOS. When I'd been testing this setup at home, I'd made sure that I could run the tunnel in one tab of my browser, and the dev environment output in a second tab, whilst switching between them to check my changes. That worked fine, though it was a bit clunky. What I wanted to be able to do was use the inbuilt swipe mechanics to quickly jump between two screens, and I'd thought that installing the tunnel as a PWA would make this simple. But it seems that whenever you swipe between two apps on the iPad – even a very modern iPad with plenty of system memory and nothing else running – the now out-of-focus app has all resources either paused or actively diverted. And that includes the active connection.

So every time I switched screens, the tunnel dropped out. This would then take about a minute to reconnect, and would sometimes require me to go back through the authentication handshake as well. It also terminated the development environment entirely, so even if you were wanting to see the output on, say, your phone, but wanted to use the iPad to look something up online, well, you couldn't. It effectively turned the iPad into a single-application device. You either had VS Code focused, or the whole system broke. Frankly, this sucked. I wanted to be able to jump over to WorkFlowy to look at saved design ideas, or bring up my own site to look up some notes I'd made on a previous project, or even just test the project I was working on with a larger screen, but I couldn't. Not without losing 1-2 minutes (and sometimes considerably more) setting everything back up again. Talk about a flow state killer!

Maybe there is some way to prioritise an app within iPadOS, so that it's kept running at the expense of everything else, but I couldn't find it. This was easily the single largest issue, and the core reason why I wouldn't recommend using this technique yourself. But there was one other irritation that I hadn't really expected, but probably should have seen coming: the lack of developer tools.

Again, despite the relatively powerful hardware that a modern iPad has access to, the mobile version of Safari doesn't seem to have any concept of developer tools. There's no Inspect Element or hidden developer mode. No way to see under the hood and check the code actually being rendered to the page. As someone who frequently builds in the browser – including doing a lot of my CSS editing directly in developer tools – this really sucked. For instance, I had an issue trying to get some items in a Flex array to behave as I would expect, but it was frustrating trying to work out why without access to any of the debugging techniques that I'm used to. I couldn't investigate the box model diagram or try toggling certain CSS rules on or off; I couldn't even check to see if the code was all being rendered as I expected. All I could do was revert to the days of setting different coloured borders on everything and jumping back and forth between the code editor and my live environment. Manageable? Sure. Enjoyable? Not even a little bit!

All of this could probably be solved by a native code editor and a diverse browser ecosystem. After all, I can download developer-specific versions of some browsers on my ten-year-old Android phone and get much more information there then I could via iPadOS. But the reality is that until Apple prioritises making the iPad a meaningfully useful productivity tool, even the most basic web development is going to remain technically possible, but not truly workable.