At an event, the operator needs the next slide to advance once, in the intended presentation. A full desktop pointer can prototype the interaction, but it also makes the wrong window easy to control. A dedicated controller should reduce possible actions and make uncertainty visible.
Illustrative custom implementation, not an existing Tetherly slide API. The buyer is an event or training team with a specific presentation application and a local operator. Venue Wi-Fi, guest isolation and crowded networks cannot be assumed reliable.
Rehearse the real setup before the audience arrives
Pair before the event, rehearse the venue network and displays, then verify the presentation/application identity. The local operator should retain a physical keyboard or another rehearsed local control. A fallback that nobody can reach is not an operational fallback.
Apple's Keynote remote guide documents a platform presentation workflow, including linking and local-network considerations. Its platform-specific connectivity behavior does not establish Tetherly behavior or feature parity. The proposal here needs its own application integration and venue test; it does not reproduce Apple's setup sequence.
Define the allowed actions and command lifetime
The first surface might offer next, previous and start, with large labeled touch targets and screen-reader names. Stop accepting commands if app identity, focus or connection state becomes uncertain. More buttons are not automatically more useful when the operator cannot inspect the result.
| Command-envelope field | Proposed enforcement |
|---|---|
| session_id | Bind input to the current authorized event session |
| sequence_number | Detect duplicate delivery within that session |
| action | Enforce a small allowed-action list outside the interface |
| app_target | Verify the intended presentation application/context |
| expires_at | Reject stale commands after delay or reconnect |
Acknowledge each accepted command and distinguish accepted, applied and uncertain where the integration can observe them. A transport acknowledgement alone does not establish that the audience saw the intended slide. If application state cannot be read, label that limitation instead of showing a fabricated success state.
Walk through a lost acknowledgement
Synthetic rehearsal. Command 24 advances the demo deck, but its acknowledgement is lost. The phone displays uncertain state and reconnects. It must not blindly replay command 24 or queue several new advances while disconnected.
Retain deduplication within the agreed session lifetime, expire the old envelope and reconcile with authoritative presentation state where available. If that state cannot be established, require local confirmation before resuming. For a generic keyboard shortcut, exactly-once application behavior may not be knowable; a supported app integration can offer a stronger state contract, but that is additional engineering.
Double taps are a different issue from duplicate packets. Decide whether two intentional taps mean two advances. Avoid an arbitrary debounce that silently discards legitimate builds. Rehearse the chosen feedback with the real operator, including how an uncertain result is resolved.
Guard focus at dispatch and handover
Verify the application/context close to command execution, not merely when the controller opens. Suspend commands when focus changes or the display disconnects. A focus check cannot by itself eliminate every race; test whether the chosen integration targets the app directly or sends global input.
Use one active operator lock. Handover should explicitly end the old authority before enabling the new one, with visible state on both devices. At teardown, revoke event-specific access and confirm the controller cannot resume the next day using stale session state.
NIST SP 800-46 Rev. 2 supports considering authorized endpoints and policy alongside transport. A phone already trusted for a personal desktop session is not automatically an approved event controller with the right action scope.
Test failures the audience cannot wait through
| Rehearsal fixture | What must be observed |
|---|---|
| Duplicate packet or tap | Agreed input semantics; no hidden extra advance |
| Phone locks or receives an interruption | Input suspends and authority is checked before resuming |
| Wrong foreground application | No shortcut reaches an unrelated app |
| Network loss and reconnect | No stale command replay; uncertain state is explained |
| Display disconnect or operator handover | Local fallback works and old authority ends |
Record venue/network, Mac/mobile versions, app version and exact display arrangement. Evaluate input correctness, acknowledgement clarity, accessible controls and local takeover. Do not infer a guarantee over all venue networks from one successful rehearsal.
The dedicated build requires app integration or reviewed accessibility commands, allowed actions, focus verification, reconnect deduplication, operator locking and event teardown. Those are separate from Tetherly's native desktop input foundation.
The Tetherly foundation and the additional build
Tetherly brings an existing Mac session to native Android, iPhone and iPad clients. It does not create a separate virtual desktop. Its README describes screen streaming, native input and explicit clipboard/file actions. Mac pairing requires code comparison and local approval. The owned-product study explains that personal-device workflow; the connection guide covers local versus separate Tailscale reachability. This proposal addresses a different organizational task.
The Mac must remain awake. Windows/Linux hosting, remote wake and enterprise/fleet readiness are not established capabilities. Screen viewing itself can disclose confidential information, even if clipboard and files are disabled. Transport protection does not establish endpoint or pairing security. The security design says independent pairing review remains pending. It describes implemented controls, not an independent audit report.
The acceptance record distinguishes automated tests, Simulator checks, physical-device checks and owner-reported testing. Those are bounded evidence, not validation of the devices, networks or workload proposed here. The current README lists iOS availability; PLAN retains older release-gate language and is not used as availability authority. Consult official setup for current distribution and support instructions rather than copied installer links.
Scope a first evaluation
Explore the relevant development service and discuss this workflow. Bring the intended task, permitted operators, target devices and a failure scenario. These are proposed custom builds, not delivered sector features, customer stories or measured outcomes.
Sources and evidence limits
Public sources inspected 5 November 2026. Tetherly repository revision: 37aa424a482a43712e237490287bb463fd10e2b2. Apple presentation remote documentation is design context only; NIST supplies remote-access policy context, not a controller certification. The linked Tetherly documents describe current implementation and bounded evidence; this article is not an independent security review or a device-performance test.