Control a Mac from an iPhone: what you can finish on a phone

Searching for how to control a Mac from an iPhone usually starts with a specific, small task. A build needs restarting. A file has to be sent to somebody before a meeting. A long process was left running and its output needs checking. The frustrating part is that the answer depends less on which app gets installed than on three things about the task itself: whether the Mac is in the same room, whether the job needs a whole screen or a single command, and whether this will happen once or every week.

Get those three wrong and the result is a remote desktop session on a phone screen, pinching to find a menu bar, typing into a terminal through a software keyboard. That works, technically. It is also the slowest available answer to most of the tasks people actually have.

The direction that ships with macOS is the other one

The first thing that trips people up is that Apple's headline feature points the opposite way. iPhone Mirroring puts the iPhone screen on the Mac and lets the Mac drive the phone. It is not a way to reach the Mac from the phone, and no setting turns it around.

Its requirements also make clear that it was never built for being away. Both devices need iOS 18 or later and macOS 15 or later, Wi-Fi and Bluetooth turned on, the same Apple Account signed in on both, and a distance of no more than 30 feet, which is about 10 metres. Apple documents all of this on its iPhone Mirroring page, along with the limits: the iPhone camera and microphone are not compatible with mirroring, and some Continuity features stop being available on the Mac while it is running.

So a search for the reverse direction lands on a feature that solves a desk-tidiness problem rather than a distance problem. Knowing that early saves a lot of settings-app archaeology.

What Apple gives you in the reverse direction

There is one Apple route, and it lives in Accessibility rather than in Sharing. Switch Control has a mode for driving other devices on the same network.

With Use Other Devices for Switch Control, you can control your other Apple devices remotely on the same Wi-Fi network without adjusting any switch connections. Source: support.apple.com

The setup is short. Both devices go on the same Wi-Fi network and sign in to iCloud with the same Apple Account. On the Mac, Accessibility in System Settings has a Switch Control section with an option to allow platform switching to control the computer. On the iPhone, Switch Control gets turned on, then the Switch Control menu offers Device, then Use Other Device, then the Mac, then Connect. Holding the switch for ten seconds hands control back to the phone.

Two caveats decide whether this is the right tool. It is a switch-scanning interface, designed so that someone using a single physical switch can navigate an entire system, which makes it deliberate and slow for anyone who does not need that. And it requires the same Wi-Fi network, so it does nothing from a train. For accessibility purposes it is excellent. As a general-purpose remote it is not what it was built for.

Screen sharing versus sending a command

Every remaining option is one of two shapes, and the shapes matter more than the brand names.

Shape	What you get	What it costs	Good for
Remote screen	The whole desktop, pointer and all	Latency, pinch-zoom, a 4K screen squeezed into a phone	Tasks with no command line equivalent
Terminal over SSH	A shell on the Mac	No graphical apps	Restarting services, checking logs, moving files
Saved shortcut over SSH	One command, one tap	Has to be written in advance	Anything repeated
Switch Control	Pointer navigation on the same network	Slow by design, same network only	Accessibility use

Remote screen tools are the ones most articles recommend, and they are the right answer when the job genuinely needs a graphical application. Apple's own Screen Sharing is built for Mac-to-Mac, so reaching a Mac from an iPhone means a third party client, and the free option most people land on is Chrome Remote Desktop, which Google documents as supporting remote access to a Mac, Windows or Linux computer from a computer or mobile device. Paid clients exist with better input handling and file transfer.

Latency is the other thing worth measuring rather than assuming. On a local network a remote screen feels close to native. Over mobile data the same session develops a delay between a tap and the pointer moving, which is tolerable for clicking one button and intolerable for dragging a selection. The fix is not a faster client. It is choosing a task shape that does not need dragging.

Whichever client gets used, the host constraint is identical and is the part that catches people out. A sleeping Mac answers nothing. The machine has to be awake and on the network, which for an always-away setup means either a desktop left running or a laptop configured not to sleep on power.

Remote Login is the setting that unlocks the useful half

The command-shaped options all sit behind one switch. Remote Login is in System Settings under Sharing, and turning it on starts the SSH server and shows the exact address to connect to. Apple describes the switch and the list of users allowed to log in in the macOS User Guide.

With that on, any SSH client on the iPhone reaches the Mac, and on a local network the .local hostname is enough:

ssh [email protected]

Two decisions are worth making at this point rather than later. The first is key authentication instead of a password, because typing a strong password on a phone keyboard every time is the reason people abandon this route after a week. The second is how the connection works from outside the house. Opening the SSH port on the router is the option to avoid. A mesh VPN gives the Mac a stable private address that follows it between networks, so the same hostname works from a phone on mobile data without anything being exposed publicly.

What this unlocks is most of the real task list. Restarting a stuck process, checking whether a long job finished, tailing a log, pulling a branch, freeing disk space, copying a file to a location a colleague can reach. None of those need a pointer.

A shortcut that runs one command beats a screen you have to pinch

The Shortcuts app has an action called Run Script Over SSH, and it is the most underused answer to this whole question. The action takes a host, a port, a user and an authentication method, and it can generate an SSH key for itself rather than storing a password. The script goes in the action body.

The result is that a task which used to mean opening a remote desktop, waiting for the connection, finding the terminal window, and typing becomes a single tap from the Home Screen or the Lock Screen. A shortcut that restarts a development server is one line. A shortcut that reports free disk space is one line. A shortcut that pulls the current branch and runs the test suite is three.

There is a practical detail worth planning for. A shortcut returns whatever the command printed, so commands that are quiet on success are the ones worth wrapping first, because the returned text becomes the confirmation. Commands that ask a question interactively are the ones to avoid, since there is nothing on the phone side to answer them. Writing scripts that either succeed silently or print one clear line makes the difference between a shortcut that gets used and one that gets deleted.

Where a phone screen actually fails, and what it is good at

Once the connection works, the limit stops being technical. It becomes physical. Precise pointer work on a 6 inch screen representing a 27 inch one is unpleasant no matter how good the client is. Sustained typing is worse. Reading a wide diff sideways is worse still.

What a phone is genuinely good at is a shorter list than the remote desktop marketing suggests, and it is worth being honest about it, because it changes what you set up. A phone is good at deciding, approving, checking, and starting. It is bad at composing and editing. The tasks that fit are the ones where the information needed is small and the action is a single choice: a process needs killing, a run needs approving, a file needs finding and its path needs sending, a job needs kicking off before the train arrives.

That framing is why the file side matters more than the screen side. Most of the small tasks are file tasks in disguise: locate something, confirm what changed, hand a path to something else. Being able to browse a tree, read a file and run a command against it without three separate connections is the difference between finishing a task on a phone and merely observing it. That specific arrangement is what From iPhone and iPad is about, and the panes it is built from are described in Features. For the broader question of which tool to keep on the Mac itself, Compared with other file managers lays out the trade-offs.

Making it survive the week after you set it up

Most of these arrangements work on the afternoon they are built and quietly stop working a fortnight later, and the causes are boringly consistent.

The host went to sleep. A laptop lid closed, or idle sleep took a desktop that looked permanently awake. Checking pmset -g assertions on the Mac shows whether anything is actually holding it awake, and a long job can be wrapped in caffeinate so it holds the machine open only for its own duration rather than changing the setting permanently.

The address changed. A .local hostname works on the home network and means nothing elsewhere, and a home broadband address moves without warning. This is the single biggest reason a setup that worked from the sofa fails from a station platform. A mesh VPN fixes it properly by giving the Mac one private address that does not depend on which network it is on.

The authentication broke. A password-based SSH login survives exactly as long as your patience for typing it on glass. A key stored in the SSH client or generated by the shortcut removes the friction, and it removes the temptation to pick a shorter password.

The command needed a decision. Scripts that prompt interactively hang forever when run from a phone, because nothing is there to answer. Anything that might ask a question needs the non-interactive flag added before it goes into a saved shortcut.

Testing each of these deliberately, from mobile data rather than from the same room, is fifteen minutes that saves the trip home.

What to change first

Turn on Remote Login and set up key authentication before installing any remote desktop client, because that one switch covers most of the tasks and costs nothing. Then write a single shortcut for the thing you already do most often from the phone, and see whether the remote screen is still needed afterwards. If the answer is that the missing piece is reading and acting on files rather than seeing the desktop, that is the gap Atriens was designed around.