Aperio — Plugin Developer Documentation

Aperio is extensible through plugins: self-contained shared libraries the app loads at runtime to add a new data provider or backend, without recompiling the app.

What a plugin can be

Every plugin is an adapter, and what it actually does is its capabilities list:

• calendar — events (Google, iCloud via CalDAV, Microsoft Graph, …).
• tasks — task lists and tasks (Vikunja, Todoist, …).
• contacts — address books.
• sync — a storage backend for cross-device sync (WebDAV, Dropbox, SFTP, …).
• videoconference — meeting links and rooms (WebEx, …).

Declare any combination. A tasks-only provider declares ["tasks"]; a provider that is both a calendar and a place to sync into declares both, ships one library, and signs in once — which is the reason capabilities, rather than the plugin type, decide what a plugin is.

This book uses calendar adapters for its examples (the most common kind); the ABI shape is identical for every other surface.

How it works, briefly

The app (the host) talks to a plugin across a stable C ABI — a table of function pointers (a vtable) per capability. You don’t have to write raw FFI: the Rust SDK (plugin-sdk) gives you macros so you implement ordinary Rust traits and a couple of macros generate the ABI glue. Domain data crosses the boundary as serde JSON.

Because it’s a C ABI, a plugin can in principle be written in any language that can export C symbols (Rust is recommended; C/C++/Zig are possible), and the ABI is versioned for forward compatibility.

Read this in order

Chapter	What you’ll do
Getting Started	Build a working minimal plugin in under 15 minutes.
The C ABI	The full contract: structs, lifecycle, vtables, memory rules, versioning.
The Rust SDK	The macros and helpers that hide the FFI.
The manifest	Every plugin.json field.
Examples	hello-world and a full calendar adapter template.

The contributor-facing docs for the app itself are the Developer Documentation.