Why You Don't Really Want Mac Apps on iPadOS

There has been an increasing amount of talk lately about the idea of running Mac apps on iPads. This certainly isn't a new idea, with people wanting apps like Final Cut Pro and Xcode to run on iPads for almost as long as the iPad has existed, but it has really ramped up with the introduction of new iPad Pros featuring the same M1 chip as Apple's latest Macs.

I can certainly see the appeal. These are iPad Pros after all, so it's not unreasonable to want them to run all your Pro software. And if you primarily spend your time on an iPad, it would all but eliminate the need for a Mac laptop (at least for those who don't need a large MacBook Pro). You can already get part way there depending on your workflow, but the fact that all these higher-end Mac apps are missing from the platform really limits your ability to do that.

It doesn't have to be this way though. With the switch to Apple Silicon, Apple started allowing iOS apps to run unmodified on macOS. This gave Mac users access to a swathe of new apps, and didn't require anything from developers. So why not do this in reverse? The iPad Pro effectively has Mac hardware in it, so why not let Mac apps run unmodified on iPadOS? Where to begin…

How do you get the apps on an iPad?

For better or for worse, every piece of software you can run on iOS is in the App Store. They all comply with the App Store rules, their capabilities are known by Apple, and Apple can easily provide (or limit) access to them on any of their platforms.

On the other hand, the Mac App Store is merely a subset of all available Mac apps. It does have a fairly wide range of apps, but a lot of rather significant Mac apps are missing. Apps like Nova, Sublime Text, Creative Cloud, VMWare Fusion, Sketch, and even my own app Coppice.

There are many reasons for this, some business-related, some technical. Some of these apps will never make it into the App Store unless Apple massively changes their policies. This means the only way you'd be able to get a lot of these apps is if Apple was to allow side-loading of apps, something equally unlikely to happen (at least, willing).

There is no spoon file system

It comes as no surprise to anyone that iPadOS is not macOS. They may share similar foundations, but they are fundamentally different platforms with different capabilities and restrictions.

iPadOS is an app-based system. When you unlock your iPad you're greeted with a grid of apps, each of which lives in its own little silo, with very narrow means of communicating with other apps and with the system. This works great for security and for focused workflows where you live in only one app, but it can hurt workflows that require multiple apps working together (see Panic's latest post for an example of this).

Meanwhile, macOS is a file-based system. Apps, rather than being the starting point, are merely tools to act on files. The first app in the Dock on every Mac is the Finder, allowing you to view your entire file system and organise your files. It's common to have folders containing files created in a plethora of apps. Apps are designed to be part of a workflow, with multiple apps on screen at once.

Now you may think these are two completely different systems, and to some degree they are. However, the App-based system on iPadOS is actually built on top of a file-based system. Is is effectively a subset of the capabilities of a file-based system.

What this means is you can bring an app from iPadOS to macOS, and it will be none the wiser as it hasn't lost any capabilities. But bringing an app from macOS to iPadOS leads to all kinds of complications as suddenly the app is encountering walls where it expected open fields.

A touchy subject

At a high level, UI design seems fairly agnostic to input device. After all, regardless of if you're using a keyboard, a mouse, a stylus, or your finger, a button is surely just a button, and a text field just a text field, right? And you wouldn't be wrong to think that. However, the problem comes when you try to optimise for a particular input device.

Take your finger. It's big, it's clunky, and it's not particularly precise. This makes it a terrible way to interact with something that requires accuracy. It has one key advantage though: even a baby can use it. This is why touch screens are so popular: they have the lowest barrier to entry as you don't need to learn anything beyond the software itself.

I order to optimise for touch, you need to optimise for general inaccuracy. This means making your UI bigger and more spaced out to reduce the risk of tapping the wrong thing. Apple has long recommended a minimum size of around 44pt for controls, to give enough leeway for users. You can go smaller than this, but that usually requires you to try and predict what the user meant to do to correct errors, so it's only recommended when it's absolutely necessary (such as with the iPhone keyboard).

While a single finger may be disappointingly inaccurate, your hand can be capable of incredibly precise movements. We've learnt to augment this fine motor control with tools, from pens, to paint brushes, to what the Mac is best known for: the mouse. Mice can be incredibly precise. While Apple recommends a touch area shouldn't be smaller than 44pt, there is no minimum on the Mac (though generally you want to be at least 4-5pt).

Unfortunately this precision comes with a cost: locality. In order to be precise without requiring huge arm movements to get across a screen, mouse cursors don't move proportionally to the distance a mouse moves but to the speed it moves. Try moving your mouse an inch very slowly and then an inch very quickly, and notice the difference in how far the cursor moves. This means accuracy rapidly goes down the more you have the move the mouse.

To get around this, Mac apps tend to be designed with smaller controls that are packed more tightly together. Take this zoomed in screenshot from Xcode. It contains 4 distinct controls to interact with: the close button, focus button, breakpoint, and code folding bar. And these are all in an area that is just 44pt by 44pt, or the minimum control size on iPadOS.

What this means is that to optimise for a touch screen leads to making using a mouse slower, whereas optimising for a mouse makes using a touch screen far less accurate. Now being slower isn't as bad as being inaccurate. The former means you can do what you want, it just takes longer. The latter means you may not be able to do what you want. Much like with the file system issue, this means it's far easier to bring an unmodified iPadOS app to macOS than to go the other way.

Bad gestures

Also related to input devices is the subject of gestures. iPadOS relies heavily on gestures. From standard gestures to scroll, pan, and zoom, to custom gestures developers can build using multiple fingers. It's this reliance on gestures that can be why some iPadOS apps running on macOS can feel very clunky. At best they require some level of translation to mouse and keyboard combos, at worst they simply prevent certain functionality from working.

The lack of gestures on the Mac is actually a benefit to the idea of letting Mac apps run on iPadOS. Left click, right click, and scroll wheels can all easily map to existing gestures in iPadOS, as can the existing multi-touch gestures available for trackpad users. Unfortunately there is one interaction that is impossible to map to iPadOS (unless you attach a mouse): hovering.

Hovering is a vital part of many Mac apps. It allows for UI to be hidden until the user wants to interact with it. It lets you provide additional information on controls (such as icons appearing in the window close/minimise/zoom buttons). And it lets you show additional help via tooltips. Again, this ends up making large parts of some apps unusable on iPadOS.

Enough complaining, what's the solution?

You may have noticed that throughout this post I've been very specific about my wording. I've talked about running Mac apps on iPadOS, not about running Mac apps on an iPad. The points above outline why we're probably never going to see unmodified Mac apps running side-by-side with iPad apps, as we do with iOS apps on the Mac. But there is another option: virtualisation.

Virtualisation would allow you to install macOS itself on an iPad. This would solve a lot of the problems outlined in this post and mitigate many of the others. By running a full version of macOS in a virtual machine, you can give apps access to a full file system. You can also allow side loading of those apps, just as you can on the Mac. This is because a virtual machine can be sandboxed to protect the security of iPadOS, without the apps running in it ever needing to know.

By being a separate environment, you can also provide new interactions to work around UI issues. If you've ever used a VNC app on iOS to interact with a Mac, you'll be familiar with the ability to zoom into the Mac UI, and to drag a cursor around the screen with your finger. It's a bit clunky, but it fixes many of the UI problems.

And what's interesting, is there's nothing really preventing this bar Apple opening it up. The M1 (and A14 in lower-end iPads) supports virtualisation at the hardware level. Apple has a new virtualisation framework that works inside a more restricted security model. And macOS Big Sur introduced support for hardware accelerated graphics when running in a virtual machine. Put simply, all the pieces are in place for Apple to announce virtualisation support in iPadOS 15.

It should be said that the best solution to bringing an app from one platform to another is to re-design and port that app to be native to the platform. Even Apple recognises this, by providing Catalyst as a means of building Mac/mouse-optimised iPad apps for the Mac.

Apple could certainly make it easier to start moving the other way, and SwiftUI may very well play a role in that. But in the mean time, the option of virtualisation would allow users to use Mac apps that haven't been ported. And, more importantly, it allows them to use those Mac apps that can't be ported, because they can't fit in the more restrictive environment of iPadOS. After all, it's the only way I can see us getting an app like Xcode on the iPad in a way that allows you to do meaningful work (without also needing to buy a Mac).

Speaking of Mac apps… do you need a way to organise your thoughts and ideas, to visually lay them out, and to see the links between them? Then be sure to check out my new Mac app: Coppice