Discover ways to create a plugin system utilizing dynamic libraries and the ability of Swift, aka. modular frameworks on the server-side.
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 numerous invocation factors and hooks. The one downside with that method is that you would be able to’t actually activate or off modules on-the-fly, since we normally construct our apps in a static method.
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’ll be able to add further performance to the CMS with out recompiling or altering the core. Exterior the Apple ecosystem, there’s a enormous world that might benefit from 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’ve got this superb type-safe programming language that we are able to use. Swift is quick and dependable, it’s the good selection for constructing backend apps on the long run. ✅
On this article I wish to present you a easy methods to construct a dynamic plugin system. The entire idea is predicated on Lopdo‘s GitHub repositories, he did fairly a tremendous job implementing it. Thanks very a lot for displaying me easy methods to use dlopen
and different comparable features. 🙏
The magic of dynamic linking
Handmade iOS frameworks are normally bundled with the applying itself, you’ll be able to be taught just about every little thing a few framework if you recognize some command line instruments. This time we’re solely going to deal with static and dynamic linking. By default Swift package deal dependencies are linked statically into your utility, however you’ll be able to change this in case you 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(
title: "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’ll want one thing like a builder to assemble the specified object. We will use a brand new summary class for this goal.
open class PluginBuilder {
public init() {}
open func construct() -> PluginInterface {
fatalError("It's a must to override this technique.")
}
}
That is our dynamic plugin interface library, be happy 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(
title: "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 lengthen this protocol primarily based in your wants, you may as well use different frameworks as dependencies.
import PluginInterface
struct PluginA: PluginInterface {
func foo() -> String {
return "A"
}
}
We’ve 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 avoid wasting our operate beneath the “createPlugin” image title.
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 venture folder. Now you could find the dylib file beneath the binary path, be happy to run swift construct --show-bin-path
, this may output the required folder. We’ll want each .dylib recordsdata for later use.
Loading the plugin at runtime
The core utility can even use the plugin interface as a dependency.
import PackageDescription
let package deal = Package deal(
title: "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 major.swift
file.
import Basis
import PluginInterface
typealias InitFunction = @conference(c) () -> UnsafeMutableRawPointer
func plugin(at path: String) -> PluginInterface {
let openRes = dlopen(path, RTLD_NOW|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
technique. If we’ve got a pointer we nonetheless must forged that into a sound PluginBuilder
object, then we are able to name the construct technique and return the plugin interface.
Working the app
Now in case you 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 previous bug, however fortuitously that’s already resolved. This time Xcode is the dangerous man, since it’s making an attempt to hyperlink every little thing as a static dependency. Now in case you construct the applying by means of the command line (swift construct) and place the next recordsdata 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 just wish 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 precise plugin path within the core utility.