Skip to main content
A plugin’s signature is checked only outside the app’s own PlugIns directory. That one rule explains all three ways to run a plugin you built locally, and which of them a release build of TablePro would also accept. The dev script is the normal route; the other two are for when the signature check itself is in your way. See Plugin Development for writing the driver and Plugin Registry for publishing it.

​
Where plugins load from

PluginManager reads two directories on launch and treats them differently. The version key goes first either way: a plugin whose TableProPluginKitVersion falls outside the app’s compatible range is rejected before anything looks at its signature. The signature check accepts one signer: the Apple team that signed the running app, which for a release is TablePro. Your own debug build accepts what your own Xcode signed for the same reason. Every other signature, ad-hoc signing and an unsigned bundle are refused, and nothing asks. Do not reuse a built-in plugin’s bundle ID. Installing over one fails outright, and at discovery the higher build (CFBundleVersion) wins, with the built-in taking a tie and the losing user copy deleted from disk.

​
Install with the dev script

It finds the newest MyDriverPlugin.tableplugin under DerivedData and copies it into the user plugins directory. Relaunch TablePro to load it. Build from Xcode first: the script reads DerivedData, and a command-line xcodebuild writes to build/Debug instead, where the script never looks.
Never edit the copied bundle, Info.plist included. Any change invalidates the code signature and dyld then refuses to load the executable.

​
Bundle it into the app instead

A plugin embedded in PlugIns/ skips the signature check entirely, which is the shortest path when the team check is the thing in your way. Add the target to the app’s dependency list in apple/project.yml:
Then run apple/scripts/generate-project.sh and build. XcodeGen puts the bundle in an Embed Dependencies copy phase with CodeSignOnCopy, so it is re-signed with your debug identity on the way in.
apple/TablePro.xcodeproj is generated and gitignored, so adding the plugin through the Xcode UI survives exactly until the next apple/scripts/generate-project.sh. Edit apple/project.yml. Take the entry back out before you open a pull request, or the plugin rides into a release build.

​
Skip the signature check

A Debug build skips signature verification altogether when TABLEPRO_ALLOW_UNSIGNED_PLUGINS is set to 1. Set it under Product > Scheme > Edit Scheme > Run > Arguments, in the environment variables list. This is the route for a bundle built on another machine or signed by another team. The bundle still has to be validly signed for dyld to load it at all. The escape hatch is compiled out of Release builds, so it cannot mask a signing problem that would reach a user.

​
When it does not load

The reason lands in a Plugin Installation Failed alert when installing, and in the banner in Settings > Extensions otherwise. Once it loads and works, publish it through the Plugin Registry so users get a signed binary.