What Is Remote Viewer?

Remote Viewer is a cross-platform remote access and support platform built for businesses and Home that need one consistent way to reach, monitor and assist devices across desktop, mobile and web. It is designed for MSPs, internal IT teams, helpdesks, support engineers and service providers that manage mixed fleets and need a single operational model instead of separate tools for each operating system.

At its core, Remote Viewer is built around a broker-based session architecture. Endpoints register out to the Remote Viewer infrastructure, technicians connect using session credentials, and communication is routed centrally rather than relying on direct inbound access to the customer device. That approach keeps deployment simple, works well behind NAT and firewalls, and allows Windows, macOS, Linux, iPhone, iPad and Android devices to sit inside the same support ecosystem.

What makes Remote Viewer different is that it is not just a viewer. It combines remote screen delivery, technician access, session tracking, chat, file operations, terminal or command execution, company account management and browser-based access into one joined-up system.

How the Platform Is Structured

Remote Viewer is made up of several coordinated parts:

Broker Middleware

The Broker is the traffic and session layer for the entire product. It accepts client registrations, manages technician sessions, tracks live connection state, routes screen and command traffic, and exposes web API endpoints for client lookup, technician presence, health monitoring and session metadata.

Desktop and Mobile Clients

Each operating system has its own native client implementation, built around what that platform allows. Some platforms are focused on unattended desktop support, some on attended screen sharing, and some on technician-side control.

Technician Interfaces

Remote Viewer includes technician-facing control surfaces in native desktop apps and in the browser, giving support staff more than one way to connect to devices.

Customer Portal

The web portal provides account login, registration, verification, company-based device visibility and administrative device actions.

Web Viewer

The browser viewer gives technicians a no-install route into live sessions, including screen viewing, session connection, screen switching, chat and browser-based input handling for supported endpoints.

What Remote Viewer Does

Remote Viewer is designed to give support teams a consistent workflow across very different platforms. Depending on the target OS, the system can provide:

live screen streaming
technician remote control
session ID and password access
multi-screen selection
chat between technician and user
remote terminal or command execution
remote file browsing and file operations
device inventory and company-based access
browser-based technician sessions
persistent background presence through services, daemons or foreground services depending on platform

The important part is that this is not one generic client compiled everywhere. Each operating system has been implemented in a platform-specific way to match the realities of that OS.

Windows Application

The Windows side is the most layered desktop implementation in the current product. It is not just a single app; it is a coordinated Windows stack made up of:

a Windows Service for persistence, broker connectivity and session orchestration
a Windows App for the user-facing client and technician UI
a Windows Session Helper for session-aware screen hosting and desktop-state handling
a Windows KVM/HID driver path used for low-level input injection support

What the Windows app does

The Windows app includes both the endpoint/client experience and a technician console. It exposes a full technician workspace with dedicated areas for:

Home / device session information
Screens
Files
CMD / command output
Chat

From the codebase, the Windows technician experience supports live screen viewing, multi-screen switching, mouse movement, mouse button events, wheel input and keyboard injection using HID-style key routing. It also includes remote chat, device/session info panels, public IP and location display, and a company device list retrieved after account login.

File management on Windows

Windows includes one of the fullest file-operation stacks in the project, with support for:

drive and directory enumeration
upload (In Progress)
download (In Progress)
rename
move
delete

The transfer model is chunked and session-aware, which fits larger transfers and multiple technician sessions better than a simple one-shot copy model.

Command execution on Windows

The Windows endpoint supports remote command execution through CMD, with streamed output, error output, end-of-message handling and working-directory tracking so the technician sees command results in an ongoing console-style flow rather than a one-off popup response.

Windows session awareness

One of the strongest parts of the Windows architecture is its awareness of actual Windows session state. The service tracks desktop and session transitions and distinguishes between states such as:

booting
no logged-in user
locked
logged-in desktop activity

That means the Windows build is aimed not only at in-session support, but also at remaining aware of what the machine is doing during boot, lock and logon transitions.

Why the Windows architecture matters

In practical terms, Windows is built for unattended support. The service stays resident, the app provides the UI surface, and the helper/session components exist specifically because Windows remote support gets harder when the machine moves between service context, user session, lock screen and active desktop. Remote Viewer’s Windows design reflects that reality.

macOS Application

The macOS version is a native Swift implementation and, like Windows, is more than a simple app bundle. The macOS side is split into:

the main macOS app
a daemon
agent processes for Aqua and Login Window sessions
an installer layer with launchd plists and lifecycle scripts

What the macOS app does

The main macOS application includes both a user-side app experience and a technician-facing interface. It supports:

account login and session restore
company-aware device access
technician chat
live screen viewing
input capture for remote control
command execution
remote file browsing and file operations
keychain-backed credential persistence
Screen capture and control on macOS

The macOS code uses ScreenCaptureKit for live screen delivery and uses native macOS event APIs for input control. The codebase also explicitly checks for and prompts around macOS accessibility and post-event permissions, which is critical on Apple platforms because reliable input control depends on those security approvals being granted.

LoginWindow and Aqua awareness

A big strength of the macOS design is that it is not limited to just the signed-in desktop. The installer and daemon coordinate hidden agents for both:

LoginWindow
Aqua

That gives the platform a stronger unattended-access model than a normal single-user Mac app. The daemon watches the current console state, bootstraps the right launch agents and keeps the right runtime loaded depending on whether the Mac is sitting at the login window or a user desktop.

File and command capabilities on macOS

The macOS technician UI includes remote file browsing and operational actions such as rename, move and delete, alongside command execution through a shell-style panel. The terminal experience is presented as a live session view, not just a one-command utility.

What this means in practice

Remote Viewer on macOS is aimed at real support work, not just passive viewing. It is built to remain present across session changes, support live screen workflows using Apple’s modern capture stack, and provide technician tools inside a native Mac interface.

Linux Client

The Linux client is a .NET-based endpoint focused on practical remote support for Linux desktops and servers.

What the Linux build does

The Linux code supports:

broker registration
technician chat routing
shell command execution
filesystem browsing
upload and download handling
rename, move and delete operations
screen streaming when a graphical environment is available
Terminal and shell support

Linux is especially strong for command-line support. The client executes shell commands through Bash and streams back:

current working directory
command output
error output
end-of-message markers

That makes it suitable for support scenarios where terminal access is more important than a full graphical session.

Linux screen delivery

When Linux is running with a GUI, the code supports graphical screen streaming using Linux-native tooling, including display discovery and PipeWire-based capture flow. That means Linux can operate in two useful modes:

server/headless style support, where command and file access matter most
desktop support, where live screen streaming is needed
File operations on Linux

The Linux client implements a proper remote file workflow rather than basic directory listing only. It includes upload, download, rename, delete and move handling, which makes it more capable than a simple terminal agent.

Best fit

Linux is especially well suited to infrastructure, servers, technical workstations and mixed GUI/headless estates where technicians need terminal-first support but still want the option of live screen delivery on graphical machines.

iOS Application

The iOS build is a native SwiftUI app paired with a ReplayKit Broadcast Extension and a Broadcast Setup UI extension.

What the iOS app does

The iPhone and iPad implementation is designed around attended screen sharing in a way that fits Apple’s platform rules. The app provides:

account login against the Remote Viewer portal
company-linked session state
device count visibility for the logged-in account
a broadcast start flow
live display of the generated client ID and password
shared app-group storage so the app and broadcast extension can work together
How iOS remote support works here

On iOS, the app does not try to behave like a desktop remote-control agent. Instead, it uses ReplayKit broadcasting so the user deliberately starts a screen-sharing session, after which the extension registers with the broker and begins sending encoded frames.

The broadcast extension handles:

broker registration
session credential updates
frame preparation
JPEG encoding and resizing
adaptive quality control
technician-aware frame cadence
Why this matters

This is the correct architecture for iOS. It respects Apple’s restrictions while still giving technicians a live view of the device during a support session.

Position of the iOS app in the product

The iOS build is best described as a secure attended screen-sharing client for iPhone and iPad. It is ideal for support, walkthroughs and live viewing, while remaining compliant with the platform’s limitations.

Android Application

The Android version is a native app built around a foreground service and MediaProjection capture.

What the Android app does

The current Android codebase is centred on attended screen broadcast and session presence. It includes:

account login tied to the Remote Viewer portal
company-linked registration data
a foreground service for persistent capture
MediaProjection-based screen capture
technician count display
live connection timer
generated ID and password display for the current session
Android capture model

Once the user grants capture permission, the foreground service creates the MediaProjection pipeline, starts virtual display capture, compresses frames to JPEG and streams them through the broker to connected technicians.

This gives Remote Viewer an Android implementation that is practical for real-time support without requiring rooting or non-standard deployment.

What the current Android build is best suited for

As the code stands today, Android is best described as a live mobile screen-sharing client rather than the more feature-heavy unattended desktop-style endpoint seen on Windows and macOS. Its present strength is attended technician viewing with solid session visibility and device registration.

Web Viewer

Remote Viewer also includes a browser-based technician viewer, which is important because it lowers the barrier to support.

What the Web Viewer does

The browser viewer provides:

session connection by client ID and password
live screen display
screen switching
fullscreen mode
fit-to-screen mode
technician chat
browser-side mouse and keyboard event handling
session lifecycle controls such as connect and disconnect
Why it matters

This means technicians do not always need to install a native app just to reach a device. For many support flows, especially quick access or lightweight deployments, the browser becomes the technician console.

Customer Portal

The web portal is the account and company administration side of Remote Viewer.

What it provides

The portal includes:

login
registration
email verification
secure session handling
dashboard views
company device visibility
device actions and administration

This matters because Remote Viewer is not only a point-to-point support tool; it is also structured for account-based, company-based deployment.

Security and Session Model

Remote Viewer is designed around a routed session model rather than direct inbound exposure. In practical terms, that means the product is built to avoid the usual complexity of opening ports, dealing with direct peer-to-peer exposure or forcing customers onto VPN-based workflows just to receive support.

Across the codebase, the recurring patterns are:

outbound client registration
broker-routed communication
per-session identifiers
technician session tracking
company-scoped device access
persistent service or daemon presence on supported platforms
platform-native permission handling where OS security requires it

That architecture is one of the product’s biggest strengths because it allows very different device types to sit behind the same operational model.

Why Remote Viewer Stands Out

Remote Viewer is not trying to be a clone of a single-platform remote desktop tool. It is being built as a full remote support platform with different native strategies for different operating systems.

Windows is built for deep unattended support with service, session and technician tooling.
macOS combines a native app, daemon and hidden agents for stronger session coverage.
Linux delivers terminal, file and optional GUI support in a lightweight client.
iOS provides Apple-compliant attended screen broadcasting through ReplayKit.
Android provides attended live screen streaming through MediaProjection and foreground services.
Web gives technicians a zero-install access path.
Portal and Broker tie the whole product together into a company-ready system.

The result is a platform that is broader than a standard remote desktop app and more unified than using separate tools for each operating system.

Summary

Remote Viewer is a multi-platform remote support system built around a single brokered session model, with native implementations for Windows, macOS, Linux, iOS, Android and browser-based technician access.

Its desktop platforms are designed for deeper technician workflows, its mobile platforms are built around the realities of mobile OS security models, and its web and portal layers make the product usable at company scale.

In short, Remote Viewer is not just remote viewing. It is a full remote assistance platform designed to let support teams reach more devices, from more operating systems, through one connected system.

I kept that aligned to the actual codebase rather than just the current page copy. The biggest accuracy wins were making Windows/macOS more detailed, keeping iOS clearly broadcast/view-only, and describing Android as it currently exists in code rather than overclaiming full mobile control.