nRF Toolbox for iOS: a reference client for Nordic Bluetooth LE peripherals

A demo app that doubles as the vendor's reference implementation

The README frames the nRF Toolbox as an all-in-one application designed to demonstrate Nordic Semiconductor's Bluetooth Low Energy capabilities, and then says the important thing about what it is for. It serves a dual purpose: providing a user-friendly interface for connecting to Nordic-based peripherals, and acting as a reference implementation for developers utilizing Nordic's libraries.

That second role is the one that matters for engineers, and it explains the rest of the design. The app is not a generic Bluetooth explorer that can dump every characteristic of an arbitrary device. It is a set of client implementations, one per Bluetooth LE profile, written the way Nordic would write them. If you are building an app that talks to an nRF52-based heart rate sensor, this repository shows you how Nordic structures that connection, which characteristics it subscribes to, and how it interprets the payloads.

The top level of the repository confirms the app rather than a library. There is a `nRF Toolbox.xcodeproj/` project directory, the application source in `nRF-Toolbox/`, unit tests in `nRF-ToolboxTests/`, UI tests in `nRF-ToolboxUITests/` and a test plan file, plus a `Podfile` and `Podfile.lock` for CocoaPods dependencies, a `Gemfile` for the fastlane tooling, a `fastlane/` directory, and a `CHANGELOG.md` and `CONTRIBUTORS.md`.

It is a full iOS application, and it is published on the App Store. The licence is BSD-3-Clause with the terms in the LICENSE file, the repository is not archived, and the last push was on 2026-10-19. The release history is steady, with 6.1.4 on 2026-09-01, 6.1.3 on 2026-08-28 and 6.1.2 on 2026-08-20.

One module per Bluetooth LE profile, not a generic scanner

The module list is the clearest statement of scope, and it is a closed list rather than an extensible one.

The supported profiles are Cycling Speed and Cadence, Running Speed and Cadence, Heart Rate Monitor, Blood Pressure Monitor, Health Thermometer Monitor, Glucose Monitor, Continuous Glucose Monitor, Nordic UART, Throughput, Monitoring and Diagnostic, and Quick Start. The README describes them as distinct modules for standard and proprietary profiles.

Most of these are Bluetooth SIG standard profiles, so the implementation follows a defined service and characteristic layout. Nordic UART is the exception, and it is Nordic's own proprietary service. The Throughput module is a performance measurement tool rather than a profile in the standards sense, and Quick Start is a guided flow for a new device.

The consequence for a reader is that this is a tool for Nordic-based peripherals. The key features are listed as connecting to one or multiple peripherals simultaneously, parsing and displaying characteristic data in an intuitive readable format, modifying peripheral settings and parameters where supported, and providing code examples demonstrating communication with Nordic's peripherals.

The third of those, modifying peripheral settings where supported, is the one that has a doubled use. It is a feature for a hardware bring-up, and it is also a debugging tool for a developer, because changing a parameter on the peripheral and watching the effect is faster than rebuilding firmware. The phrase where supported matters, because a read-only sensor characteristic will simply not be writable from the app.

Nordic UART treats the link as a serial port and lets you share macros

The Nordic UART module deserves its own look because it is the part most likely to be used with something other than a shipped demo board.

The README describes it as a serial port emulator over Bluetooth LE, with three listed capabilities. It sends and receives text strings or byte arrays to and from a peripheral. It defines custom macros for quick execution. And it exports and imports macro configurations via XML for easy sharing and backup.

A macro is a named sequence of bytes to send, and the ability to define them means a UART peripheral can be exercised with one tap rather than a terminal program and a copy-pasted hex string. The export and import via XML is the part that makes this a working tool rather than a toy: a set of macros for a device is a configuration artifact, and being able to hand that file to a colleague or keep it in version control is what turns it into a repeatable procedure.

The XML format is not documented in the visible portion of the README, so the file layout is something you would learn by exporting one and reading it, and the interoperability question, whether a macro set from one device version works against another, is not answered there either.

Core Bluetooth Mock lets the same client code run without hardware

The Simulation section is the most useful thing in the README for anyone without a Nordic board on the desk.

The project integrates Core Bluetooth Mock, a separate repository from Nordic Semiconductor, and the README says it facilitates development and testing without physical hardware. Three points of detail follow. The app can emulate peripheral behavior directly within the iOS Simulator. All supported profiles, excluding Throughput, include predefined mock responses that are available automatically when running on the simulator. And the client-side BLE logic remains identical regardless of whether the app is communicating with a mock object or a physical device.

That third point is the one that matters architecturally. A mock layer that requires the app to take a different code path is a mock layer that stops testing the interesting code. Here the same client code drives both, so a developer can write the parsing logic against mock responses in the simulator and then switch to a real peripheral without changing the logic under test.

The exception is worth planning around. Throughput is excluded from the mock responses, which makes sense since measuring throughput requires a real radio and a real peer. So if your work depends on the Throughput module, the simulator will not help you, and the requirement table's hardware line applies: a peripheral with one of the supported services installed.

iOS 18 and the Swift toolchain set the floor

The requirements table is short. The OS version is iOS 18.0 or newer, and the hardware is a peripheral with one of the supported services installed.

iOS 18 is a recent floor, which matters for two audiences. For an app developer adopting the patterns, it means the sample code assumes a modern SDK and will not build against an older toolchain without changes. For a QA team that wants to run the app on a spread of devices, it narrows the device pool considerably compared with a year or two ago.

The repository shows how the project is set up. There is a `.swift-version` file pinning the Swift version, a `Podfile` and `Podfile.lock` for CocoaPods, an `nRF Toolbox.xcodeproj/` directory, and a `.vscode/` directory, so an editor with Swift support is expected. `GoogleService-Info.plist` sits at the top level, which is the configuration file for a Google service, and it is worth knowing about because it hints that some part of the app talks to a Google backend, though the README does not describe what for.

There is also a `ReactiveCentralManagerDelegate.md` at the repository root, which is unusual enough to be worth noting. A central manager delegate is the Core Bluetooth object that owns the connection to a peripheral, and a document about it at the root level of an app repository is a sign that the app's connection handling is complex enough to warrant written explanation. The README itself does not describe it.

For resources, the README states that the nRF5340, along with the nRF52 and nRF54 series development kits, can be ordered from Nordic. That is a helpful pointer for anyone who needs the hardware, and it also tells you which silicon generations the app is expected to be used against.

Compared with a generic BLE scanner and with your own client

The obvious alternative is a general-purpose Bluetooth scanner, of which there are many on the App Store, and the difference in approach is one of scope versus depth.

A generic scanner connects to anything, lists every service and characteristic it finds, and lets you read and write raw values. That is exactly what you want when you do not yet know what a device does, and it is useless for the third question a developer asks, which is how a well-behaved client for this device should be written. The nRF Toolbox can only connect to peripherals speaking one of its eleven listed profiles, and in exchange it shows you the full flow for that profile, from subscription to interpretation to a readable display, with Nordic's own code behind it.

The second alternative is writing your own client from scratch, which is what many embedded developers end up doing because the vendor app is not a dependency you want in a product. The trade is that you copy the approach rather than the code, and you lose the mock layer, because Core Bluetooth Mock is integrated into this application rather than offered as a separate library you can pull into your own project.

A third option is the more general Nordic approach of reading the specification and the SDK samples. The nRF Toolbox is a middle point between a spec and a product, because it is a working app that a developer can also read.

For a firmware engineer debugging a BLE peripheral, the practical split is simple. Use a generic scanner when the question is what is this device advertising. Use the nRF Toolbox when the question is what should my client do with this known device, and use the simulator when the question is what does my parsing code do with this payload.

Editorial conclusion

Adopt the nRF Toolbox if you are developing against Nordic's own Bluetooth LE peripherals and want the vendor's own client to test against, especially if you are working on the UART service and need its macro sharing. Do not adopt it as a general-purpose Bluetooth LE scanner, because the module list is fixed to Nordic's supported profiles and its purpose is to demonstrate Nordic's libraries. Verify first that the peripheral you are testing speaks one of the listed profiles, since the README states the hardware requirement is a peripheral with one of the supported services installed and requires iOS 18.0 or newer.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. nordicsemi/IOS-nRF-Toolbox on GitHub
3. Project website
4. README
5. Releases