I have been trying to package a FileMaker 18 runtime app* for Mac distribution for - oh - a year and a half on and off (the Windows version was packaged in an afternoon).
I succeeded - or thought I had - until I updated to Tahoe.
Now my packaging process does everything it did formerly (creates the DMG, etc.), but when opened, fails to see/load a third-party plugin (BaseElements.fmplugin).
Does anyone know why this should be?
I have attached 4 of my build files in the hope that someone can point me in the right direction.
Thanks in advance for any advice you may provide.
Regards,
L
*Claris deprecated the runtime feature years ago, but it still runs and is useful for proof of concept.
P.S. A contributor to an earlier query kindly suggested I go down the zip file or pkg installer route, rather than the DMG route. I tried doing as much but found both as susceptible to Mac spaghetti signage.
I admire your dedication to this task!
It’s hard to offer definitive advice without knowing more about how FileMaker loads plug-ins, but I suspect you’re being blocked by library validation. I downloaded that plug-in and took a look. First, I confirmed that it’s based on native code:
% file BaseElements.fmplugin/Contents/MacOS/BaseElements
BaseElements.fmplugin/Contents/MacOS/BaseElements: Mach-O … bundle …
Next, I looked at its code signature:
% codesign -d -vvv BaseElements.fmplugin
…
Authority=Developer ID Application: Goya Pty Ltd (GUZF844KMZ)
…
If your runtime is loading this is the traditional manner — that is, loading the plug-in bundle into your process’s address space — then library validation is an issue. Specifically:
- To distribute your app directly, you must notarise it.
- Notarisation requires the hardened runtime.
- The hardened runtime enables library validation by default.
- Library validation ensures that your app’s process will only load code signed by Apple or by your team.
So, your app tries to load a plug-in signed by another team and that’s blocked by the trusted execution system.
There are a couple of ways [1] around this:
- If you embed the plug-in within your app, it’s generally best to re-sign it as your code.
- If you load the plug-in from some other location on disk, you’ll need to disable library validation. To do this, sign your app with the
com.apple.security.cs.disable-library-validationentitlement.
IMPORTANT As noted in the docs, disabling library validation makes it harder to pass Gatekeeper. For a detailed explanation of that issue, see Resolving Gatekeeper Problems Caused by Dangling Load Command Paths.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Well, the best way around this is to switch to a plug-in model based on ExtensionKit, which doesn’t require you to load the plug-in code into your process, but that’s not an option for you because you’re relying on a runtime created by someone else.
