Why PingKit Has No Cloud (and Uses iCloud Sync Instead)

Published June 8, 2026 · 7 min read

When you scan your home network, you produce a remarkably detailed picture of your life. The list of devices on your WiFi reveals which phones, laptops, consoles, cameras, speakers, and smart-home gadgets you own. The times those devices come and go hint at when people are home. Open ports and service banners can expose what software is running where. A network map is not a boring list of IP addresses. It's an intimate snapshot of a household.

So a fair question to ask of any network app is: where does that snapshot go? With PingKit, the answer is simple. It doesn't leave your Apple account. We built the app with no proprietary cloud at all, and we want to explain that choice honestly, including the things we give up to make it.

The Norm: Your Network, Routed Through a Vendor's Servers

Many popular network apps work on a familiar model. You create an account, you log in, and your scans and device inventory get uploaded to the vendor's own servers. This is usually framed as a convenience feature. It powers a web dashboard, lets you get notifications, and syncs your data between your phone and tablet.

The catch is that it puts a third party in the middle of your network map. Once your device list lives on someone else's server, that company can see it. Their staff may be able to query it. It becomes part of their database, subject to their retention policy, their security practices, and their legal obligations. If that company is ever breached, your home network inventory is part of the spill. If it receives a subpoena, your data is among what it can be compelled to hand over.

None of this requires bad intent on the vendor's part. It's just the structural reality of routing sensitive data through a server you don't control. The data is there, so it can be seen, retained, leaked, or demanded.

PingKit's Choice: No Server, No Account

PingKit takes a different path. There is no PingKit-operated server that your scans pass through, and there is no PingKit account to create. When you run a network security scan, a ping, a traceroute, or a port check, the work happens on your device, and the results are stored on your device.

That immediately removes us from the picture for the data itself. We can't read what we never receive, and we can't be compelled to produce a database we don't keep. There is no central store of customer network maps sitting on our infrastructure waiting to be breached, because that infrastructure doesn't exist.

But people legitimately want their data on more than one device. You might run a scan on your iPhone and want to see it on your iPad. The Mac Agent needs to get its alerts to your phone. So we still needed a way to sync, just not one that routes through us.

How We Sync: Apple's CloudKit Private Database

Instead of building our own backend, PingKit uses CloudKit, Apple's framework for storing app data in iCloud. Specifically, it uses the private database, which is the part of CloudKit scoped to an individual user's iCloud account.

At a high level, it works like this. When PingKit needs to sync something between your devices, it writes a record into your private database. Your other devices, signed in to the same iCloud account, read that record back. Authentication rides on your existing iCloud sign-in, which is why PingKit never asks you to make a separate login. The whole thing happens within your Apple account.

The key property is the access boundary. In CloudKit, an app developer can read and manage the records in their app's public database, but the contents of each user's private database belong to that user, inside their own iCloud. The developer defines the schema, but does not have access to the private records that users store. Your network map travels between your devices and Apple's infrastructure, not ours.

We want to be precise here rather than oversell it. This is a privacy model based on how CloudKit's private database is designed and on Apple's platform policies, with iCloud data protected in transit and at rest. The honest, accurate claim is this: there is no PingKit server in the loop, and as the app developer we do not have access to the contents of your private CloudKit database. That is a genuinely smaller circle of trust than the account-and-vendor-server model, and it's the reason we chose it.

Why This Matters: A Smaller Attack Surface

Security people talk about reducing your attack surface, meaning the number of places something can go wrong. Holding sensitive data in fewer hands is one of the most reliable ways to do that.

Think about who can touch your home network map under each model:

• Cloud vendor model: you, the vendor, the vendor's employees with database access, the vendor's hosting provider, anyone who breaches the vendor, and any party that can legally compel the vendor.
• PingKit model: you and your own Apple account. There is no PingKit-side database to breach, subpoena, or accidentally misconfigure.

Every party you remove is a class of risk you remove with them. There is nothing to leak in a PingKit data breach involving your network map, because we don't hold one. There is nothing for us to hand over in response to a legal request, because we don't have it. That isn't marketing. It's just the consequence of not building the server in the first place. For more on why a home network is worth protecting at all, see our guide on how to secure your home WiFi network.

The Mac Agent Uses the Same Private Path

The PingKit Mac Agent runs continuous monitoring from your Mac, watching uptime and surfacing problems even when your phone isn't nearby. When it detects something worth knowing about, it needs to get that alert to your iPhone.

It does that through exactly the same private iCloud path. Agent status and alerts sync to your phone via your CloudKit private database, not through a PingKit relay server. So the architecture is consistent across the whole product: whether the data originates on your Mac or your iPhone, it moves between your devices inside your Apple account. There is no separate Agent cloud, and no separate Agent login.

The Trade-Offs, Stated Honestly

Choosing no cloud is not free, and we'd rather name the costs than pretend they don't exist. They follow directly from the same decision that gives us the privacy benefits.

• No web dashboard. You can't log into a browser from any computer in the world to see your network. Your data lives on your Apple devices, so that's where you view it. We think the privacy win is worth losing the convenience of a universal web login, but it is a real loss.
• Sync requires iCloud. If you're signed out of iCloud, or you've disabled iCloud for the app, cross-device sync simply won't happen. The app still works fully on a single device, but the magic of seeing your scans on your iPad depends on the account that makes it private in the first place.
• No cross-ecosystem sync. Because we lean on Apple's framework rather than our own server, there is no syncing to Android or Windows. A vendor cloud could bridge ecosystems; our model can't. PingKit is an Apple-platform product by design.

We accept these limits on purpose. They're the price of not being a third party in your home network, and for a privacy-conscious audience we think that's a price clearly worth paying.

A Core Difference, Not a Footnote

Plenty of network tools are capable. What sets PingKit apart isn't only what it can scan, but where that information ends up afterward. The mainstream model treats your network map as data to be collected. We treat it as data to be kept out of our hands entirely.

This is one of the clearest lines between PingKit and cloud-based competitors. If you'd like to see how that compares concretely, our PingKit vs Fing comparison lays out the differences side by side. Otherwise, the short version is this: the most private place for a map of your home is your own home, and the next most private is your own Apple account. PingKit is built so that's exactly as far as it ever travels.