Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MikeFerak

macrumors newbie
Original poster
I built the Mac utility I kept looking for.

If you've ever tethered your Mac to your phone for a Zoom call, worked from hotel Wi-Fi, or relied on another metered connection, you know how easy it is to lose track of your data usage.

By the time your carrier warns you, the data is often already gone.

So I made Hotspot Meter - a native macOS menu-bar app that shows:
  • Live download and upload speeds
  • Usage for the current session
  • Cumulative totals for each Wi-Fi network or hotspot
  • Usage history across connections
  • Alerts before you reach a chosen data limit
  • Automatic tracking on hotspot connections
I also wanted it to be the kind of utility I'd trust installing myself.

It's completely free. No account, no analytics, no trackers, and no personal data collected or transmitted. Everything is calculated and stored locally on your Mac.

Hotspot Meter is now available on the Mac App Store:

https://apps.apple.com/app/id6763610446

More details and screenshots:

https://hotspot-meter.loam.sk/

I'd love to hear what you think!
 

Attachments

  • 01-live.webp
    01-live.webp
    62 KB · Views: 57
  • 02-history.webp
    02-history.webp
    84.5 KB · Views: 43
  • 03-alerts.webp
    03-alerts.webp
    67.8 KB · Views: 41
  • Like
Reactions: tulon
This is a great idea -- data caps on hotspot/tethered connections are exactly the kind of thing macOS gives you zero visibility into by default.

Curious about the implementation side, if you don't mind sharing: how are you attributing usage per network/hotspot? In my own experience the interface-level byte counters (getifaddrs/if_data) don't persist cleanly across sleep/wake or interface re-association, so keeping an accurate running total per SSID/hotspot across reconnects seems like it'd need its own persistence layer rather than trusting the OS counters directly. Did you run into that, or is macOS better behaved about it than I'd expect?

Also good to see it's local-only with no accounts -- that's a rare choice for a utility like this. Bookmarking it, tethering data caps have burned me more than once.
 
  • Like
Reactions: MikeFerak
This is a great idea -- data caps on hotspot/tethered connections are exactly the kind of thing macOS gives you zero visibility into by default.

Curious about the implementation side, if you don't mind sharing: how are you attributing usage per network/hotspot? In my own experience the interface-level byte counters (getifaddrs/if_data) don't persist cleanly across sleep/wake or interface re-association, so keeping an accurate running total per SSID/hotspot across reconnects seems like it'd need its own persistence layer rather than trusting the OS counters directly. Did you run into that, or is macOS better behaved about it than I'd expect?

Also good to see it's local-only with no accounts -- that's a rare choice for a utility like this. Bookmarking it, tethering data caps have burned me more than once.
Good instinct - you're right that the system's own counters can't be trusted on their own, and the app doesn't rely on them directly.

Instead of reading the totals macOS reports and taking them at face value, the app checks the counters about once a second and only records how much they grew since the last check. If a counter ever resets or goes backwards - which happens after sleep/wake or when you replug a tethered phone - that one second is simply skipped instead of throwing off the total. So the worst case is losing a second of data, not corrupting your running total.

Each little increment then gets filed under whatever network you're currently on (the Wi-Fi name, or "USB tether" for cable connections), and those per-network totals are stored by the app itself, locally on your Mac. So reconnects, sleep cycles, even reboots don't lose your running total. The app's own records are the source of truth, not the OS counters. One small note: reading the Wi-Fi name requires Location permission on recent macOS versions, which is an Apple requirement, not the app's choice. The actual location is never read or recorded. Strange to bundle network name with location permissions, if you ask me.

It's not perfect down to the byte - if traffic happens while the Mac is napping, it gets counted against whatever network you're on when it wakes up. But I consider that, for keeping an eye on a data cap, a rounding error.

And yes, local-only was deliberate - a utility that watches your traffic shouldn't be phoning home. Thanks for the kind words!
 
  • Like
Reactions: tulon
That delta-sampling approach is smart -- treating the OS counters as untrusted and diffing your own polls instead of trusting the running total is exactly the kind of thing that's obvious in hindsight but easy to get wrong the first time. Skipping a second on reset/rollback instead of trying to detect and correct for it is a good tradeoff too, way simpler than trying to guess what the "real" delta should've been.

Good to know about the Location permission gotcha for reading the Wi-Fi name -- that's going to trip up a chunk of privacy-conscious users who see a data-usage app asking for Location and get suspicious, even though it's an Apple requirement, not the app doing anything shady. Do people actually deny it and then wonder why the per-network breakdown is missing, or is the prompt clear enough that it doesn't cause confusion?

Appreciate the detailed answer -- genuinely well thought-through design.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.