Skip to main content

​
Testing a Custom Plugin

When you write your own driver plugin, you can run it inside a local debug build of TablePro before publishing it to the registry. If you package the plugin and install it the way the app installs a registry plugin, it fails with “Unable to install plug-in.” The install path only accepts plugins signed by TablePro’s signing team, and a plugin you just built locally is not signed by it. The way around this is to let the plugin ship inside the app bundle instead of installing it as a user plugin. Add it to the Copy Plug-Ins build phase, then run the app. Plugins that live inside the app bundle load as built-in plugins, which are not put through the signature check.

​
Steps

1

Add the plugin to Copy Plug-Ins

In Xcode, select the TablePro target, open the Build Phases tab, and add your .tableplugin bundle to the Copy Plug-Ins phase.
2

Run the app

Press Cmd+R to build and run. See Building for the -skipPackagePluginValidation requirement on command-line builds.
3

Test the plugin

The plugin loads with the app. Create a connection for your database type and confirm the driver works.
4

Remove it after testing

Once the plugin works, remove it from the Copy Plug-Ins phase so it does not ride into a release build.
Keep the plugin in Copy Plug-Ins only while you are testing. Release builds distribute plugins through the Plugin Registry, where every binary is signed.

​
Why the signing error happens

TablePro loads plugins from two locations, and treats them differently:
  • Inside the app bundle (PlugIns/): loaded as built-in plugins. No signature check runs.
  • In the user plugins directory: loaded as user-installed plugins. Each one must be signed by TablePro’s signing team, or it is rejected.
Installing a plugin from the registry, or packaging your own to install the same way, goes through the user-installed path. A plugin you built locally does not carry TablePro’s signature, so that path rejects it with “Unable to install plug-in.” Adding the plugin to Copy Plug-Ins avoids the check on two counts. The plugin lands in the app’s PlugIns/ directory, so it loads as a built-in plugin and the user-install signature check never runs. The phase also re-signs the plugin with the debug build’s own signing identity (CodeSignOnCopy) as it copies it in.

​
Alternative: allow unsigned user plugins

If you would rather keep developing the plugin from the user plugins directory, a debug build skips the signature check when the TABLEPRO_ALLOW_UNSIGNED_PLUGINS environment variable is set to 1. Set it under Product > Scheme > Edit Scheme > Run > Arguments. This works in debug builds only. Release builds always verify the signature. When the plugin is ready to ship, publish it through the registry so users receive a signed binary. See Plugin Registry for the manifest format and publishing flow.