After becoming a workaholic in the last three “plague” years and spending 7 days almost every week in the office, it was time for a vacation and change of scenery: a 25 days trip to South Korea and Japan. The only problem was that I still needed to work on my book, A Functional Approach to Java, so I had to take at least one device capable of doing that with me.

I was torn between taking my MacBook Pro 16", in the case of an iOS emergency, my Framework 13 Linux laptop, which would be smaller and lighter, or the option to take only an iPad Pro 12.9" with Magic Keyboard. The latter would have the advantage of being nicer to watch movies on or consume other content than a laptop.

As I decided to travel as light as possible, with only carry-on luggage, every gram counts. Even though the Framework weighs as much and has roughly the same dimensions as the iPad+keyboard, the iPad wouldn’t tempt me to do some actual work and treat my trip. I needed a vacation, not another workation.

Oh boy, do I regret the decision to take (only) the iPad…

tl;dr

To save you some time, this article is mostly a rant about the iPad not being the device I wanted it to be, even though I knew it beforehand. Nevertheless, I needed to write these words down and get them off my chest to understand better how to fit the iPad into my usual workflow, or if at all.

There are ways to extend the iPad’s capabilities, but each has downsides that made them unattractive to me. The conclusion is to choose the right tool for the job at hand, which means, in my case, a laptop, not a tablet.

The Best Tablet for (almost) Everything

Don’t get me wrong; the iPad is the best tablet and media consumption device I’ve ever owned. Well, the Google Nexus 7 in 2012/2013 was maybe the most overall awesome small-tablet package at the time, but I’m talking about my M1 iPad Pro 12.9" in 2023.

The hardware quality is unmatched, in my opinion. There are other premium tablets out there with certain better features, like a landscape camera for video calls. Samsung’s S8 high-end tablet offerings look quite nice but cost as much as iPads these days.

The next thing where Apple has an advantage, in my opinion, is the software. The tablet form factor is not an afterthought for iOS app developers, as it seems for many Android apps. I can’t say for sure, as I don’t have any Android devices in rotation. Still, the last time I checked out the competition, Apple’s App store provided way more optimized and feature-complete tablet-compatible apps than Android.

As an iOS-centric user, I’d need to mix/switch certain apps/services to utilize an Android tablet to its full potential.

The Magic Keyboard, although too expensive, is a great choice for a keyboard cover, as it connects and disconnects without effort, making switching between it and a smart cover a breeze. The Logitech Combo Touch is an alternative, as it also adds a kickstand to the device. However, I don’t like the “bulk” of putting the device into a case. My iPhone is also naked, as I’m not fond of cases or bumpers. Using a “normal” keyboard is an option, too. However, you wouldn’t have a trackpad, or the slightly elevated display, like when using the Magic Keyboard.

The iPad Pro mini LED screen is gorgeous to look at. Still, it has undeniably blooming issues. I sometimes notice them while watching videos, but it isn’t an issue for me in day-to-day use.

On the software side, the iPad is the clear winner over other tables for me. It took a few years for developers to adapt to the new form factor and possibilities, but now, iPad apps are much more than just “stretched” iPhone apps. The introduction of Mac Catalyst, which allows you to bring iPad apps to macOS more easily, will most likely introduce more apps to the iPad in a quality that wouldn’t be there otherwise.

So far, the iPad Pro looks like quite a good package for my needs on the road. But then, I had to do some actual work with it.

Getting (Some) Things Done

My primary use case for the iPad on my vacation was revising PDFs of my book. During writing the manuscript, I used PDF Expert by Readdle to work with the feedback from the technical reviewers. As it was a “read-only” situation, it worked great and I enjoyed the app. Now, however, I had to give feedback myself.

As much as I like PDF Expert, it doesn’t seem to support edit-replies as Adobe Acrobat does. With my copy editor suggesting to use Adobe Acrobat not possibly to corrupt a PDF anyway, I bit the bullet and subscribed to Adobe Acrobat on the iPad.

Even though I hate Adobe with a passion, the app is actually quite good, with a few things I prefer over PDF expert, like a list view of annotations so that I won’t miss any. My initial enthusiasm for Acrobat was gone real quick, though, as it started crashing repeatedly and destroying about the last 10 minutes of edits each time. Ultimately, I wrote a list in a text editor with my feedback, so I don’t have to repeat the same comments after Acrobate crashes.

Acrobat crashing wasn’t the only issue that came up. Minor issues and weird design choices manifested the longer I tried to use the iPad for actual work, not just content consumption. Many of the annoyances stem from what the iPad is: a primarly touch-based device with a keyboard as an afterthought.

It’s a Touch Device

The introduction of the Magic Keyboard, which includes a trackpad, made the iPad Pro appear like an excellent replacement for a laptop. Heck, even Apple is marketing the iPad as “your next computer”. But as usual, marketing overpromises, and the actual device and software underdeliver.

That doesn’t mean an iPad couldn’t replace “your” computer, but certainly not mine. I prefer keyboard-based workflows. That’s why I use the tiling window manager i3 on all of my Linux machines. The mouse is supposed to fill any gaps that are hard to achieve with a keyboard.

The Magic Keyboard gives you a mouse equivalent on the iPad as an adaptive cursor to better visualize the affected area. It’s quite an ingenious solution that seemingly integrates how a mouse functions and brings it closer to the touch-based interface and the related controls. Still, iOS and iPadOS are primarily touch-based, and no keyboard or trackpad will change that anytime soon.

Keyboard support depends solely on the actual app you’re using. If it’s an Apple one, most things you’d expect work, like navigation tables with the arrow keys, accessing Safari’s address bar with CMD-L, etc. But many tasks can’t be done with the keyboard, like accessing a table view’s search field with CMD-F or another combination. Any app can implement keybindings to work, but there’s no system-wide convention to follow.

If an app decides to roll its own UI instead of using the standard controls, you can kiss your keyboard controls goodbye. I think the worst offender in this area is the Gmail app, which has no keyboard-navigability or shortcuts at all! To add insult to injury, even Apple’s apps and the OS struggle with proper keyboard support.

For example, if you touch the three dots on the top for split-view, you can trigger Spotlight/Search with CMD-Space. Anything subsequent keystrokes, however, are going nowhere!

Another weirdness is if one of the two visible apps is the first responder, meaning it has an active text-based control, like when you write an article. Touching the other app, for example, Safari, to do some research, won’t resign the first responder and send keys to Safari. Doing CMD-Tab, though, will switch correctly to Safari. It’s the little things like this behavior that make the keyboard support feel like a half-assed job, or at least not in line with the touch support.

As an app developer myself, I can understand why implementing proper keyboard controls might not be a top priority for many apps. But what’s Google’s and Apple’s excuse?

You’re Holding It Wrong

Another aspect that makes using the iPad as a primary device difficult is more of a cultural problem that has plagued Apple for quite a while.

Most likely, you remember the iPhone 4 and “Antennagate”. If not, here’s the gist: The iPhone 4 got a redesign, including a new antenna layout. This changed layout was affected by how you hold/grip the device, as it was possible to electrically connect two antenna parts, degrading its signal strength immensely.

Apple’s response was, in essence: “you’re holding it wrong”. In my opinion, this statement perfectly reflects the problematic philosophy underlying Apple’s hardware and software, especially with iPhones and iPads.

As long as you’re holding it “right” and trot along the path Apple has laid out for you, their devices (let’s be honest, they are their devices, not yours) are great, and the software does what it says it does on the package. It “just works” for most users perfectly. Usually, that’s enough for me and my needs, at least on the iPhone and iPad. Sometimes, however, I’m in the minority of users that need more of their devices.

It’s pretty sad to see that these kinds of patronization and weird design choices are making their way toward macOS, too. We pay a fortune for the newest and shiniest devices, but Apple not only tells us how we’re supposed to hold them, but they also design it in a way that prevents you from holding them in any other way.

If you want or need to deviate from the path in front of you to get actual shit done, you’re (mostly) out of luck. Let’s take a quick look at the options available to gain back control over your device.

Leaving the Walled Garden

There are ways to go beyond the confinements of Apple’s walled garden, improving an iPad’s usability, with a few caveats. Which option might work for you depends highly on what you want to achieve.

This article is about what I considered and why none weren’t viable options for me. It’s not a detailed guide on achieving the different options presented, though.

The iPhone was an almost revolutionary device “back in the days”. Apple might not have invented the internet-connected touch-capable phone, but it was the best mainstream offering then and entered the market at the right time and conditions.

Even though Steve Jobs saw web apps as the right way to go, Apple caved and released an SDK for native apps, which enforced certain restrictions on what you could do. Users wanted more, though, and people started to use exploits to gain access full access to their devices, better known as “jailbreaking.”

In the beginning, it was as easy as visiting a website that exploited a flaw in the PNG codec. I remember buying an iPod touch in Japan, as they weren’t available in Germany at the time, and immediately jailbreaking it in the nearest café I could find. As exploits usually get patched, over the years, it became a cat & mouse game between the exploiters and Apple. You had to stay on older iOS versions, and sometimes even hardware revisions, as newer ones no longer had the required flaw to be exploited.

As of writing this article, there isn’t a Jailbreak for iOS 16, yet, and the iOS 15 one depends on a hardware flaw, restricting the devices that can be jailbreak even further.

I mostly use my iPad primarily for personal stuff. Still, it’s also my primary test device for iPad-related development, so it’s always up to date, with older iOS versions being restricted to older test devices. Even if I wanted to jailbreak it, there isn’t one available for the software/hardware combo, making jailbreaking a non-option.

Using the iPad as a Dumb Terminal

The next option is using the iPad as a mere terminal to connect to another machine capable of what you want to do. Using 3.600€ worth of hardware (at max specs & accessories) only as a dumb terminal seems almost comical, but here we are…

There are two most common ways to use your incredibly powerful iPad as a dumb terminal:

• SSH into a machine directly
• Use a remote dev container through VSCode

SSH into another machine

The first option is as old as time. Connect to another machine via SSH and run terminal apps remotely.

Multiple apps for terminal emulators are available on the App Store, like Prompt or Blink Shell. The latter supports Mosh, which will give a better experience when you have a spotty connection, but requires the other side to support Mosh, too.

Once you’re connected to the other machine, you can do whatever you want! Unless you want to run any GUI apps. That’s unfair to say, as it’s not 100% true. There are ways to connect to another machine and run GUI apps using protocols like RDP and VNC. However, I never got any of them working in a way I was satisfied with to get some actual work done. Especially when you’re halfway around the world, and the speed of light is still too slow for pleasant roundtrip times.

Being restricted to the terminal leaves you with the “usual suspects” of TUI tools: vim, emacs, tmux, etc. Don’t get me wrong, these are some of the most powerful tools available. Still, if your workflow isn’t already based on them, it’s usually impossible to switch “just” for traveling.

For example, I can “use” vim for smaller things. I can even “quit” it! But I’m not proficient enough to do meaningful work with an acceptable productivity level. I know, I know… I really should learn to use vim more efficiently, as it’s such an awesome tool, but I’m not there yet, so the option of using a remote machine via SSH wasn’t for me either.

Using SSH gives you quite low-level access to another machine. Let’s look at a more high-level approach, then.

Remote Dev Containers With Visual Studio Code

To get things done, a familiar environment is essential. That’s where Visual Studio Code (VSCode) comes in.

One of the major downsides of VSCode – being an Electron app – is actually an upside in this scenario, as it allows you to run (most of) it directly in a browser, including many of its extensions. That alone isn’t enough, though, as a browser is quite restricted, too.

Your browser still runs in a sandbox, lacking all the native tools required. To go beyond what’s possible in a browser, VSCode can connect to a remote machine, serving as the GUI to interact with such a dev container running on a remote machine.

It’s like connecting to another machine via SSH, but VSCode runs locally, hiding the fact it’s delegating all the work to a remote dev container quite efficiently.

This approach sounds like we hit the jackpot! A UI we’re accustomed to with all the benefits of a remote machine. Still, there are some downsides…

Internet Connectivity

The first one is shared with using SSH directly: internet connectivity. As you rely on another machine, you need to be connected to it.

Choosing a remote container location that’s near you helps to reduce roundtrip times. VSCode is quite good at hiding the fact that you’re not working locally, but when push comes to shove, you need a working connection. In my case, this means either relying on public or hotel wifi, which is often sub-sub-sub-par in Japan, or getting a SIM card with enough data not to worry about it. As you can see, internet connectivity might be an issue, but it’s manageable.

Securing the other side

The other major downside To consider is the security aspect. As your code runs on another machine, this machine has to be secure! It has access to your source code and, depending on what you intend to do, requires access to your SSH and GPG keys, too.

Unlike SSH, VSCode can’t talk to a machine directly. It needs a server application to talk to. The easiest way to achieve this is to use one of the established SaaS: Gitpod., GitHub Codespaces, or Coder.

I tested all offerings and actually quite liked them. Still, I’d need to trust them with my sensitive data, which would require more evaluation time.

An alternative is using one of the available self-hosted variants. Gitpod supported self-hosting until November 2022, so I looked at code-server, the open-source variant of Coder.com.

Having full control over the machine that hosts the VSCode remote dev container also means that you have to take care of everything yourself. This means you need a machine, preferably in a region close to you, set up your software stack and everything you need, and keep it safe and secure by yourself. Even though I’m used to setting up servers and dev machines, it’s not one of my strong suits, especially with unknown software stacks.

Getting familiar with the new software stack would take some time, so it’s another option that needs preparation if I want to do it right.

Almost Local Dev Containers

As the “remote” part of dev containers can be an issue or at least a chore to keep safe, I’ve also evaluated another option: making the “remote” part more “local” by moving the dev container to a locally connected Raspberry Pi.

The software stack for running remote dev containers runs on a Raspberry Pi, which can then be connected directly to an iPad via USB-C. By telling the Pi to emulate a network connection over USB-C, it creates a new network, and you can connect to the “remote” dev containers running on the Pi from your iPad without the outside world being involved. The coder.com documentation has more information on how to set up this arrangement.

This approach sounds great! You don’t need a remote machine; just connect the Pi via USB-C, which also doubles as the PI’s power supply.. However, you need to get your hands on a capable Pi first…

I overpaid for a Raspberry Pi 4 with 8GB RAM, so I don’t have to wait weeks to receive one. Then, I tried to set up everything I needed, and it worked! At least most of the time…

As you don’t have a monitor connected to the Pi, you don’t see what’s going on if you can’t connect to it for some reason. Of course, I could’ve added a small display to it showing some stats, but how would I debug any issues without being able to connect directly to the Pi?

Even if it works, there are more downsides that I won’t go into much detail, like:

• No internet connectivity: The Pi needs to connect to the internet by itself, regardless of the iPad being connected to a Wifi.
• ARM64: Most software should be available on ARM64, but your milage may vary.
• Slow performance: Compared to a “real” remote dev container, the PI is underpowered compared to a real remote server, or the iPad itself.

As you can see, using a Raspberry Pi is another “clutch” trying to force the iPad to do something it’s not supposed to do. With the general fragility of the setup, at least during my testing, it wasn’t a viable option for me, either.

The Most Obvious Solution

Hindsight is 20/20, so I have to say I should’ve taken my Framework with me as my primary device. If I had enough weight left over in my carry-on luggage allowance, the iPad without the keyboard would’ve made a nice addition. And the worst part, I actually had enough room and weight to take both devices with me…

All the options I’ve listed in this article are mere clutches to make things work that the iPad isn’t designed for. iPads are an excellent piece of hardware with one of the most capable consumer CPUs available, but as users, we’re held back by non-sensible defaults and artificial restrictions.

Even though I reviewed the copyedits solely on the iPad, thanks to the quite powerful Adobe Acrobat app, it felt like an exhausting chore compared to working on a “real” computer with real multi-tasking and full access to the filesystem.

The Jack-Of-All-Trades Device

If I knew all this beforehand, why did I do it anyway? Well, sometimes I’m an optimist, especially regarding tech stuff. I’m still dreaming of having a single device replacing multiple others to always have it with me and won’t miss out on any functionality. In reality, however, it’s a pipe dream…

I really hoped the iPad could be that “jack-of-all-trades” device for me. What most people forget about this saying is its second part: “jack-of-all-trades, master-of-none”.

For me, the iPad masters quite a few categories in a satisfying way. Still, other use cases are pretty lackluster or even impossible. A device I usually carry in addition to my iPad is my eInk reader, as it’s easier to hold and carry, and reading on eInk is always better than on an LCD. Also, I almost took my Supernote A6X, an A6-sized eInk note-taking device, with me because I like it so much more for note-taking than the iPad.

However, my general conclusions might not be relevant to your worklfows and requirements. I know a few (non-technical) authors that switched to an iPad because it’s a more focused device. But as a developer, I don’t see myself switching to an iPad full-time, or even only for traveling, any time soon.

The moral of this ranty article is that you shouldn’t choose your devices based on what you wish would be the workflow to be. Instead, be realistic and choose the tech you actually require and know how to use it and can do the job you need them for. The iPad is a great device, just not a “general purpose computing device” that can completely replace a laptop, especially for me as a software developer.