tonymillion/Reachability: the Objective-C network reachability class that replaces Apple's

What tonymillion/Reachability replaces, and for whom

Apple ships a Reachability sample class that tells an app whether a network interface is usable. tonymillion/Reachability is a drop-in replacement for that class. The README states it is ARC-compatible, so it compiles under automatic reference counting without manual retain and release calls, and it uses GCD methods to notify of network interface changes. The audience is narrow and specific: Objective-C and Swift developers on iOS and macOS who already call Reachability-style APIs and want the same shape of API with modern memory management and dispatch-based callbacks. If you are starting a new networking layer from scratch, this class is not a networking library. It does not perform requests, retry them or manage sessions. It answers one question, whether an interface is reachable, and reports when that answer changes.

How the notifier, the blocks and the WWAN flag fit together

The mechanism has three parts. You allocate a reachability object, either for a hostname or, in the Swift example, through Reachability.forInternetConnection(). You then attach callbacks, and finally you call startNotifier. According to the README, startNotifier causes the reachability object to retain itself, which is why the examples store the object in a property rather than a local variable. There are two callback styles, and they differ in threading. Blocks are called on a background thread, so the README's examples wrap UI work in dispatch_async(dispatch_get_main_queue(), ...) or DispatchQueue.main.async. NSNotification observers are delivered on the main thread, so UI updates can happen directly inside the handler. The WWAN flag is the third part: setting reachableOnWWAN to NO makes the object treat 3G, EDGE and CDMA connections as not reachable, which the README suggests for a video streaming app trying to save the user's data plan. Swift callers can then branch on isReachableViaWiFi() and isReachableViaWWAN().

Installing the class and getting a first callback

There is no package manager step in the README. You add the .h and .m files to your project, then link SystemConfiguration.framework through Project, TARGETS, Build Phases, Link Binary With Libraries, pressing the plus button in the lower left of the list. The README calls that the end of setup. A podspec, a Package.swift file and a Framework directory exist in the repository, but the README does not document them, so treat the manual file drop as the documented path.

Once the framework is linked, the shortest working example is a hostname-based object with a single reachable block. The README's Objective-C sample looks like this:

Reachability* reach = [Reachability reachabilityWithHostname:@"www.google.com"];

reach.reachableBlock = ^(Reachability*reach)
{
    dispatch_async(dispatch_get_main_queue(), ^{
        NSLog(@"REACHABLE!");
    });
};

[reach startNotifier];

After startNotifier runs, the block fires whenever the interface state changes in the reachable direction, and the log line appears on the main thread because of the explicit dispatch. For Swift, the README's example allocates through Reachability.forInternetConnection() and assigns reachableBlock and unreachableBlock before calling startNotifier. If you prefer notifications over blocks, register an observer for kReachabilityChangedNotification, or NSNotification.Name.reachabilityChanged in Swift, and the Reachability object arrives in the notification's object parameter.

The framework rejection warning and the iOS 5/6 tag problem

The README opens with a warning in capitals: there have been reports of apps being rejected when Reachability is used in a framework, and the only solution offered so far is to rename the class. That is a real constraint, not a footnote. If your architecture puts this class inside a dynamic or static framework, you are working against documented App Store outcomes with no supported fix in the project. The second limitation is version coverage. The README instructs anyone opening a bug about iOS 6 or iOS 5 build errors to use tag 3.2 or 3.1, because those tags support assign types. So the current code is not the right choice for projects still targeting those systems, and the fallback is an older tag rather than a configuration flag. The README also asks users not to open bugs until they have tested on a device, which tells you the simulator is not considered a sufficient environment for reporting problems.

Where this sits against Apple's own Reachability

The obvious alternative is the class this project replaces. Apple's Reachability is the reference implementation, and tonymillion/Reachability is explicitly positioned as a drop-in substitute for it. The difference in approach is in the delivery of change events and in memory management. Apple's sample predates ARC and uses the older notification-centric style; this project is ARC-compatible and adds GCD-based notification plus block callbacks for the reachable and unreachable transitions. The WWAN toggle is another point of divergence: the README presents reachableOnWWAN as a first-class property so an app can decide that a cellular connection does not count as reachable. If you need a broader networking stack with request handling, neither class is the answer, and you would be comparing against an HTTP client rather than a reachability helper. Within the reachability problem itself, the choice is between Apple's sample and this replacement, and the deciding factors are ARC, blocks and the WWAN flag.

Maintenance, licence and what upgrading costs you

The repository is not archived, and the last push was on 2026-03-25. The most recent release listed is 3.4b1, a preview release dated 2019-04-06, so the release channel has been quiet for years even though the repository has seen recent activity. That gap matters for planning: if you pin to a tagged release, you are pinning to something from 2019 or, for iOS 5 and iOS 6 support, to the 3.2 or 3.1 tags. The licence is BSD-2-Clause, which is permissive and generally allows use in closed-source applications, but this is not legal advice and you should read LICENCE.txt in the repository yourself. Upgrade cost is low in one sense, because the API surface is small and stable enough that the README's examples still read as current. It is higher in another, because the documented install path is a manual file drop, so every upgrade is a file replacement in your project rather than a dependency manager command.

Editorial conclusion

Adopt tonymillion/Reachability if you already depend on Apple's Reachability API and want ARC compatibility, GCD-based notifications and block callbacks without changing call sites. Do not adopt it if your app ships the class inside a framework, since the README warns that apps have been rejected in that situation and the only workaround it offers is renaming the class. Before you commit, verify that SystemConfiguration.framework is linked in Build Phases, confirm you can build against the 3.2 or 3.1 tags if you still target iOS 5 or iOS 6, and read Reachability.h to check the exact method names your code will call.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. README
4. Releases
5. tonymillion/Reachability on GitHub