DEV Community: Dmytro Tishchenko

What I learned building 9 network tools on iOS without entitlements

Dmytro Tishchenko — Thu, 04 Jun 2026 09:08:23 +0000

A few weeks ago I shipped NetDiag+, an iOS network toolkit — ping, traceroute,
DNS, whois, port/LAN scan — built entirely on BSD sockets through C-interop, with
no private entitlements. I wrote up the ping/traceroute internals here.

Then I spent a month adding 9 more tools. I expected "more of the same" — wrap a
socket, draw a SwiftUI list. Instead almost every tool turned into its own little
research project. Here are the parts that surprised me.

1. MTR — a continuous traceroute that can't be slow

mtr keeps probing every hop and accumulates per-hop loss + RTT stats. My first
version probed hops sequentially: TTL=1, wait for reply or timeout, TTL=2, wait…
On a 12-hop path where a couple of routers rate-limit ICMP, one cycle took 5-7
seconds. Set the interval to "1 second" and the cycle counter ticks every five.

Fix: fire all probes in a cycle at once and collect replies in a single window.
The trick is matching an incoming ICMP reply to the TTL that triggered it. I give
each probe a unique destination UDP port (base + ttl + cycle_offset). When a router
returns ICMP Time Exceeded it includes the first bytes of the original packet — UDP
header included — so I demultiplex on that port:

/// Pull the dest port out of the UDP header embedded in an ICMP Time-Exceeded
/// error, so we know which outstanding probe this reply belongs to.
static func extractInnerDestPort(from data: Data) -> UInt16? {
    let bytes = Array(data)
    let icmpHeader = 8
    guard bytes.count > icmpHeader else { return nil }
    let ihlBytes = Int(bytes[icmpHeader] & 0x0F) * 4   // inner IP header length
    guard ihlBytes >= 20 else { return nil }
    let innerUDP = icmpHeader + ihlBytes
    guard bytes.count >= innerUDP + 4 else { return nil }
    return (UInt16(bytes[innerUDP + 2]) << 8) | UInt16(bytes[innerUDP + 3])
}

Now cycle time ≈ probeTimeout, independent of how many hops are timing out.

For the stats, storing every RTT and recomputing stddev leaks memory in a tool that
runs forever. Welford's online algorithm updates mean + variance in O(1):

recv += 1
let delta = rttMs - mean
mean += delta / Double(recv)
m2 += delta * (rttMs - mean)
// ...
var stdDevMs: Double? {
    guard recv >= 2 else { return nil }
    return (m2 / Double(recv - 1)).squareRoot()
}

2. Path MTU — the obvious approach silently lied

Path MTU = the largest packet that reaches the destination unfragmented. Classic VPN
debugging: if your tunnel caps MTU at 1420 and the app sends 1500 with DF set, packets
vanish and "the internet works but half the sites don't load."

The algorithm is a binary search: send a Don't-Fragment packet of growing size, watch
for ICMP "Fragmentation Needed." My first version sent UDP to a random high port
and treated ICMP Port Unreachable as the "it arrived" signal.

Testing against 1.1.1.1 it reported Path MTU = 688 bytes — nonsense. Cloudflare
(like most well-run hosts) silently drops UDP to random ports, so Port Unreachable
never comes back. Every timeout looked like "too big" and the search converged on junk.

Rewrote it on ICMP Echo with DF. Public hosts answer pings reliably, so "it fit"
became a real signal. And when a router returns Frag-Needed it includes its next-hop
MTU (RFC 1191), so you can jump straight to the answer:

static func extractNextHopMTU(from data: Data) -> Int? {
    let bytes = Array(data)
    guard bytes.count >= 8 else { return nil }
    let mtu = (UInt16(bytes[6]) << 8) | UInt16(bytes[7])
    return mtu > 0 ? Int(mtu) : nil
}

Bonus: the discovered value hints at the link type — 1492 → PPPoE, 1480 → GRE,
1420-1440 → WireGuard, 1400 → OpenVPN/IPSec.

3. Site Reach — TCP success doesn't mean "reachable"

A tool that checks whether popular sites are reachable. Naive version: TCP-connect to
443, success = "reachable." That misses the dominant modern block.

National/corporate DPI often lets the TCP handshake complete and only injects RST after
seeing the forbidden hostname in the SNI field of the TLS Client Hello. From the
device's view, TCP connected — so a TCP-only probe reports "reachable" while HTTPS
is actually dead.

To catch it, go all the way to the TLS handshake. Two probes, compared:

TCP	TLS	Verdict
fail	fail	IP block (or DNS pointing at a dead IP)
ok	fail	SNI / TLS block — DPI killed the Client Hello by hostname
ok	ok	actually reachable

The TLS probe uses NWConnection with NWProtocolTLS, which sets SNI to the
connection's hostname automatically — exactly what trips SNI-aware DPI. Flagged sites
get an "SNI" badge so they're distinct from plain unreachable ones.

The other six, briefly

TLS Inspector — probes TLS 1.0–1.3 in parallel (one NWConnection per version, min/max pinned), shows the negotiated cipher, flags deprecated 1.0/1.1 and weak ciphers.
Encrypted DNS — resolves a domain over DoH and DoT at Cloudflare/Google/Quad9/ NextDNS, compares answers + latency. Hand-rolled minimal DNS wire codec.
STUN / NAT — real RFC 5389 Binding Request to several servers, parses XOR-Mapped-Address, classifies NAT (Open / Cone / Symmetric) by whether the external port differs per server. The signal for whether VoIP/WebRTC/P2P will work.
Bonjour browser — NWBrowser over ~20 mDNS service types (AirPlay, Chromecast, HomeKit, printers) with TXT-record parsing.
HTTP/3 (QUIC) — real QUIC handshake via NWConnection + NWProtocolQUIC with ALPN "h3" on UDP/443. URLSession won't attempt QUIC without a cached Alt-Svc hint, so this is the only honest way to check whether your network passes QUIC.
IPv6 Check — local v6 enumeration with tunnel awareness (utun → iCloud Private Relay / NAT66), NAT64/DNS64 detection (RFC 7050), v4-vs-v6 latency.

Four takeaways

The "obvious" probe usually lies. UDP-to-random-port (Path MTU), TCP-only (Site Reach) — both give false results on real networks. Only a real protocol exchange — ICMP Echo with DF, a full TLS handshake — tells the truth.
Raw ICMP/UDP on iOS is more accessible than you'd think — a SOCK_DGRAM ICMP socket needs no entitlements and covers ping, traceroute, MTR, Path MTU. Raw SYN, ARP, and packet capture are still off-limits.
Test on two networks. Half my bugs only showed up comparing a clean European Wi-Fi against a cellular CGNAT/symmetric-NAT link — the false "blocks" lived there.
Network.framework is the right tool for TLS/QUIC. Where ICMP means BSD sockets, TLS Inspector and HTTP/3 are cleaner with NWConnection: version pinning, ALPN, a real QUIC handshake — all built in.

Everything still runs without private entitlements and collects no data — results stay
on the device.

NetDiag+ on the App Store: https://apps.apple.com/app/id6761954529 (12 languages, 25 tools)

Happy to answer implementation questions in the comments.

How I implemented ping and traceroute on iOS without entitlements

Dmytro Tishchenko — Thu, 21 May 2026 10:51:49 +0000

I just shipped v1.3 of a network diagnostics app I've been building on evenings and weekends — NetDiag+. It does ping, traceroute, DNS lookups, whois, LAN scanning, port scanning, SSL cert checking, BGP/ASN lookups, plus a host monitor that does background pings and pushes a notification when something goes down.

Stack: pure SwiftUI, iOS 16+, Swift Concurrency throughout, Darwin C-interop where it has to be. No third-party networking libraries — everything on raw BSD sockets through C-interop.

Wanted to share the implementation notes I would have appreciated finding myself when I started. A few things on iOS work differently than you'd expect from a Unix background, and the gotchas aren't where you think they are.

Spoiler on conclusions: the most painful part wasn't networking, it was integrating Google's UMP consent SDK for AdMob.

ICMP ping without entitlements

The first surprise: on iOS, you can open an ICMP socket without any special entitlement and without root, which is something you'd need CAP_NET_RAW or setuid for on Linux. Apple exposed this to regular sandboxed processes through SOCK_DGRAM (not SOCK_RAW):

final class ICMPSocket {
    private let fd: Int32

    init() throws {
        fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP)
        guard fd >= 0 else {
            throw SocketError.creationFailed(errno)
        }
    }

    deinit {
        close(fd)
    }
    // ...
}

This is the same model macOS ping(8) has used since some old version when Apple dropped the setuid bit. The kernel writes the correct ICMP header for you (type/code/checksum for echo request), and rewrites the identifier to one it generates. That last bit is the first gotcha: on recv you don't get back the identifier you sent, so the standard logic of matching responses by identifier doesn't work.

The fix: match on sequence number and payload. I put my own marker in the payload and verify it on receive:

// Send
var header = ICMPHeader()
header.type = ICMPType.echoRequest.rawValue
header.code = 0
header.identifier = 0   // kernel will overwrite
header.sequence = currentSequence.bigEndian

let payload = makePayload(sequence: currentSequence)
let packet = header.bytes + payload
try socket.send(data: packet, to: address)

// Receive
let (data, fromIP) = try socket.receive()
guard let received = ICMPHeader.parse(data),
      received.type == ICMPType.echoReply.rawValue,
      received.sequence == currentSequence.bigEndian
else { continue }

Second gotcha: timeouts. recvfrom without SO_RCVTIMEO blocks indefinitely, which in Swift Concurrency means a stuck Task you then can't cancel cleanly. So I set a recv timeout on the socket:

func setTimeout(seconds: Double) {
    var tv = timeval(
        tv_sec: Int(seconds),
        tv_usec: Int32((seconds.truncatingRemainder(dividingBy: 1)) * 1_000_000)
    )
    setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, socklen_t(MemoryLayout<timeval>.size))
}

On EAGAIN/EWOULDBLOCK I throw my own SocketError.timeout, which higher up in the stack becomes a normal "timeout" hop in the result list.

Apple's SimplePing sample is the OG reference here — it's Objective-C, dated, but you can crib a lot from it. I ended up writing my own thin wrapper because SimplePing doesn't play nicely with modern Swift Concurrency and gets awkward for multi-host pings. No regrets.

Traceroute that actually works

Standard Unix traceroute has three flavors: ICMP echo (the Windows tracert style), UDP to closed ports (classic BSD), or TCP SYN (paris-traceroute, traceroute-tcp).

I tried the ICMP variant first. The idea is straightforward — send ICMP echo with a low TTL, listen for ICMP Time Exceeded from an intermediate hop, increment TTL. On paper, fine. In practice I hit two problems on iOS:

setsockopt(IP_TTL) on a SOCK_DGRAM ICMP socket behaves inconsistently. Some networks worked, others wouldn't return Time Exceeded reliably.
Matching incoming responses. On receive you get back an ICMP Time Exceeded, and the inner payload contains the original packet you sent. Matching the response to a specific TTL step means parsing inner payloads, which felt fragile.

So I switched to the classic BSD approach: UDP packets to closed ports with incrementing TTL, with a passive ICMP socket listening for Time Exceeded:

let icmpSock = try ICMPSocket()  // receive-only
icmpSock.setTimeout(seconds: timeout)

for ttl in 1...maxHops {
    let udpSock = try UDPSocket()
    udpSock.setTTL(ttl)

    var dest = address
    dest.sin_port = (port + UInt16(ttl - 1)).bigEndian  // 33434, 33435, ...

    let probe = Data(repeating: 0x40, count: 32)
    let sendTime = CFAbsoluteTimeGetCurrent()
    try udpSock.send(data: probe, to: dest)

    let (data, fromIP) = try icmpSock.receive()
    let rtt = CFAbsoluteTimeGetCurrent() - sendTime
    // ...
}

The 33434+TTL port choice is traceroute(8)'s historical pick from the 80s — those ports are unlikely to be open on the destination, so you're guaranteed to get either ICMP Time Exceeded from an intermediate hop or ICMP Port Unreachable from the destination, and both cases are handled uniformly.

Key insight: UDP_TTL works fine on iOS via setsockopt(IP_TTL), unlike the ICMP variant. The ICMP socket is purely a passive receiver — we never send from it, only read incoming Time Exceeded packets.

Final hop detection is two-way:

let isFinal = fromIP == destIP
    || header.type == ICMPType.destinationUnreachable.rawValue

Either the response came from the destination IP (meaning it sent us Port Unreachable), or the ICMP type is Destination Unreachable.

LAN scanner: no ARP for you

This is where iOS cuts harder. You don't get the system ARP table in userspace. There's no getarp(), no /proc/net/arp like on Linux. So the obvious "read the ARP table and list neighbors" idea is dead on arrival.

What you do get:

Concurrent TCP connect on common ports (80, 443, 22, 8080, etc). If a host responds (SYN+ACK or RST), it's alive. Raw SYN is locked down — only a full TCP handshake works.
mDNS / Bonjour discovery via NetServiceBrowser or NWBrowser. Partial coverage — only sees devices that advertise services.
NSLocalNetworkUsageDescription in Info.plist is mandatory. Without it, the first attempt to connect to a local IP triggers a "Local Network Access" alert, and nothing works until the user answers. Burned half an evening figuring this out the first time.

I went with the TCP connect approach via withThrowingTaskGroup:

private static let maxConcurrentProbes = 20

func discoverHosts(localIP: String, subnetMask: String) -> AsyncThrowingStream<LANDevice, Error> {
    AsyncThrowingStream { continuation in
        Task.detached {
            let range = Self.calculateSubnetRange(ip: localIP, mask: subnetMask)

            try await withThrowingTaskGroup(of: LANDevice?.self) { group in
                var activeCount = 0
                for ip in range {
                    if activeCount >= Self.maxConcurrentProbes {
                        if let device = try? await group.next() {
                            if let d = device { continuation.yield(d) }
                        }
                        activeCount -= 1
                    }
                    group.addTask {
                        try await Self.probeHost(ip: ip)
                    }
                    activeCount += 1
                }
                for try await device in group {
                    if let d = device { continuation.yield(d) }
                }
            }
            continuation.finish()
        }
    }
}

One connect() to port 80 with a 500ms timeout per IP across a /24 — the host responds with SYN+ACK (alive), RST (alive but port closed, also counts as alive), or times out (dead or filtered). With maxConcurrentProbes = 20 the whole /24 finishes in 2-3 seconds.

iOS 17 gotcha: the "Local Network Access" alert shows only once. If the user denies it, subsequent connect() calls just silently time out, with no clear error. Had to add a UI hint nudging the user to Settings.

Host monitor: BGTaskScheduler as it is

The most engineering-painful part of the app. The user-facing requirement: "I add hosts to monitor, and if one goes down I get a push, like UptimeRobot." On iOS you can't do this properly because:

No persistent background thread. iOS kills your app ~30 seconds after backgrounding.
Silent push as a wake mechanism exists but needs a server, and I wanted everything local.
BGTaskScheduler gives you ~30 sec of CPU maybe once every 15+ minutes. iOS decides when based on user behavior patterns.

So monitoring precision on iOS is fundamentally worse than on a server. You have to accept that and design around it.

What I do:

BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.netdiag.hostmonitor", using: nil) { task in
    Task {
        await HostMonitorService.shared.runMonitoringPass()
        task.setTaskCompleted(success: true)
    }
    submitNext()
}

let request = BGAppRefreshTaskRequest(identifier: "com.netdiag.hostmonitor")
request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60)
try BGTaskScheduler.shared.submit(request)

Inside runMonitoringPass():

Fetch all monitored hosts
Ping them in parallel (withTaskGroup) — fit within the 30-second budget
For each: if state changed (up→down or down→up), fire a local notification
If state unchanged, stay quiet

No "host still up every 5 minutes" pings. Only state transitions. This both helps with iOS background limits and respects the user.

Debugging gotcha: BGTaskScheduler doesn't fire in the simulator unless you manually trigger it via debugger:

e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"com.netdiag.hostmonitor"]

Found this in some old DTS thread. Without that command, debugging background logic is impossible. On real devices the system runs your tasks unpredictably.

AdMob and UMP — the part that actually hurt

Networking was a pleasure to write. AdMob integration was a separate ordeal.

AdMob via the GoogleMobileAds Swift Package itself is fine — MobileAds.shared.start(), banners through BannerView in a UIViewRepresentable, standard stuff.

The pain begins with GDPR / CCPA consent, which Google requires through their UMP SDK (GoogleUserMessagingPlatform). Two problems:

SwiftUI documentation is essentially nonexistent. Every Google example is Objective-C or old UIKit. You figure out the SwiftUI integration by trial and error.
AdMob won't activate your privacy message until you ship a "revocation link" in the live app — that is, a button in Settings that re-opens the consent form. The business logic is: build the revocation link in code → ship that build → then go back to AdMob and confirm "yes, my app has the revocation link, please activate the message." Nowhere is this clearly stated. I sat on a configured but inactive consent message for a week before figuring it out.

The integration looks like this:

@MainActor
final class ConsentManager: ObservableObject {
    static let shared = ConsentManager()

    @Published private(set) var adsStarted = false
    @Published private(set) var privacyOptionsRequired = false

    func requestConsentAndStartAds() {
        let parameters = RequestParameters()

        ConsentInformation.shared.requestConsentInfoUpdate(with: parameters) { [weak self] error in
            ConsentForm.loadAndPresentIfRequired(from: Self.topViewController()) { [weak self] formError in
                self?.updatePrivacyOptionsAvailability()
                self?.startAdsIfNeeded()
            }
        }
    }

    func presentPrivacyOptionsForm() {
        guard let root = Self.topViewController() else { return }
        ConsentForm.presentPrivacyOptionsForm(from: root) { [weak self] error in
            self?.updatePrivacyOptionsAvailability()
        }
    }

    private func startAdsIfNeeded() {
        guard ConsentInformation.shared.canRequestAds else { return }
        MobileAds.shared.start { [weak self] _ in
            self?.adsStarted = true
        }
    }
    // ...
}

The key part: MobileAds.shared.start() is only called after the UMP flow returns canRequestAds == true. If a user in the EEA refuses, canRequestAds stays true anyway, ads just become non-personalized. The same flow covers both GDPR (EEA/UK) and US state privacy (CCPA in California and other regulated states), because UMP under the hood inspects geo and serves the matching message.

Another gotcha: ATTrackingManager.requestTrackingAuthorization (the ATT prompt) must come before the UMP flow, because UMP checks the ATT state when building the request:

ATTManager.requestTrackingIfNeeded {
    ConsentManager.shared.requestConsentAndStartAds()
}

Wrong order and UMP might think tracking is granted, then ATT denies, creating a mismatch AdMob can later flag.

For debug builds I force the geography to test the flow:

#if DEBUG
let debugSettings = DebugSettings()
debugSettings.geography = .EEA  // or .regulatedUSState
parameters.debugSettings = debugSettings
#endif

Without this, from a non-EEA IP the consent form never shows and you can't validate the flow at all.

Localization

12 languages (en, ru, uk, de, es, pt-BR, fr, it, pl, ja, ko, tr) using the new Xcode String Catalogs (.xcstrings). After years of Localizable.strings, the Catalog format is just nice — JSON, diffs reasonably in git, Xcode has a usable GUI for translation, automatic pluralization. If you're still on .strings, migrate, you're losing nothing.

What I'd do differently

Don't skimp on tests for ICMP header parsing. I have decent tests on DNS resolver and whois parser, but I debugged the ICMP path against live networks. It worked for 30 hosts; then two days after release I found a bug with big-endian sequence numbers. Embarrassing.
Build UMP from day one, before submitting to TestFlight. Retrofitting UMP after the fact rewrites your AdMob initialization order, ATT timing, etc. Just bake it in.
Don't trust the simulator for anything touching background tasks, mDNS, or push notifications. I had several "green in simulator, dead on device" moments.

Numbers and context

App went live a few weeks ago. ~30 total installs at the time of writing — basically zero marketing happened. This post is part of changing that.

AdMob after the first week post-approval: $1.19 eCPM, 85% match rate — "normal for a utility at launch" according to indie folks I've asked.

If you've done iOS network programming and hit different walls, I'd love to compare notes. Apple's networking stack isn't where most iOS devs spend their time and good references are scattered.