Swift has become the first go-to-language whenever I am going to build something on macOS or iOS. Recently, I was trying to write a quick look plugin in Swift but met some problems.
First, the default quick look plugin files generated by Xcode were
.c. Swift is compatible with Objective-C and they can interact with each other well. Swift can also handle C API well but it’s not easy to call Swift from
.c files. I changed the file extension from
.m and got it fixed.
However, the next problem would not be that easy to fix. After I finished the code and tried to run it in
qlmanage failed to load my plugin because it was unable to find
libswiftCore.dylib. I checked the Build Settings and set Always Embed Swift Standard Libraries to YES so that all the Swift libraries can be copied to the frameworks directory in the plugin. To make the
qlmanage find the frameworks, I also set Runpath Search Paths to
@load_path/../Frameworks but the libraries were still not loading. I turned on the debug log by running
qlmanage -d4 and found
@load_path/../Frameworks “being ignored in restricted program because it is a relative path”.
I posted a question in Apple Developer Forums and quickly got an answer with detail. The short answer is “No”.
No. You could probably make this work but it’s definitely not safe.
The fundamental problem here is the Swift runtime. Quick Look plug-ins are hosted in a system process and it’s possible that that system process might load multiple plug-ins. If there are two plug-ins written in Swift, they might have different versions of the Swift runtime and that will not end well.
The reply also suggested two approaches:
- Eventually Swift will reach ABI stability and be bundled in the system instead of bundled in apps or plug-ins.
- Moving Quick Look over to use the new plug-ins mechanism based on app extension, which allows plug-ins to run in their own process.
As the replier suggested, I opened an request in Apple Bug Reporter and the problem ID is 32095249 . Have a check if you also interested in it.