# libiio, the C library behind the Linux IIO userspace, and its v1.0 API break

> libiio is the cross platform C library for talking to Linux IIO devices, either locally on an embedded target or remotely from a Linux, Windows or Mac host over USB, Ethernet or serial. It suits engineers reading ADCs, DACs, accelerometers and RF parts from userspace, and its September 2026 release replaced the entire v0.x API, so migration is the central decision in adopting it now.

**analogdevicesinc/libiio** — A cross platform library for interfacing with local and remote Linux IIO devices

- Repository: https://github.com/analogdevicesinc/libiio
- Website: http://analogdevicesinc.github.io/libiio/
- Stars: 652 · Forks: 372
- Language: C
- License: LGPL-2.1
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/analogdevicesinc-libiio

## What the Linux IIO subsystem is for, and what libiio adds

libiio is the userspace interface to the Linux Industrial Input/Output subsystem, and the README describes that subsystem as intended to provide support for devices that in some sense are analog to digital or digital to analog converters.

The device list is broad, and it tells you the intended audience. Beyond ADCs and DACs, the subsystem covers accelerometers, gyros, IMUs, capacitance to digital converters, pressure sensors, colour, light and proximity sensors, temperature sensors, magnetometers, direct digital synthesis, phase locked loops, variable and programmable gain amplifiers, and RF transceivers. The topics list on the repository adds industrial-linux, iio-devices and linux-iio-drivers to that set.

The library itself is the layer above the kernel drivers. Its job is to give an application a uniform way to enumerate devices, discover their channels, and move samples, without the application having to know whether the device is on the other side of a USB cable or on the far side of a network.

It was primarily developed by Analog Devices, and the README states plainly that it is an active open source library to which many people have contributed. That combination, a vendor origin with outside contributors, is why the support routing is split: Analog Devices device questions go to EngineerZone, and questions about non-ADI devices go to GitHub issues.

## Local mode and remote mode over USB, Ethernet or serial

The two operating modes are the design decision that makes libiio useful beyond a single embedded board.

In local mode you use libiio natively on an embedded Linux target, talking to the IIO drivers on that same machine. In remote mode you use libiio to communicate remotely to that same target from a host Linux, Windows or Mac, over USB, Ethernet or serial.

The point of the remote mode is that the application does not change. The same code that reads a channel on the target reads a channel on the host, with the transport moved out of the way. For a test bench, a data acquisition station or a monitoring service on a laptop, that is the difference between writing one program and writing two.

The repository layout shows how the split is implemented. There is a context.c, which is the connection to the IIO context, and a device.c and channel.c for the device model. The remote side is the iiod/ directory, with iiod-responder.c and iiod-client.c implementing the daemon and its client, and there is an iiod-emu/ directory for emulation. A compat.c and an iio-compat.h are present, which is consistent with the compatibility layer described for v1.0. The DNS service discovery files, dns_sd_avahi.c, dns_sd_bonjour.c and dns_sd_windows.c, exist so a host can find a remote target on the network without being told its address.

## The v1.0 API break is the whole adoption story

The README carries an important note dated 2026-09-22 stating that libiio v1.0.0 has been released with a brand new API, which is incompatible with libiio v0.26 and older. There is a migration guide describing the API changes.

The old API is not gone. It lives in the libiio-v0 branch, and the README says libiio v0.x is now considered legacy, so only important bug fixes will be accepted into that branch. The release list shows how sharp the break was: v0.26 came in September 2024 and v1.0.0 arrived on 2026-09-22, with the versions in between not appearing as named releases.

There is one piece of good news for existing deployments. Old programs compiled against libiio v0.x will still be able to run with libiio v1.0 and newer, because v1.0 provides a compatibility layer. So a device that ships a binary does not have to be rebuilt the day you upgrade the library on the host.

What you cannot avoid is source-level work if you are writing new code or changing existing code against the v0 API. Read the migration guide before estimating that work, because a 1.0 major version in a library of this size usually means the object model, not just function signatures, has been reworked.

## Getting libiio: release packages for the common platforms

The installation story for a C library with hardware bindings is mostly about the kernel side, and the README is explicit about where to get what.

The recommended path for users is the latest release, and the release table for v1.0.0 lists installer packages: a Windows 64 setup executable, macOS packages for macOS 15 and macOS 14 on x64 and a macOS Ventura package for arm64, and Debian packages for Ubuntu 26.04, Ubuntu 24.04 and Ubuntu Jammy Jellyfish on 22.04. So the mainstream host platforms are covered by prebuilt installers, which is a change from a world where you built the library from source.

For development, the README points to the latest untested binaries from the main branch and the documentation built from that branch, and notes that builds are provided for a few operating systems while asking for other platforms can most likely be arranged.

Building from source is documented in README_BUILD.md and README_DEVELOPERS.md, and the repository carries a CMakeLists.txt, a cmake/ directory, a CI/ directory and a format.sh script. The source files at the root are the library core: context.c, device.c, channel.c, buffer.c, block.c, attr.c, emu.c, events.c, and the platform-specific dynamic.c, dynamic-unix.c and dynamic-windows.c. A .clang-format, .clangformatignore, .cmakeformatignore, .pylintrc, .vale.ini and .codespell-ignore.txt sit alongside, which tells you the project runs a fairly wide set of format and lint checks across C, Python and prose.

## The examples show what a real capture loop looks like

The examples directory is where a new user should start, because it shows the library used against named parts rather than in the abstract.

There are iiostream examples for several Analog Devices parts, including ad9361-iiostream.c, ad9371-iiostream.c, adrv9002-iiostream.c and adrv9009-iiostream.c, the last two being the RF transceiver families. There is a dummy-iiostream.c, which is the one to read first if you want to understand the streaming pattern without hardware attached. A shared iiostream-common.c and iiostream-common.h hold the parts common to those examples.

Beyond the streaming examples, iio-monitor.c is a monitoring utility, and iio_adi_xflow_check.c is a check specific to Analog Devices parts. The examples README and CMakeLists.txt are in the same directory, and there is a tinyiiod-linux/ subdirectory, which appears to be a minimal deployment of the remote daemon for a Linux target.

That naming pattern is itself informative. The library does not present a single abstract API for reading samples, it presents a set of buffer and stream abstractions that a given part's driver supports differently, and the examples exist because that support varies. Read dummy-iiostream.c first, then the example for your own part.

## Three licences in one tree, and what each covers

The licensing is split across the tree and the README explains the arrangement rather than leaving it to the badge.

The library itself is released under the GNU Lesser General Public License version 2.1, or at your option any later version. The LGPL is the choice that lets the library be linked into a proprietary or commercial application, with the obligation that modifications to the library itself stay open. The README states that this open source licence allows anyone to use the library on any vendor's processor, FPGA or SoC, controlling any vendor's peripheral device, locally or remotely, including in closed or open source, commercial or non-commercial applications, subject to the licence freedoms, obligations and restrictions.

The examples and test applications, referred to as the iio-utils, are released separately under the GNU General Public License version 2.0 or later. That is the standard split, and it means the example code you copy into your own project is GPL, while linking against the library is not.

There is a third category, certain files, under the MIT licence, with its own COPYING_MIT.txt alongside COPYING.txt for the LGPL and COPYING_GPL.txt for the utilities. The badge links point at each of these three files, so the terms are explicit rather than implied.

One practical note for evaluation: the LGPL obligations attach to modifications of the library and to how you distribute it, so if you plan to patch the library rather than only call it, the licensing question is more involved than for a permissively licensed library.

## Conclusion

Adopt libiio v1.0 if you need to read or drive analog peripherals from userspace, either on the embedded Linux target itself or from a host over USB, Ethernet or serial, since the library already covers the device model, the streaming and the remote daemon. Do not adopt the v0.x branch for new work, since it is considered legacy and receives only important bug fixes. Before you commit, read the migration guide, because the v1.0 API is incompatible with v0.26 and older, decide whether you need the compatibility layer that lets old binaries run against v1.0, check that your device has a Linux IIO kernel driver, and note the licensing split, with the library under LGPL 2.1, the iio-utils examples under GPL 2.0 and certain files under MIT.

## FAQ

### What is the difference between libiio v1.0 and the older v0.x API?

The v1.0.0 release on 2026-09-22 introduces a brand new API that is incompatible with libiio v0.26 and older, and a migration guide describes the changes. The v0.x API is kept on the libiio-v0 branch and is now considered legacy, so only important bug fixes are accepted there.

### Do old libiio programs still work against libiio v1.0?

Yes. The README states that old programs compiled against libiio v0.x will still be able to run with libiio v1.0 and newer, because v1.0 provides a compatibility layer. New code written against the v0 API still needs to be migrated.

### What devices does libiio support?

The Linux IIO subsystem it interfaces with covers ADCs, DACs, accelerometers, gyros, IMUs, capacitance to digital converters, pressure sensors, colour, light and proximity sensors, temperature sensors, magnetometers, DDS, PLLs, variable and programmable gain amplifiers, and RF transceivers.

### How do I use libiio from a remote host?

You run the same libiio code against a remote target instead of a local one, connecting from a Linux, Windows or Mac host over USB, Ethernet or serial. The remote side is the iiod daemon in the iiod directory, and the tree includes DNS service discovery support through the Avahi, Bonjour and Windows implementations.

### What licence applies to libiio and to its examples?

The library is under LGPL version 2.1 or any later version, the examples and test applications known as the iio-utils are under GPL version 2.0 or any later version, and certain files are under the MIT licence. The tree carries COPYING.txt, COPYING_GPL.txt and COPYING_MIT.txt.

## Sources

- [analogdevicesinc/libiio on GitHub](https://github.com/analogdevicesinc/libiio)
- [License: LGPL-2.1](https://github.com/analogdevicesinc/libiio/blob/main/LICENSE)
- [Project website](http://analogdevicesinc.github.io/libiio/)
- [README](https://github.com/analogdevicesinc/libiio/blob/main/README.md)
- [Releases](https://github.com/analogdevicesinc/libiio/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/analogdevicesinc-libiio