« Three weeks till year… | Home | Upcoming changes for … »

With Xojo 2025r3 we got a new thing: Libraries

A library is a way to bundle project items for reuse as a binary file and give them to other developers to use them. Like a plugin, but of course not a plugin.

Build a library

You start by creating projects where you develop your library. For each target you need a separate project: Console, Desktop, Web, and iOS. The project may have some unit tests to run and some test functionality for you as developer to try your library functions.

When you build your project, Xojo will make an application. And next to the project you find the Xojo library. You may need to build the projects multiple times and switch between ARM and x64 for Windows *1. Each library is compiled into machine code with Xojo's compiler and written into a xojo_library file.

The library file is a zip archive and you can unpack it. The structure is for example this:

Library1
   LibraryInfo.json
   Console
      OSX_x86_64
         Module1.o
      OSX_ARM64
         Module1.o
      API
         Module1.xojo_code

The LibraryInfo.json file contains some metadata from the build settings:

{
    "Version": "1.0",
    "Copyright": "Christian Schmitz",
    "Description": "Just a test module",
    "BuildDate": "2025-12-07 09:41:50",
    "IDEVersion": "2025.03"
}

The library contains a folder for the target. So you can unpack the libraries for Console, Desktop, Web, and iOS. Then pack them together into a bigger library supporting multiple targets in one library. For Windows and Linux we may need to build twice (ARM and x64) and merge the libraries:

Each library is build with a specific version of the Xojo compiler. Since it produces native machine code, a different version of the compiler could possibly link it into an application. But your library references framework functions and if they change name, index or parameters, things will break. So in future whenever a new Xojo version appears, you may try to check if your library still works. If not, you may need to ship multiple versions for various Xojo versions.

Next you may want to the API code included. This is the public interface of your library. Be aware that this will show all the declarations of methods, properties and events. There is a feature request *2 to skip the private items there, which are not needed for compiling.

Use the library

To use the library, you place it inside the Plugins folder or the project folder. Whenever you open a project, Xojo will load the libraries from both locations. Then you can use them and they appear in autocomplete.

A library can use things from other libraries or from plugins. Then the developer using the library needs to have the same interface. The library can also refer to things in the project using the library. Let's construct this:

In our library project, we add a method named test to the application object app. Then in the library we can call that method. Like as a callback to the project or for example to have the library use a central Log method.

Now we use that library in a new project. The method doesn't exist. What will happen? Seems like nothing happens in my test as the call to the non existing method is ignored, but it could also crash with an exception. The method in app gets called by index in the method table. So I can use the a call to app.test in a project. Then when I rename the first method and make a second one, I can see the first one called. Just to confirm they are called by index, not by name.

That has consequences. Like if you use a dictionary and call "Value(key as variant) as variant" to get a value, you actually call method at offset 11 in the virtual table. If that index moves with a future Xojo version, the library breaks.

Libraries can carry control subclasses, which show in the control library for use. They can declare properties to show up in the inspector for that control. If you need some JavaScript for a Web control, you can include it as a constant. But that constant will appear in the public code *3. Also you can easily spot it inside the compiled code.

As you see this is a fantastic new thing to discover and figure out all the details. There will probably be changes coming to Xojo in the next versions to improve.

See also Checking Out Xojo Libraries, Creating Libraries that Support Multiple Project Types and Documentation.

  1. Build apps for multiple architectures in one pass and Change Build Settings for 64-Bit
  2. Hide private shared methods/properties in libraries public interface
  3. Exclude private constants from public interface of library
The biggest plugin in space...
10 12 25 - 12:13