What remote access can actually do on each platform

Windows supports the desktop access pattern most IT teams expect: attended viewing, keyboard and pointer control, unattended maintenance where authorised, file transfer and terminal access. The enrolled agent and technician’s permission determine whether a particular machine can be reached.

“Windows supported” still does not answer every deployment question. User accounts, endpoint policy, privileged prompts and network restrictions can change the session experience. Test the task that matters to your team, including any administrator workflow, rather than stopping when a desktop first appears.

Separate the person connecting from the account used inside the remote operating system. A support technician’s Remote Login identity explains who opened the session; local Windows permissions still govern the work on that computer. The existence of a connection is not a grant of administrator rights.

For planned unattended work, identify who authorises that mode and which devices it covers. Servers and staff workstations may have different policies. A single working installer should not quietly become a blanket policy for the whole fleet.

On macOS, screen viewing and input are separate permissions. Screen Recording allows the relevant app or agent to capture the display. Accessibility permits the input interaction needed for control. Granting one does not prove that the other is present.

This is why a session can look connected while the technician cannot move the pointer or type. It is also why “the agent installed successfully” is not an adequate acceptance test. The setup process must verify the screen, pointer and keyboard as distinct outcomes.

Apple documents screen and system audio recording permission as a user-controlled setting. The exact labels can vary by macOS release. Follow the setup instructions for the installed version and have the person at the Mac approve the correct application identity.

App and agent updates can affect permission identity. If the screen or input stops working after a binary change, inspect the current grants before treating the result as a network fault. Repeating an install without checking which app has permission can leave the same failure in place.

The practical pilot is simple: view a non-sensitive test desktop, move the pointer, enter text in a safe test field and confirm the local user can stop the session. Record those results. A badge should reflect those checks, not assume them from the device’s operating-system name.

Android viewing and control depend on the device’s ownership, permissions and supported management configuration. An organisation-owned managed device is not equivalent to an employee’s personal phone. Manufacturer and OS-version differences can affect what a remote support app may do.

For attended sharing, the person at the device starts the sharing flow and retains a way to stop it. Remote input and unattended access require a supported configuration; they should not be inferred from the fact that the screen is visible.

Build a small test list that represents the actual fleet: manufacturer, model, OS release and management state. Ask for the precise action you need—viewing, tapping, typing or returning when no user is present—and verify it separately. A product that works on one managed model has not automatically demonstrated the same capability on all Android devices.

For personal devices, explain the scope to the owner before the session. Showing a work-app problem may expose notifications or other content on the screen. Keep the support task narrow and let the person stop or prepare the display as needed.

Remote Login cannot remotely tap or type into an iPhone or iPad. Third-party support apps do not have public system-wide input-injection access. Attended screen sharing, a pointer overlay and chat can help the user perform the steps, but they do not turn viewing into control.

Apple’s own FaceTime remote control is a separate first-party feature available in supported calls and regions. Its existence is why an unqualified statement that “an iPhone can never be controlled remotely” would be wrong. It does not make that function available to Remote Login.

Our iPhone and iPad support reference explains screen broadcast, the distinction from device management, and questions to ask a vendor making a broad mobile-support claim. Read it before buying any support product specifically to control an iPhone.

A platform list is easy to scan, so it compresses several different capabilities into one word. “iOS supported” can mean that an iPhone can act as the technician’s viewer, that a customer can share a screen, or that a device can be enrolled for management. Those are three different claims.

The commercial temptation is to let the reader supply the most generous interpretation. The problem comes later, when the support team has already promised something to an end user. Precise language moves that conversation earlier, while the buyer can still make a useful choice.

We publish separate capability rows because a limitation belongs beside the positive claim it qualifies. It should not take a sales call to discover that a phone cannot accept remote input. Equally, a limitation should not obscure useful supported work: attended guidance can still solve a real problem.