Shared technical settings

The Shared tab is where you define technical settings that apply across your whole plugin, rather than to a single element or action. This covers dependencies, code you want injected into the pages of apps that use your plugin, extra keys, shared assets, and the React Native libraries available to mobile plugins.

Dependencies are the shared building blocks your plugin relies on to run.

The Bubble plugin API version sets which version of Bubble's plugin API your plugin runs against. Each version introduces changes to how plugins behave, and you can see what changed in each one by clicking Show changelog.

We recommend using the latest version, since it includes the most recent improvements and fixes. If you're maintaining an older plugin, though, be aware that moving up a version may require changes to your code, so review the changelog before switching.

Check Include jQuery 3 in apps using this plugin if you're building an element that relies on jQuery 3. When checked, the API gives you access to jQuery.

The HTML header lets you add code to the <head> section of every page in an app that uses your plugin. This is common for services like analytics tools, which usually need a snippet present on all pages to work.

To let the people using your plugin supply their own values, like an API key or a tracking code, wrap a dynamic value in the sequence _*_NAME_*_. That value then appears as a key in the Plugins tab of any app using your plugin, and Bubble replaces it with the actual value in run mode.

Authentication keys defined in your API calls are added automatically, so you don't need to re-enter them here. Use the Additional keys section to expose any extra keys your elements or actions need. Once defined, these keys are available in the context object that's passed to all the functions in your elements and actions.

The Shared assets and resources section lets you upload files your plugin code references at run time, such as logos, fonts, or fixtures. Uploaded files are hosted on Bubble's CDN, so they load quickly, and their URLs stay stable across plugin versions, so links in your code won't break when you publish an update.

If you're building a mobile plugin, you have access to a set of React Native libraries that Bubble has already installed. These give you native components and APIs to build with, so you can reach device features and native functionality directly from your plugin. You can reference any of them in your plugin's code and test them on BubbleGo out of the box.

Using a library isn't required. You can write plain React Native to build more generic elements and actions that don't rely on any external libraries or APIs. The libraries are there when you need native functionality, not something you have to reach for every time.

Beyond the built-in libraries, you can import additional React Native libraries into your plugin. Declare the library in the Additional libraries section using the same JSON shape as the built-in list: the library name as the key, and the version as the value.

This works the same way as declaring a dependency in a package.json file. Once you've added a library, you'll need a development build to test an app that uses your plugin, since the library has to be compiled into the app.

A mobile plugin can declare a third-party library at a specific version. Since an app can have several plugins installed, two plugins might declare the same library at different versions. When that happens, only one version can load, an app can't run multiple versions of the same library at once.

Bubble resolves this in a set order:

Because of this, a plugin that expects an older version of a library may not work as expected when a newer version ends up being the one that loads.

If you run into a conflict, the practical step is to reach out to the plugin's developer, since resolving it usually means aligning on a compatible version.

Bubble's web preview runs on React Native for web, so not every plugin can be tested there, depending on compatibility. If your plugin uses a feature web preview can't run, like opening the device camera, test it on a device instead. BubbleGo covers plugins that only use Bubble's built-in libraries; for any other library, use a development build.

Some libraries need access to device features, like contacts, the camera, or location. On both iOS and Android, an app has to declare up front which of these features it intends to use, or the app store will reject it and the feature won't work on the device. The Native configuration section is where you make those declarations for the libraries your plugin uses: plist keys on iOS, and manifest entries on Android. The people using your plugin can override these values before they build their app.

If a permission is already handled by the editor, it isn't requested again. For example, if the editor already offers camera access, a plugin that uses a camera library won't prompt the user for it a second time.

On iOS, each protected feature has a matching plist key, and every key you add needs a description string, known as a purpose string. This string is shown to the user in the system permission prompt, so it should explain clearly why the app needs access. For a plugin that reads contacts, for example, you'd add the NSContactsUsageDescription key with a description like "Lets you find and invite people from your contacts."

To add one, select a plist key, enter a default description string, and click Add iOS entry.

On Android, permissions and other native settings are declared as entries in the app's manifest. You select an element type and enter its XML attributes.

The most common entry is a uses-permission element, which requests a single system permission. To request camera access, for example, you'd add a uses-permission element with the attribute android:name="android.permission.CAMERA", which produces:

The manifest can hold other kinds of entries too, not just permissions, so some libraries may ask you to add a different element type with its own attributes.

To add one, select an element type, enter its attributes, and click Add Android entry.