32feet.NET wraps Bluetooth, IrDA, OBEX and NFC for .NET code

One family of libraries for personal area networking

Writing Bluetooth code in .NET means either wrapping the operating system stack yourself or finding someone who has done it. 32feet.NET, the open source project run by In The Hand, is that wrapper, and it covers more than Bluetooth.

The project currently consists of Bluetooth Classic, Bluetooth LE, IOBluetooth and IOBluetoothUI bindings for macOS, IrDA, Object Exchange (Obex) and NFC. That last group is what makes the project more than a Bluetooth wrapper. IrDA and OBEX are the older infrared and file-transfer protocols that embedded and handheld devices used, and NFC covers the near-field tag reading that arrived with phones and door access hardware.

The audience is a developer building a .NET application on Windows, Xamarin, MAUI or Uno Platform code that has to talk to a device over a short personal area network. The library is described as free for commercial and non-commercial use, and the components in the repository carry project names that match the NuGet package names.

Windows needs .NET Framework 4.6.1, mobile needs Xamarin or .NET 6

The platform story is stated in one sentence and it matters. Bluetooth support requires .NET Framework v4.6.1 or later on desktop Windows 7, 8, 10 and 11, and Android, macOS and iOS are supported through Xamarin or .NET 6.0 and above. The full platform matrix is kept in the project wiki rather than in the README, which means the exact combination of target framework and operating system is a page you have to open separately.

The macOS support is a special case worth understanding. Instead of pretending the same code covers every OS, the project ships InTheHand.IOBluetooth and InTheHand.IOBluetoothUI, which are bindings to Apple's IOBluetooth framework for Xamarin Mac. The repository keeps them in separate projects, InTheHand.IOBluetooth/ and InTheHand.IOBluetoothUI/, with their own solution file 32feet-mac.sln, so the macOS work is versioned apart from the cross platform core.

That is the trade-off of the whole design. A unified API means one code path for most targets, and a native binding where the platform is too different to abstract away.

Eight NuGet packages, one of them legacy

Distribution happens through the Downloads tab of the repository and through NuGet, and the package list is where the shape of the project becomes clear:

InTheHand.Net.Bluetooth
InTheHand.BluetoothLE
InTheHand.IOBluetooth
InTheHand.IOBluetoothUI
InTheHand.Net.IrDA
InTheHand.Net.Obex
InTheHand.Nfc
32feet.NET

The names split along the same lines as the libraries. InTheHand.Net.Bluetooth and InTheHand.BluetoothLE cover the two Bluetooth flavours, the two IOBluetooth packages cover macOS, and the IrDA, Obex and Nfc packages are separate again.

The last entry is the one to read carefully. InTheHand.Net.Bluetooth, InTheHand.BluetoothLE, InTheHand.Net.IrDA and InTheHand.Net.Obex are marked as v4.x, while 32feet.NET is the legacy v3.x package. A new project should reference the specific InTheHand packages rather than the umbrella package, and an existing v3.x project is the case where the umbrella name still applies.

The repository is several solutions and one permissions project

Looking at the top level, this is not a single library project. There is 32feet.sln for the main solution, 32feet-mac.sln for the macOS bindings, InTheHand.Nfc.sln plus the matching solution filter InTheHand.Nfc.Build.slnf, and separate project directories for each of the InTheHand.Bluetooth, InTheHand.BluetoothLE, InTheHand.IOBluetooth, InTheHand.IOBluetoothUI, InTheHand.Net.IrDA, InTheHand.Net.Obex and InTheHand.Nfc components.

Two entries stand out. Legacy/ holds the older code that feeds the v3.x package, and InTheHand.Bluetooth.Permissions/ is a project of its own, which suggests the platform permission story is maintained separately from the Bluetooth implementation. For mobile targets, where Bluetooth access depends on runtime permissions, that separation is a reasonable place to keep it.

The practical consequence for a contributor is that a change touches one project directory and a solution file, and the build is a solution build rather than a single package build. There is also a Samples/ directory and a docs/ directory, and a 32feet.shfbproj, which is a Sandcastle Help File Builder project for generating the API documentation that is published at inthehand.github.io.

The Samples directory is the tutorial the wiki points to

The documentation strategy is unusual: the README sends you to the wiki before anything else and says the user guide should be read first, covering the features in the library, what kind of Bluetooth connection you want, and how to use each feature. Detailed API documentation lives at inthehand.github.io.

The sample projects show what the library is actually used for, and their names read as a task list. The Samples/ directory holds BluetoothClassicConsole, BluetoothClientApp, ConsoleBLETest, IOBluetoothSample, MauiBluetoothClassic, MauiWebBluetooth, NfcReaderMaui, RadioConsole, RfcommClientWin32, RfcommServiceConsole and RfcommXamarinForms.

There is a console client and a desktop client for Classic Bluetooth, a console test for Bluetooth LE, a sample for the macOS IOBluetooth path, and MAUI samples for Classic Bluetooth, Web Bluetooth and NFC reading. The radio and RFCOMM samples cover the lower layers: discovering devices and connecting over the serial port profile.

For a developer choosing a starting point, that list is more useful than the wiki index, because each sample maps to one protocol decision you have to make anyway.

The licence lets you ship binaries as-is, and asks more of a fork

The repository is under the MIT licence, and the README adds a condition that is easy to miss. Using the binaries, you can use the library as-is. If you modify the source, you need to include the 32feet.NET License.txt document and make sure the file headers are not modified or removed.

That is a modest obligation next to a copyleft licence, and it is still an obligation. A fork that strips the headers to tidy the code has to keep the notice file, and a team that vendors the source rather than the package inherits that obligation too. It is not legal advice, it is just the stated condition, and it is the sort of detail that matters when a library ends up in a commercial product.

The professional framing matters too. The project description calls it open source and professionally supported, with commercial use permitted, and the repository carries a sponsors list and a development blog alongside the code. The licences and the commercial posture are separate questions, and both are answered in the README.

GitHub tags stop at 2017 while the branch keeps moving

The release history on GitHub is misleading at first glance. The most recent releases are 4.0, 3.7 and 3.5, all dated 2017-10-11, which looks like an abandoned project. It is not archived, and the last push to the main branch was on 2026-10-19, nearly nine years after the newest tag.

What that means is that the version numbers in the repository and the version numbers in NuGet have drifted apart. The NuGet listings show the component packages at v4.x and the umbrella 32feet.NET package at v3.x, and the Downloads tab of the repository is where the current binaries are offered. A team pinning a dependency is pinning a NuGet version, not a GitHub tag, and a team that expects GitHub releases to reflect the shipped code will be misled.

For an evaluation, the practical checks are the NuGet page of the package you intend to use, the wiki platform table, and the source headers requirement if you plan to fork.

Editorial conclusion

Use 32feet.NET when a .NET application has to talk to Bluetooth, IrDA, OBEX or NFC hardware without writing platform-specific code, and pick the InTheHand.Net.Bluetooth or InTheHand.BluetoothLE package rather than the legacy 32feet.NET one. Do not choose it if you need features the project does not expose or a release process you can see from GitHub tags. First check the platform table in the wiki for your target OS, then read the source headers rule before you fork anything.

Frequently asked questions

Official sources

1. inthehand/32feet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases