Building and loading dynamic libraries at runtime in Swift

Why ought to we make a plugin system?

Within the modules and hooks article I used to be writing about how modules (plugins) can work collectively through the use of varied invocation factors and hooks. The one drawback with that strategy is that you could’t actually activate or off modules on-the-fly, since we often construct our apps in a static means.

An excellent plugin system ought to allow us to alter the conduct of our code at runtime. WordPress plugins are extraordinarily profitable, as a result of you possibly can add additional performance to the CMS with out recompiling or altering the core. Outdoors the Apple ecosystem, there’s a large world that might make the most of this idea. Sure, I’m speaking about Swift on the server and backend functions.

My thought right here is to construct an open-source modular CMS that may be quick, protected and extensible by means of plugins. Thankfully now we now have this superb type-safe programming language that we are able to use. Swift is quick and dependable, it’s the excellent selection for constructing backend apps on the long run. ✅

On this article I want to present you a methods to construct a dynamic plugin system. The entire idea relies on Lopdo‘s GitHub repositories, he did fairly an incredible job implementing it. Thanks very a lot for exhibiting me methods to use dlopen and different comparable capabilities. 🙏

The magic of dynamic linking

Handmade iOS frameworks are often bundled with the applying itself, you possibly can study just about everything about a framework if you recognize some command line instruments. This time we’re solely going to give attention to static and dynamic linking. By default Swift package dependencies are linked statically into your utility, however you possibly can change this for those who outline a dynamic library product.

First we’re going to create a shared plugin interface containing the plugin API as a protocol.

import PackageDescription

let package deal = Package deal(
    identify: "PluginInterface",
    merchandise: [
        .library(name: "PluginInterface", type: .dynamic, targets: ["PluginInterface"]),
    ],
    targets: [
        .target(name: "PluginInterface", dependencies: []),
    ]
)

This dynamic PluginInterface package deal can produce a .dylib or .so file, quickly there might be a .dll model as properly, primarily based on the working system. All of the code bundled into this dynamic library might be shared between different functions. Let’s make a easy protocol.

public protocol PluginInterface 

    func foo() -> String

Since we’re going to load the plugin dynamically we are going to want one thing like a builder to assemble the specified object. We will use a brand new summary class for this function.

open class PluginBuilder 
    
    public init() 

    open func construct() -> PluginInterface 
        fatalError("You must override this methodology.")
    

That is our dynamic plugin interface library, be at liberty to push this to a distant repository.

Constructing a dynamic plugin

For the sake of simplicity we’ll construct a module known as PluginA, that is the manifest file:

import PackageDescription

let package deal = Package deal(
    identify: "PluginA",
    merchandise: [
        .library(name: "PluginA", type: .dynamic, targets: ["PluginA"]),
    ],
    dependencies: [
        .package(url: "path/to/the/PluginInterface/repository", from: "1.0.0"),
    ],
    targets: [
        .target(name: "PluginA", dependencies: [
            .product(name: "PluginInterface", package: "PluginInterface")
        ]),
    ]
)

The plugin implementation will after all implement the PluginInterface protocol. You’ll be able to prolong this protocol primarily based in your wants, you can too use different frameworks as dependencies.

import PluginInterface

struct PluginA: PluginInterface 

    func foo() -> String 
        return "A"
    

Now we have to subclass the PluginBuilder class and return our plugin implementation. We’re going to use the @_cdecl attributed create operate to entry our plugin builder from the core app. This Swift attribute tells the compiler to save lots of our operate beneath the “createPlugin” image identify.

import PluginInterface

@_cdecl("createPlugin")
public func createPlugin() -> UnsafeMutableRawPointer 
    return Unmanaged.passRetained(PluginABuilder()).toOpaque()


remaining class PluginABuilder: PluginBuilder 

    override func construct() -> PluginInterface 
        PluginA()
    

We will construct the plugin utilizing the command line, simply run swift construct within the undertaking folder. Now you could find the dylib file beneath the binary path, be at liberty to run swift construct --show-bin-path, it will output the required folder. We’ll want each .dylib information for later use.

Loading the plugin at runtime

The core utility may even use the plugin interface as a dependency.

import PackageDescription

let package deal = Package deal(
    identify: "CoreApp",
    dependencies: [
        .package(url: "path/to/the/PluginInterface/repository", from: "1.0.0"),
    ],
    targets: [
        .target(name: "CoreApp", dependencies: [
            .product(name: "PluginInterface", package: "PluginInterface")
        ]),
    ]
)

That is an executable goal, so we are able to place the loading logic to the important.swift file.

import Basis
import PluginInterface

typealias InitFunction = @conference(c) () -> UnsafeMutableRawPointer

func plugin(at path: String) -> PluginInterface RTLD_LOCAL)
    if openRes != nil 
        defer 
            dlclose(openRes)
        

        let symbolName = "createPlugin"
        let sym = dlsym(openRes, symbolName)

        if sym != nil 
            let f: InitFunction = unsafeBitCast(sym, to: InitFunction.self)
            let pluginPointer = f()
            let builder = Unmanaged<PluginBuilder>.fromOpaque(pluginPointer).takeRetainedValue()
            return builder.construct()
        
        else 
            fatalError("error loading lib: image (symbolName) not discovered, path: (path)")
        
    
    else 
        if let err = dlerror() 
            fatalError("error opening lib: (String(format: "%s", err)), path: (path)")
        
        else 
            fatalError("error opening lib: unknown error, path: (path)")
        
    


let myPlugin = plugin(at: "path/to/my/plugin/libPluginA.dylib")
let a = myPlugin.foo()
print(a)

We will use the dlopen operate to open the dynamic library file, then we try to get the createPlugin image utilizing the dlsym methodology. If we now have a pointer we nonetheless must solid that into a sound PluginBuilder object, then we are able to name the construct methodology and return the plugin interface.

Working the app

Now for those who attempt to run this utility utilizing Xcode you will get a warning like this:

Class _TtC15PluginInterface13PluginBuilder is applied in each…
One of many two might be used. Which one is undefined.

That is associated to an outdated bug, however fortuitously that’s already resolved. This time Xcode is the dangerous man, since it’s making an attempt to hyperlink the whole lot as a static dependency. Now for those who construct the applying by means of the command line (swift construct) and place the next information in the identical folder:

• CoreApp
• libPluginA.dylib
• libPluginInterface.dylib

You’ll be able to run the applying ./CoreApp wihtout additional points. The app will print out A with out the warning message, because the Swift package deal supervisor is recognizing that you simply want to hyperlink the libPluginInterface framework as a dynamic framework, so it will not be embedded into the applying binary. After all you need to arrange the appropriate plugin path within the core utility.