How to control your Mac from an iPhone, and which method fits which job

Apple sells you the other direction. iPhone Mirroring puts the phone on the Mac's screen, Universal Control shares a keyboard between a Mac and an iPad, and Sidecar turns an iPad into a second display. Going the other way, phone controlling Mac, has no single Apple app on the iPhone, which is why the search results for this are a mess of VNC clients and remote desktop marketing.

The methods that do exist are good at different jobs, and the mismatch is where people waste an afternoon. Dragging a tiny cursor around a 16-inch desktop rendered on a phone is miserable for anything except a one-off rescue. Running a command or answering a waiting agent is genuinely fine. Pick by the job, not by the app store rating.

The four approaches, and what each one really is

Screen the whole desktop. The Mac's built-in Screen Sharing is compatible with VNC, an industry standard for controlling computers remotely over TCP/IP, so any VNC client on iOS can connect to it. This is full control: the remote user sees what is on screen and can open, move, and close files and windows, open apps, and even restart the Mac.

Run commands over SSH. Turning on Remote Login lets another computer reach the Mac using SSH or SFTP. An iPhone SSH client then gives you a real shell, with no screen to squint at.

Trigger prepared actions. The Shortcuts app can run actions on the Mac, and Home automations can be set up so a tap or a time of day starts something. Nothing is improvised, which is the point: the decisions were made in advance, on a big screen.

Drive an agent session. If what is running on the Mac is an AI coding agent, the useful remote control is the one built into that agent rather than a picture of a desktop. Claude Code's Remote Control, for example, connects the Claude app on the phone to a session running locally, so the filesystem and tools stay on the Mac.

There is a fifth, narrower option worth naming. Switch Control, an accessibility feature, can control another Apple device on the same Wi-Fi network when both are signed in with the same Apple Account. On the Mac, Accessibility settings have to allow platform switching. It exists for switch users rather than as a general remote desktop, but it is the one path that is entirely Apple's own.

Setting up the two that need the Mac configured

Screen Sharing

On the Mac, open System Settings, click General, then Sharing. Turn on Screen Sharing. If Remote Management is on, turn it off first, because both cannot be on at once. Two options matter for phone access: Anyone may request permission to control screen, and VNC viewers may control screen with password, which requires setting a password. Then choose who may connect, either all users or a named list.

From the phone, connect with a VNC client to the Mac's address. On the same network this is straightforward. From outside, it is not, and that is covered further down.

For managing several Macs, installing apps and building reports, Apple sells Apple Remote Desktop on the App Store. That is a fleet tool, not something to buy for reaching one machine from a phone.

Remote Login for SSH

Same place: System Settings, General, Sharing, then Remote Login. There is an option to allow full disk access for remote users, and a list of who may log in, either all users or named ones. Under the Remote Login: On indicator, the Mac shows the exact ssh command to use, which saves guessing the hostname.

From the phone, an SSH client connects with ssh username@hostname, where the hostname is an IP address or domain name. Apple's own documentation is blunt about the trade-off: allowing remote login to a Mac can make it less secure. Use key-based authentication rather than a password, and do not expose port 22 to the open internet.

Prepared actions instead of live control

The third approach is the one people skip, and it is often the best answer. Most of what anyone actually does remotely is a short list of known tasks: start a build, sync a folder, export a report, put the machine to sleep. Those do not need a live connection at all. They need a command that was written once, on a large screen, with time to get it right.

The pattern is simple. Write the task as a script on the Mac and test it there. Then trigger it from the phone, either through the Shortcuts app or by having the phone open an SSH session that runs the single command. Because the script is fixed, there is no cursor to aim, no window to find, and nothing to mistype on a moving train.

It also fails more gracefully. A live screen session that drops in a tunnel leaves a half-finished click. A script either ran or it did not, and the output says which. For anything repeated more than a couple of times a month, this is the version worth building.

Which one fits which job

Job	Best fit	Why
Answer a prompt from a running agent	The agent's own remote feature	No cursor, no lag, built for the exact interaction
Restart a stuck service, check a log	SSH client	Text is the one thing a phone screen handles well
Click a button in an app that has no CLI	Screen Sharing over VNC	Nothing else can reach a GUI-only app
Start a known task at a known time	Shortcuts or a scheduled job	No live connection needed at all
Grab a file you forgot	SFTP, which Remote Login already enables	Same setup as SSH, no extra service

Reading the table the other way is also useful. If the job in the left column happens weekly, it is worth the setup in the middle column. If it has happened once in a year, borrow a laptop instead of building infrastructure for it.

The pattern is that screen sharing is the heaviest tool and the last resort. It needs the most bandwidth, gives the worst input experience, and is the only one that requires the Mac's display session to be in a usable state. Everything else is lighter and more precise.

Reaching the Mac when you are not on the same Wi-Fi

This is where most setups fall down, and there are three honest options.

A VPN back to the home or office network is the cleanest. The Mac keeps its local address, nothing is published to the internet, and every method above works as if you were on the couch. Many routers can run one, and several third-party mesh networks do it with less configuration.

Port forwarding, exposing VNC or SSH directly, is the option to avoid unless you know exactly what you are hardening. Both services are scanned constantly. If you do it for SSH anyway, disable password authentication entirely and use keys.

Third-party remote desktop services route the connection through their own servers, so nothing is exposed and there is no router configuration. The cost is that a vendor sits in the middle of a session on your machine, which is a decision to make deliberately rather than by default.

One constraint applies to all three: the Mac has to be awake. In Energy Saver or Battery settings, waking for network access helps, though a laptop with the lid shut on battery will still sleep. A desktop Mac plugged in is a far more reliable target than a MacBook in a bag.

Bandwidth is the other thing that separates the methods here. A screen session streams a moving picture of a display, so a weak mobile connection turns it into a slideshow and input lag makes precise clicking painful. A shell session sends a few hundred bytes per command and stays usable on a train. That difference is why the same person can swear remote access is useless and, a week later, find it perfectly good: they changed which method they were using, not which network they were on.

Keeping it from becoming a liability

Remote access is a door, and every method above adds one. A short list keeps it from turning into a problem.

Limit who can connect. Both Screen Sharing and Remote Login let you choose named users instead of everyone, and the named list is the setting to use. Screen Sharing's VNC password option is separate from the account password and is weaker, so leave it off unless a specific client requires it.

Prefer keys to passwords for SSH, and turn password authentication off once keys work. Think twice about the option to allow full disk access for remote users, since it widens what a compromised session reaches.

Turn services off when a project ends. A Mac that has had Screen Sharing on since a support call two years ago is a door nobody remembers. Both toggles are in the same Sharing pane, so a check takes seconds.

Finally, assume the network matters more than the settings. A machine reachable only over a VPN is in a different risk category from one answering on a forwarded port, whatever is configured on the Mac itself.

The case where none of this is the answer

A specific situation drives a lot of these searches, and it deserves naming, because screen sharing is the wrong tool for it.

An agent is running on the Mac. It works for twenty minutes, then stops on a question: may it write outside the project, or which of two approaches should it take. The desk is empty. Nothing continues until someone answers.

Connecting a VNC client to answer that is like driving home to press a doorbell. The agent's own remote path is built for it. Claude Code sessions can be reached from the Claude app, with the session still running locally and push notifications when a decision is needed. Codex and other agents have their own equivalents. The phone becomes an answering device, not a tiny desktop.

That also reframes what the remaining desktop time is spent on. Answering from the phone is seconds. Checking what the agent actually produced is the part that eats the afternoon, and it usually means a Finder window for the files, a terminal for the commands, an editor for the diff, and a preview app for anything that is not text.

A file manager with a built-in terminal folds that circuit into one window, which is the half of the problem remote access does not touch. The feature list covers what stays in a single window, and the comparison with other file managers sets out how that differs from Finder.

What to set up first

Turn on Remote Login and put an SSH client on the phone, because it covers the widest range of real emergencies for the least setup and the least exposure. Add Screen Sharing only if a GUI-only app is genuinely part of the job, and reach both through a VPN rather than an open port.

If the actual reason for searching was a coding agent waiting at an empty desk, set up that agent's own remote path instead and skip the desktop entirely. Atriens is one way to keep the folder, the terminal, and the session in one window, including from an iPhone while the Mac keeps working.