NSLogger: your NSLog output, streamed to a real viewer over Bonjour

NSLog redirected with zero code changes

The basic usage promise is the hook, without any change to your code, all the NSLog() logs from your application are redirected to the NSLogger desktop viewer, which is found automatically on the network using Bonjour. Adoption is therefore free for existing projects, and the rich API is opt-in on top. The Swift wrapper reads almost like prose:

import NSLogger

[…]

// logging some messages
Logger.shared.log(.network, .info, "Checking paper level…")

// logging image
Logger.shared.log(.view, .noise, myPrettyImage)

// logging data
Logger.shared.log(.custom("My Domain"), .noise, someDataObject)

and Objective-C keeps the classic macro style:

#import <NSLogger/NSLogger.h>

[…]

LoggerApp(1, @"Hello world! Today is: %@", [self myDate]);
LoggerNetwork(1, @"Hello world! Today is: %@", [self myDate]);

Messages, binary data and images all flow through one call shape with a domain and a level attached.

A macOS viewer instead of the IDE console

The NSLogger Viewer runs on macOS and positions itself as a replacement for the Xcode, Android Studio or Eclipse consoles, the places developers normally squint at logs. What it adds over those consoles is the feature list IDEs never grew, display filtering, user defined log domains and levels, image and binary logging rendered rather than hex dumped, message coloring, traces buffering, timing information on messages, and links back to source code. Logs arrive from devices or simulators, over the local network via Bonjour or from remote clients connecting directly over the internet, so a field test on real hardware feeds the same viewer as a desktop debug session. The screenshots section shows both light appearance and dark mode support for macOS Mojave and later, a small sign of maintenance attention on an old tool. Timing information attached to messages rounds out the debugging value, since knowing when a trace fired relative to its neighbors often matters more than the trace text itself when hunting latency and ordering problems.

Domains, levels, colors and images

The organizational model is a two axis taxonomy, a log domain such as app, view, model, controller or network, and an importance level from error and warning through debug down to noise. Filtering and display operate on both axes, which is what makes large trace volumes navigable. On top of the structure, log messages can be colored using regular expressions, so a pattern like an error code range becomes visually loud without touching the logging call sites. The media capabilities are the distinctive part, NSLogger can log images or raw binary data, meaning a screenshot of the current UI state or a protocol frame can appear in the trace stream inline, and the viewer renders it, turning the log into a record of what the application actually showed or transmitted rather than only what it said.

Buffer now, deliver when a viewer appears

Disconnected operation is designed rather than accidental. Traces can be buffered entirely in memory or in a file on the client, and sent over to the viewer when a connection is acquired, so a field reproduction with no laptop attached still yields its logs afterward. Online viewing covers the application running and connected case, and offline viewing covers saved logs in the viewer itself, which can be saved to share or review later and exported to text files. The loop closes with the ability to open raw buffered traces files brought back from client applications that were never directly connected to the viewer, the forensic path for devices that spent the day away from any network the developer controlled. The export path matters for teams, a text file of a saved session can be attached to a bug report or diffed between runs, giving the offline traces a life beyond the viewer that captured them.

SSL by default, Bonjour disambiguated by user

Connections use SSL by default, stated plainly in the feature list, so traces crossing a shared network are not plaintext. Shared networks create a different problem, discovery, when multiple NSLogger users sit on the same network, logger connections can get mixed. The fix is per build user Bonjour naming, one call at application startup:

LoggerSetupBonjourForBuildUser();

paired with typing your user name, effectively $USER, into the Bonjour service name field on the viewer's Network preferences tab, so traces are received only by the computer of the person who compiled the app. The documentation notes the limitation honestly, this only works when NSLogger was added with CocoaPods, one of the few places the install method changes behavior rather than just packaging.

iOS 14 asks permission for the local network

Since iOS 14, apps must request permission to access the local network, which breaks silent Bonjour discovery unless the developer adds the right keys. The recipe is an Info.plist addition for development builds:

<key>NSBonjourServices</key>
<array>
  <string>_nslogger._tcp</string>
  <string>_nslogger-ssl._tcp</string>
</array>
<key>NSLocalNetworkUsageDescription</key>
<string>Access to the local network for development builds</string>

The two service names cover the plaintext and SSL variants of the NSLogger protocol, and the usage description string is what iOS shows in the permission prompt. Forgetting this step is the most common way an otherwise working setup goes quiet on modern iOS, and its placement in the README reflects how often it bites.

CocoaPods subspecs, Carthage pairs, and manual files

Installation offers the classic three step pitch, download the desktop app, add the framework, there is no step 3. On the client side, CocoaPods provides pod "NSLogger" with C and Objective-C APIs only, pod "NSLogger/Swift" adding the Swift sugar, and pod "NSLogger/NoStrip", which forces the linker to keep all NSLogger functions in the final build even unused ones, required when linked frameworks dynamically check for NSLogger's presence without the linker seeing that use. Carthage builds two frameworks, NSLogger and NSLoggerSwift, pick one but not both, with the import statement differing accordingly, a contrast with CocoaPods where the import is always NSLogger. A Package.swift and SPMTests directory in the repository add Swift Package Manager support, and the manual route is spelled out too, add LoggerClient.h, LoggerClient.m and LoggerCommon.h plus the CFNetwork and SystemConfiguration frameworks.

A 2019 release, still receiving pushes in 2026

The release history tells a specific story, v1.9.5 on 2018-12-26, v1.9.6 three days later, v1.9.7 on 2019-01-09, and nothing tagged since, while the repository's last push landed 2026-06-03. The tool is therefore maintained in the working tree rather than through releases, and the pre-built signed desktop viewer downloadable from the releases page remains the practical distribution. The repository structure splits into Client, Desktop and iPad Viewer directories, the last being a dedicated viewer for the iPad, plus Docs and Screenshots directories and a CONTRIBUTORS file. GitHub reports the license as unclassified despite the LICENSE.txt at the root, so commercial users should read that file directly before shipping the client framework in a product. A .swift-version file at the root pins the Swift toolchain expectations for contributors, and the podspec beside it drives the CocoaPods subspec split described earlier.

Editorial conclusion

Use NSLogger when developing Apple platform or Android applications and the built in console has become the bottleneck, since domains, levels, coloring, image logging and buffered offline traces address exactly the complaints IDE consoles cause. Verify iOS 14 or later builds include the Bonjour service keys and local network usage description in Info.plist for development builds, or the client silently cannot find the viewer. Note the project's rhythm before depending on it, the last tagged release is v1.9.7 from January 2019 while the repository was still pushed in June 2026, so the code receives care but releases are rare, and check the LICENSE.txt directly since GitHub reports the license as unclassified.

Frequently asked questions

Official sources

1. fpillet/NSLogger on GitHub
2. Issues
3. README
4. Releases