Start with local Wi-Fi when your devices share a network. Use the documented Tailscale route when your phone or tablet needs to reach a Mac on another network. In either case, the Mac must stay awake, Tetherly must be accepting connections, and pairing still requires matching codes and approval on the Mac.
That choice solves only the route. It does not, by itself, establish that the devices are paired or that macOS permits desktop capture and input. This guide gives you a sequence for checking those layers without changing several things at once.
Tetherly connects a Mac host to Android, iPhone or iPad clients. It displays the existing Mac session rather than creating another desktop. Use the official setup page for current installation links and platform instructions.
Choose the route before changing settings
| Your situation | Start with | What must be true |
|---|---|---|
| Mac and client are on the same home network | Local Wi-Fi / local network | The network allows the devices to communicate; the Mac can use Ethernet on that same network |
| Client is on another Wi-Fi network or mobile data | The documented Tailscale connection flow | Both devices have Tailscale connected in the intended tailnet, and the Mac remains online |
| The Mac does not appear in a list | Check discovery, then try a documented manual address | A missing discovery result is not enough to identify the failed layer |
| The Mac is asleep | Arrange for the host to remain awake before relying on access | Tetherly does not wake a sleeping Mac remotely |
A local session does not need Tailscale or internet connectivity. A remote route through Tailscale uses a separate service and account; Tetherly itself does not require an account. These are distinct arrangements, not two names for the same login. The repository README describes the client/host model and its current platform targets.
Treat “same network” as something to check, not just the Wi-Fi name on a screen. The connection guide notes that guest and managed networks can isolate devices. A manual address can bypass a discovery problem; it cannot make an isolated host reachable.
Prepare the host and permissions
Open Tetherly from the Mac’s menu bar. A missing Dock window does not mean the host has stopped: its controls live in the menu bar. Check that you are using the intended copy of the app, especially if you also run development builds.
The first-connection documentation separates permissions by purpose:
| Permission or prompt | What to check |
|---|---|
| Screen Recording on the Mac | Allows desktop capture; macOS may use the label Screen & System Audio Recording |
| Accessibility on the Mac | Allows pointer and keyboard control |
| Local Network, when requested | Allows nearby discovery and connections; check the client as well, including iPhone/iPad |
| Incoming connections in the Mac firewall | Allow the Tetherly host rather than disabling the firewall as a troubleshooting shortcut |
| Camera on the client | Needed when using QR scanning; the setup guide also describes non-QR pairing |
Follow the app’s setup prompts and reopen it when macOS requests that. Granting capture access and granting input access are separate tasks. If the desktop becomes visible but typing still fails, changing the network route is not the next useful experiment.
Establish one local session before leaving
When possible, complete a nearby session first. It gives you a known starting point for later comparison.
- Put both devices on the same local network. Open the Mac host and enable Allow connections.
- Choose Pair New Device on the Mac. In the client, scan the displayed QR code, select the nearby Mac, or use an address shown by the Mac app.
- Compare the short codes on the actual two devices. Confirm the match on the client, then approve that client on the Mac. Cancel if they differ.
- Confirm that the desktop appears, then try pointer movement and typing in a disposable note. Check those separately so you know what worked.
- For the next session, select the already-paired Mac and use Connect. Do not start a fresh pairing merely because you want to reconnect.
A QR scan is a way to begin pairing, not a replacement for code comparison. These steps follow the public setup sequence and the repository’s pairing instructions.
Add Tailscale as the route, not a replacement for pairing
Before going away, follow the Tailscale section of the official setup page. Install and connect Tailscale on the Mac and client, use the same Tailscale account as instructed there, and confirm that both devices are online in the intended private network, called a tailnet. Follow its permission prompts, including VPN permission on the mobile client.
With Tailscale active on both devices, complete Tetherly pairing nearby. If the devices are already paired, make a connection while Tailscale is enabled so the client can learn the Mac’s Tailscale route. Then try the paired Mac from another client network, leaving the host awake, online, running Tetherly and accepting connections.
For this documented device-to-device arrangement, the project does not require an exit node or router port forwarding. A managed tailnet must permit the client to reach the Mac on TCP port 47800. Ask its administrator to check that policy rather than opening a public router port.
The repository’s remote connection instructions describe this as the supported source flow and explicitly distinguish it from completed cellular acceptance testing. Following the procedure is a setup attempt, not evidence that every remote scenario has been verified.
Diagnose the symptom you actually have
Change one thing, retry the same small check, and record the result. The project’s troubleshooting guide is the reference for current recovery steps.
The Mac is absent from Nearby. Check host wakefulness, the running menu bar app, hosting and Local Network permission. For remote access, check both tailnet devices’ online state. A missing Bonjour discovery result does not require another pairing or prove that the host is unreachable.
A known address still will not connect. Use the address appropriate to the route. A local address shown on the home network and a Tailscale address serve different paths. The manual-address guidance explains where to obtain the Mac’s Tailscale IPv4 address and when a configured MagicDNS name can be used. Enter the address from your Mac or Tailscale rather than guessing one.
The session connects but the desktop is missing. Check the capture permission and the app’s error text. Reaching the host does not establish permission to capture its screen.
The desktop appears but input fails. Check Accessibility permission for the copy of Tetherly actually running. A grant associated with another build or location may not apply to this copy. Follow the app’s permission prompts before changing networks.
Codes disagree or an identity warning appears. Stop and use the documented recovery process after verifying the intended Mac. Do not approve a mismatch. Tailscale connectivity does not substitute for Tetherly’s pairing checks.
Compare the same session on each route
For an unclear remote problem, repeat a small session locally with the same devices and app versions. Note whether viewing, input and reconnection behave differently. A local success narrows the next question; it does not establish that a remote path or another device will behave the same way.
The connection documentation distinguishes direct Tailscale paths from relayed ones. Avoid reducing every delay to that distinction: the Mac display and client decoder also matter. Tetherly’s troubleshooting notes do not publish a performance guarantee.
Read the validation record before depending on a feature
The acceptance record records local physical-Android checks separately from automated tests and Simulator runs. It still lists cellular-route testing and several device/feature checks as pending. Those are different kinds of evidence; an automated pass does not fill a real-device gap.
The README names the clients and links to distributions, while planning and getting-started documents also contain in-progress or release-preparation wording. Use the public setup page for current distribution information and the dated evidence for what was actually tested. Do not infer equal validation across Android, iPhone and iPad from the existence of a client.
The plan and release gates still identify independent review of the pairing protocol as outstanding. This article is documentation-based guidance, not a security assessment. Windows/Linux hosts, folder synchronization and remote filesystem browsing remain outside the stated scope.
Leave the next investigation with useful evidence
Before asking for help, record the app/build versions, device models, operating systems, chosen route and exact failing step. Say whether the Mac was listed, whether a manual address was tried, whether pairing completed, and whether viewing or input worked locally. Keep the Mac awake while reproducing the same small sequence.
Use the repository’s support-report guidance. Remove private desktop content, clipboard text, pairing codes, QR links and key material from shared evidence. Route security reports through the project’s security policy rather than a public issue.
For the product overview, visit Tetherly on datahase. The existing Tetherly product study explains the broader user journey; our open-source page links the repository and licensing. Return to the official setup guide for installation and current support instructions.
Documentation checked on 5 November 2026. No new physical-device or remote-session testing was performed for this guide.