Ping any host from your Mac, iPhone or iPad

Ten real ICMP echo requests on the Mac DMG, TCP-connect probes everywhere else — with the latency, packet loss and jitter you can actually act on.

Download SSHive Free All network tools

A page takes eight seconds to load, an SSH session freezes halfway through a command, a video call turns into a slideshow. Before you touch anything else, you need two numbers: how long a round trip to the host actually takes, and how many probes never came back. That is what ping gives you, and it is still the fastest way to separate "the server is down" from "the path to the server is bad". Getting those numbers on Apple hardware is harder than it should be. macOS shipped Network Utility with a Ping tab for years; it was deprecated in Big Sur, stopped working in Monterey, and is no longer present on current macOS releases. Terminal is still there, but it is an awkward detour when you are already working inside a session manager. On iPhone and iPad there is nothing to open at all: iOS exposes no shell to users, so `ping` is not a command you can run, only a capability an app has to implement. SSHive implements it on all five targets it ships on: iPhone, iPad, the macOS direct-download DMG, the Mac App Store build and Windows. It does so with two different engines, and the distinction matters enough that the app labels it in the interface. On the macOS DMG, SSHive runs the system `ping` binary and streams genuine ICMP echo requests and replies — ten of them, verbatim. On the Mac App Store build, on iPhone and on iPad, the App Sandbox and iOS itself deny the raw ICMP sockets that would be required, so SSHive falls back to a TCP-connect probe against port 80 and times the handshake instead. The Windows build runs that same TCP probe — not because Windows forbids ICMP, but because SSHive ships one sandbox-safe implementation for every build outside the macOS DMG. The Ping card carries a small TCP badge whenever that is the engine running. The tool is free on every platform. None of SSHive's network tools sit behind a Pro licence check, and there are no ads and no account.

What SSHive does

Real ICMP on the macOS DMG

On the direct-download Mac build, SSHive spawns the system ping binary with a fixed count of ten echo requests and streams its raw output line by line into a monospace pane. You get the genuine BSD format — icmp_seq, ttl and time on every reply, followed by the native statistics block with packet loss and round-trip min/avg/max/stddev. Nothing is reformatted or summarised away.

TCP-connect probing where ICMP is refused

On the Mac App Store build, on Windows, on iPhone and on iPad, SSHive opens a TCP connection to port 80 and times the handshake instead. Ten probes on desktop, twenty on iOS and iPadOS, one second apart, each with a three-second timeout. On desktop, the card header shows a TCP badge so you always know which engine produced the numbers in front of you. On iPhone and iPad the TCP probe is the only engine there is, so there is no badge to show.

A refused connection still counts as reachable

A TCP reset is proof of life: the host received your SYN and answered it. On the Mac App Store, Windows and DMG desktop builds, SSHive counts a refused connection as a successful probe and annotates the line as a closed port rather than marking it lost. On iPhone and iPad a reset is currently recorded as a failed probe, so a host that answers with RST on port 80 shows up as packet loss there. That distinction stops you from reporting a firewall policy as an outage when the machine is up and simply is not serving HTTP on port 80.

Readable results on iPhone and iPad

The iOS and iPadOS view is not a log dump. Four stat cards show sent, received, loss percentage and average RTT; a bar chart plots every probe in order, successes green and failures red, so a burst of loss or a rising latency trend is visible at a glance. Below it, each probe is listed newest-first with its sequence number and RTT.

Streaming runs you can stop

Desktop output arrives line by line while the run is still in progress, with a Running pill in the card header and auto-scroll on the log pane. Stop cancels immediately instead of waiting out the remaining probes — useful when a host is timing out and each probe costs three seconds. On iPhone and iPad a toolbar button clears the previous run's results.

Free on every platform

Ping is not a Pro feature anywhere. None of SSHive's six network tools sit behind the licence check on Mac, Windows, iPhone or iPad — they run in the free tier, with no ads and no account to create. SSHive Pro is a separate one-time purchase that lifts the free-tier limits and unlocks RDP and VNC sessions, remote tunnels, broadcast and the rest — not the diagnostics.

How to do it, step by step

1
Open Network Tools on Mac or Windows
In the macOS or Windows app, click the network icon in the left sidebar — its tooltip reads Network Tools — or click the Network tools pill on the Welcome screen. Either opens a dedicated Tools tab alongside your sessions, holding the whole diagnostics panel. Ping is the first of the three full-width cards at the bottom of that panel.
2
Or open the Tools tab on iPhone and iPad
On iPhone, tap Tools in the bottom tab bar — the network icon — then choose Ping, the first row of the Diagnostic section. On iPad, open Network tools in the split-view sidebar and pick Ping from the same list. The tool behaves identically on both; only the navigation layout differs.
3
Enter the host to probe
Type a hostname or an IP address into the field — the desktop placeholder suggests something like google.com. Remember that on every build except the macOS DMG the probe targets TCP port 80, so choose a host you expect to be listening there if you want a meaningful reachability answer.
4
Run the test and watch it stream
Press Ping on desktop, or start the run on iOS. The desktop log fills line by line in a monospace, auto-scrolling pane while a Running pill shows in the header; Stop cancels on the spot. On iPhone and iPad the four stat cards and the RTT bar chart update probe by probe as the twenty results arrive.
5
Read the summary
On the macOS DMG, read the native statistics block: packets transmitted and received, loss percentage, and round-trip min/avg/max/stddev. On the TCP engine you get probes sent, replies received, loss percentage and rtt min/avg/max. On iOS the same figures sit in the Sent, Received, Loss and Average cards above the per-probe list.

How to read a ping result without fooling yourself

Start with the spread, not the average. A run reporting min/avg/max of 24/26/28 ms describes a healthy path. One reporting 24/58/410 ms has the same floor but is queueing badly somewhere, and the average hides it. On the macOS DMG the BSD statistics line gives you a fourth number, stddev — that is your jitter figure. A few milliseconds is fine; a standard deviation approaching or exceeding the mean means the path is unstable, and anything real-time (VoIP, remote desktop, interactive SSH typing) will feel bad even while bulk downloads still complete normally. Packet loss needs context, and the percentage alone is nearly useless. Look at the icmp_seq values or the probe order to see the shape of it. Ten probes with one gap scattered in the middle is 10% on paper, but it is usually a single ICMP packet deprioritised by a router that had better things to do; TCP retransmits it and you never notice. Ten probes where numbers 4, 5, 6 and 7 vanish in a row is a different animal — a link flap, a re-route, or a Wi-Fi roam — and it will visibly stall an interactive session. On Wi-Fi and cellular, occasional isolated loss is routine. Sustained loss on a wired path is a fault worth chasing. Read the ttl field too. Hosts start at 64 (Linux, BSD, macOS), 128 (Windows) or 255 (many network appliances), and every router decrements it by one. A reply with ttl=52 came from something that started at 64 and crossed twelve hops: a quick sanity check that you are talking to the machine you think you are, and a hint about which OS family answered. The first probe is often the slowest. Blame ARP or neighbour discovery, DNS resolution and a cold route cache — not the server. Judge the run from the second probe onward. Finally, do not read 100% loss as "down". Plenty of hosts, CDNs and edge networks drop ICMP echo by policy. And on the TCP engine the semantics change completely: you are timing a three-way handshake to port 80, so every value carries connection-setup cost on top of the true network round trip, and a host that simply is not listening on 80 reports total loss while being perfectly healthy. A closed-port annotation is the good outcome — it means the host answered with a reset.

Frequently asked questions

Can you actually ping from an iPhone?+

Yes, but not with ICMP. iOS ships no terminal and no user-accessible ping command, and Network.framework — the modern networking layer SSHive is built on — has no ICMP transport at all. SSHive's Ping on iPhone and iPad opens a TCP connection to port 80 and times the handshake, twenty probes one second apart. It answers the practical question (is the host reachable, how fast, how consistently) but it is not an ICMP echo test, and we would rather say so than pretend otherwise.

Does SSHive send real ICMP packets?+

Only on one build: the macOS version downloaded directly as a DMG. That build is unsandboxed and runs the system ping binary with a count of ten, so you get genuine ICMP echo requests and the native BSD statistics block. The Mac App Store build, iPhone and iPad use a TCP-connect probe to port 80 instead, because the App Sandbox and iOS do not grant raw ICMP sockets. The Windows build shares that same TCP probe — Windows would allow ICMP, but SSHive uses one sandbox-safe implementation for every build outside the DMG. SSHive marks those runs with a TCP badge rather than hiding the difference.

A site works in my browser but ping shows 100% packet loss. Why?+

Two common causes. First, many hosts, CDNs and edge firewalls drop ICMP echo by policy — the server is fine, it simply refuses to answer that probe type. Second, if you are on the TCP engine, SSHive probes port 80 specifically; a host that only serves HTTPS on 443, or that firewalls 80, reports total loss while being perfectly healthy. Cross-check with a DNS lookup to confirm you are testing the address the browser actually reaches before concluding anything is down.

Why can't I change the port, the probe count or the packet size?+

Those options are not exposed on any platform. The TCP engine is hard-coded to port 80; the count is fixed at ten probes on desktop and twenty on iPhone and iPad; there are no TTL, interval or packet-size settings, and no IPv6-specific mode. The DMG's ICMP path runs `ping -c 10` as-is. If you need arbitrary flags on a Mac, Terminal is still there — SSHive's Ping is built to give a fast, honest reachability answer, not to replicate every option of the CLI.

Why are SSHive's latency numbers higher than ping in Terminal?+

Because on the TCP engine you are not measuring the same thing. An ICMP echo is answered by the target's network stack almost immediately. A TCP probe has to complete a three-way handshake, and the target's listener backlog, the OS scheduler and any middlebox on the path all add to it. Expect TCP-connect values to sit above the equivalent ICMP round trip for the same host. Compare a host against itself over time rather than comparing one engine to the other.

How much packet loss is actually a problem?+

The pattern matters more than the percentage. Isolated single losses on Wi-Fi or cellular are routine and TCP retransmits them invisibly. Several consecutive losses point to a link flap, a re-route or a Wi-Fi roam and will visibly stall interactive sessions. Sustained loss on a wired path is worth investigating. And loss measured only against the ping target, while throughput elsewhere stays normal, usually means ICMP rate-limiting on that host rather than a real network fault.

Is the Ping tool free, or part of Pro?+

Free, on every platform. None of SSHive's six network tools — ping, traceroute, DNS lookup, whois, MX lookup and DNSBL check — sit behind a licence check on Mac, Windows, iPhone or iPad. SSHive Pro is a separate one-time purchase (around 9.99 USD, Universal across Mac, iPhone and iPad, no subscription and no account) that unlocks SSH, RDP and VNC sessions, profiles, tunnels and related features. The diagnostics run in the free tier, with no ads.

Why ICMP is a privilege, and what SSHive does instead

Ping is not one thing. The classic tool sends an ICMP Echo Request (type 8) and waits for an Echo Reply (type 0), matching them by identifier and sequence number and subtracting timestamps. ICMP has no ports and no ordinary sockets; to emit one you need either a raw socket or, on Darwin, a datagram ICMP socket (SOCK_DGRAM with IPPROTO_ICMP). Historically that meant root. On modern macOS the setuid bit is gone from /sbin/ping — Darwin lets any process open an unprivileged datagram ICMP socket (SOCK_DGRAM with IPPROTO_ICMP), which is exactly what the system ping binary uses. /usr/sbin/traceroute, by contrast, is still installed setuid root. That is exactly the privilege the App Sandbox does not hand out. A sandboxed Mac App Store application gets com.apple.security.network.client, which authorises outbound TCP and UDP connections. It does not authorise raw or datagram ICMP sockets, and it does not let you spawn a setuid helper. iOS is stricter still: Network.framework, the networking layer SSHive builds on, exposes TCP, UDP, QUIC and TLS. There is no ICMP transport in that API at all. An iOS app that advertises "ping" is therefore either vendoring Apple's ageing SimplePing sample against raw BSD sockets, or doing what SSHive does. SSHive splits the implementation cleanly by build. The direct-download macOS DMG is not sandboxed, so it spawns the system ping binary with a fixed argument array — ping, -c, 10, hostname — through a process spawn with shell interpolation disabled, and pipes stdout and stderr straight to the interface over IPC. You get real ICMP because the system binary opens an unprivileged datagram ICMP socket that Darwin permits outside the sandbox, and passing arguments as an array rather than a command string means a hostname can never be turned into a shell injection. The one caveat worth knowing: the binary is invoked by name, so it has to be on PATH. Everywhere else, SSHive measures TCP reachability instead. On Windows and in the Mac App Store build it opens a Node socket to port 80, ten probes, one per second, with a three-second socket timeout, and takes the round trip as the wall-clock delta between issuing the connect and the socket becoming usable. On iPhone and iPad the same idea runs on Network.framework: an NWConnection to port 80 over TCP, the timer stopped the moment the connection reaches its ready state, a cancellation task firing at three seconds, and results yielded one at a time through an AsyncStream so the chart and the stat cards fill in live. iOS runs twenty probes rather than ten, which gives the bar chart enough points to make a trend visible. The trade-offs are real and worth stating plainly rather than burying. The port is hard-coded at 80 on every TCP path; you cannot choose it. Latency includes TCP handshake cost, so values run higher than a true ICMP round trip against the same host. A host that answers ICMP but drops port 80 reads as 100% loss. There are no TTL, packet-size, interval or count options on any platform, and no IPv6-specific mode is exposed. On iPhone and iPad the address shown next to each probe is the string you typed, not the resolved IP. What you get in exchange is a consistent, honest reachability and latency signal on every Apple device you own — including the two where the operating system will never permit anything better.

Related tools

Trace the route hop by hop, and find where it actually breaks

A real system traceroute on macOS and Windows, streamed line by line — plus the part nobody explains: how to read what comes back.

Resolve a domain name without opening a terminal

A, AAAA, MX, CNAME, NS and TXT in one query on macOS and Windows — A and AAAA on iPhone and iPad. Free on every platform, no ads, no account.