FGDSamplePlugin - A Swift port of RMSSamplePlugin (plugin SDK sample project)

Hi guys,
I’ve ported RMSSamplePlugin to Swift and would like to share the result with you.

Comments and contributions are welcome.

FGDSamplePlugin repository is available here.

you would need to build a swift plugin targeted at the swift runtime that is being used by the customer that launches the app. but since the customer might be running a few different versions of the app and that might contain a few different versions of the runtime – this is not practical.

realistically i don’t think it will be possible to use swift for dynamically loaded plugins that are shipped separately from the app itself until Apple includes the swift runtime as a part of the OS.

Not sure I get what you mean.

Plugin is built with its own Swift runtime. This is actually the main drawback I’ve noticed so far: increased compiled size for the Swift version of SamplePlugin, due to fat Frameworks folder.

But I admit I’ve not tested it on older OS X versions yet.

EDIT: Tested on the targets I’m interested in (10.9 - 10.11) and everything seems to work as expected.

I’ve been in touch with an Apple engineer about this matter.

He warned me that “Swift does not have a stable Application Binary Interface at this point in its lifetime” and the process “would crash if multiple plugins bundling the Swift runtime were loaded simultaneously”.

I’ve built two separate Swift plugins using different Xcode versions. Each plugin bundles with a different version of Swift runtime. Still, I’m able to use simultaneously both of them in RW 6 with no crashes nor log complaints about conflicting library versions.

Any thoughts?

Nearly 3 years later, the same sample swift plugin is still working for me, no need to recompile it but, AFAIK no other plugins are loading a different version of Swift runtime.

That said… should we still avoid Swift as plugin development language?

for Obj-C the runtime is part of the OS and there is stability in the ABI between versions. So a macOS 10.9 app will run in the 10.10 runtime without issue and a macOS 10.10 app will even run in 10.9 – so long as you don’t call 10.10 methods.

But macOS does not include a Swift runtime and the Swift ABI is NOT stable. This means the runtime needs to be included inside the app bundle (or the plugin, i suppose). and the Swift team does not yet guarantee that a Swift 2 app will work in Swift 3. and since the runtime is included with the app it means that even point releases need not be compatible with each other. Each app runs its own binary in its own runtime – perfectly matched.

But how do you keep a plugin matched??? Since the plugin will be running in the runtime of app, the plugin needs to be compiled with an identical version of Swift as the app was compiled in.

In theory, this means that you would need to compile a version of your plugin every time RapidWeaver released a new version that included a new point release of the swift runtime (usually a couple times a year???). And users would only be able to use your plugin on exactly that release of RapidWeaver – any other release could, at least in theory, crash.

Like most binary compatibility, however – there is probably a lot that works and a lot that is already mostly stable – they have been working toward stability for several years now. So I would guess that your plugin continues to work well because:

  1. it is very simple – you will probably only bump into the ABI compatibility when you exercise recent changes to the language – or changes to the ABI.
  2. realmac may not be updating their own sdk that often – i know i only update occasionally myself, as it always causes a new load false issues that must be worked around.

obviously, it’s not impossible to write a plugin in swift – however since you can only be sure it will run on a few point releases of RW – and any new release could potentially kill your plugin – i don’t think i will be doing that anytime soon. :wink:

i myself have stopped coding in swift except for occasional test code and contract work. even when the ABI does stabilize, we will have to wait for the next OS version to start including the runtime. and even then, to use swift, you’d have to require that very latest OS version. yuck.

but if you do decide to go this route i’ll watch closely. i’m curious to see how it goes.


1 Like

Thanks for sharing your point of view, much appreciated.

I’m not sure I’m going to pioneering this with a commercially available plugin, as it’s seem challenging and would easily lead to important headaches.

That said, even if large code bases and possibly RW itself will never be rewritten in Swift, each time we start thinking of a new plugin I find it appealing. And a breath of fresh air would do good for the community and possibly attract new developers.

1 Like