Skip to main content
Download

Ping any host from your Mac, iPhone or iPad

Real ICMP echo requests on Mac, iPhone and iPad alike, with the latency, packet loss and jitter you can actually act on.

By Lucas Russo, developer of SSHive · Updated

Download SSHive FreeAll network tools
Also on iPhone and iPad
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 itself on every Apple platform it ships on: iPhone, iPad and the Mac App Store build. All of them send genuine ICMP echo requests (ten on the Mac, twenty on iPhone and iPad) and report the round-trip time of each reply, the TTL it came back with, and how many never returned. That is worth spelling out, because it is widely assumed to be impossible inside Apple's App Sandbox. The assumption confuses two different things. A raw socket does need root and the sandbox does refuse it. A datagram ICMP socket (socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP)) needs neither: Darwin hands it to unprivileged processes, and the sandbox permits it. It is the same mechanism Apple's own SimplePing sample code uses on iOS. SSHive opens that socket directly, so the sandboxed App Store build measures real round trips rather than an approximation. A TCP-connect probe against a port you choose is still available, and it is the right tool when ICMP is filtered end to end. It is a deliberate choice in the interface, not a silent substitution: the card tells you which engine produced the numbers you are reading. 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 every Apple platform

SSHive sends ICMP echo requests (ten on the Mac, twenty on iPhone and iPad) from an unprivileged datagram socket and streams each reply as it lands, in the familiar BSD shape: sequence number, TTL and round-trip time per line, then a closing block with packet loss and min/avg/max/stddev. The same engine runs in the Mac App Store build, on iPhone and on iPad, so the numbers are comparable across your devices. Replies are matched on four criteria, including a random eight-byte cookie in the payload, because a datagram ICMP socket also receives copies of other processes' replies.

TCP-connect probing where ICMP is filtered

Plenty of hosts drop ICMP at the edge while serving traffic perfectly well, and a firewall that swallows echo requests makes a healthy server look dead. For those, SSHive can open a TCP connection to a port you name and time the handshake instead. The card labels the run with a TCP badge, so a reachability check is never mistaken for a latency measurement. It is also the automatic fallback if the native ICMP module cannot be loaded.

A refused connection still counts as reachable

When you deliberately pick the TCP engine, a reset is proof of life: the host received your SYN and answered it. SSHive counts a refused connection as a successful probe and annotates the line as a closed port rather than marking it lost. That distinction stops you from reporting a firewall policy as an outage when the machine is up and simply is not listening on the port you chose.

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, 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. 1

    Open Network Tools on the Mac

    In the macOS app, click the network icon in the left sidebar (its tooltip reads Network Tools), or 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 card of its Reachability section, at the bottom of that panel.

  2. 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. 3

    Enter the host to probe

    Type a hostname or an IP address into the field; the placeholder suggests something like google.com. ICMP is the default and needs no port. If you switch to the TCP engine because the host filters ICMP, that is when the port matters: pick one you expect the host to be listening on.

  4. 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. 5

    Read the summary

    Read the closing statistics block: packets transmitted and received, loss percentage, and round-trip min/avg/max/stddev. On the TCP engine the same four figures appear, minus the standard deviation. On iPhone and iPad they 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. The 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, and a traceroute helps you find the hop where it begins. 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 the port you picked, so every value carries connection-setup cost on top of the true network round trip, and a host whose firewall silently drops that port 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, with real ICMP. iOS ships no terminal and no user-accessible ping command, and Network.framework, Apple's high-level networking API, has no ICMP transport, which is why many iOS apps quietly substitute a TCP handshake. SSHive drops below that API to a BSD datagram socket, socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP), the same one Apple's own SimplePing sample uses. It needs no jailbreak and no special entitlement, and it sends genuine Echo Requests. A TCP probe is still offered for hosts that filter ICMP, clearly labelled as such.
Does SSHive send real ICMP packets?+
On every Apple build: the Mac App Store version, iPhone and iPad all send genuine ICMP Echo Requests and read the Echo Replies, ten probes on the Mac and twenty on iPhone and iPad, with per-reply TTL and round-trip time. There is no second-class build. The TCP-connect probe still exists, but as an explicit choice for hosts that filter ICMP, and when it runs, the card carries a TCP badge so a reachability check is never mistaken for a latency measurement.
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. That is exactly when to switch to the TCP engine and aim at a port the host really serves. Second, if you are already on the TCP engine, check the port: a host that only serves HTTPS on 443 reports total loss on port 80 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.
Can I change the port, the probe count or the packet size?+
Mostly not. You choose the engine (ICMP or TCP) and, on the TCP engine, the port. Beyond that the run is fixed: ten probes on the Mac, twenty on iPhone and iPad, with no packet-size, interval or count settings. IPv6 destinations are handled automatically rather than through a separate mode. If you need arbitrary flags on a Mac, Terminal is still there; SSHive's Ping is built to give a fast, honest 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) sits behind a licence check on Mac, iPhone or iPad. SSHive Pro is a separate one-time purchase (about $12.99, a Universal Purchase across Mac, iPhone and iPad, no subscription and no account) that lifts the free-tier limits on SSH sessions, profiles and tunnels and unlocks RDP and VNC. 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. The received wisdom is that Apple's App Sandbox forbids all of this. It does not, and the distinction is worth getting right. A sandboxed Mac App Store application holds com.apple.security.network.client, which authorises outbound TCP and UDP. A raw socket is genuinely refused, and so is spawning a setuid helper. A datagram ICMP socket is a different object, and the sandbox lets it through. That was measured rather than assumed, under sandbox-exec with the app's real entitlements, and the result contains a trap. With network.client alone, socket() succeeds and sendto() succeeds, but recvfrom() returns EPERM. The probe leaves and never comes back, which looks exactly like a network that filters ICMP and debugs miserably. Both network.client and network.server are required for the full cycle. SSHive declares both, which is why ping behaves identically inside and outside the sandbox. iOS looks stricter and, at the level most apps work, it is: Network.framework exposes TCP, UDP, QUIC and TLS, and has no ICMP transport whatsoever. That is why so many iOS apps advertising a "ping" are quietly timing a TCP handshake. But Network.framework is not the floor. The BSD socket layer underneath it is still present and still permitted, and socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) is precisely what Apple's own SimplePing sample opens. SSHive opens it too, with IPPROTO_ICMPV6 for IPv6 destinations. So there is one behaviour to learn, not four. On macOS the work happens in a small native N-API addon; on iPhone and iPad in a Swift type built on the same socket. Both assemble the Echo Request themselves, compute the ICMP checksum, and set IP_TTL when a traceroute needs it. Both match replies on four criteria (identifier, sequence number, source address, and a random eight-byte cookie carried in the payload) because a datagram ICMP socket receives a copy of every ICMP reply the machine gets, including replies meant for other processes. Two simultaneous runs against different hosts do not contaminate each other. The TCP-connect probe has not disappeared; it has been demoted to what it always should have been. Plenty of hosts drop ICMP at the edge while serving traffic perfectly, and for those a handshake against a port you name is the honest measurement. It is offered as a deliberate choice, labelled with a TCP badge, and used automatically only if the native ICMP module fails to load. Its trade-offs stand: latency includes handshake cost, so the figures run higher than a true ICMP round trip against the same host, and a host that answers ICMP but drops your chosen port reads as total loss.

Related tools

Traceroute

DNS lookup