Mobile: Plugin support

personalizedrefriger · 21 March 2024 23:56

Mobile plugin support has been merged and should be present in the Joplin v3.0.1 pre-release for Android:

See the following GitHub issue for more information about plans for plugin support on iOS:

github.com/laurent22/joplin

iOS: Enable plugin support

opened 04:29PM - 18 Mar 24 UTC

personalizedrefrigerator

enhancement medium

### Operating system iOS ### Joplin version 3 ### Desktop version in…fo _No response_ ### Current behaviour Currently, plugin support is disabled in the iOS app because of [this section of the iOS AppStore guidelines](https://developer.apple.com/app-store/review/guidelines/#third-party-software) (accessed March 18 2024): > **4.7 Mini apps, mini games, streaming games, chatbots, and plug-ins** > > Apps may offer certain software that is not embedded in the binary, specifically mini apps, mini games, streaming games, chatbots, and plug-ins. You are responsible for all such software offered in your app, including ensuring that such software complies with these Guidelines and all applicable laws. Software that does not comply with one or more guidelines will lead to the rejection of your app. You must also ensure that the software adheres to the additional rules that follow in 4.7.1 and 4.7.5. These additional rules are important to preserve the experience that App Store customers expect, and to help ensure user safety. > > - **4.7.1** Software offered in apps under this rule must: > - follow all privacy guidelines, including but not limited to the rules set forth in Guideline 5.1 concerning collection, use, and sharing of data, and sensitive data (such as health and personal data from kids); > - include a method for filtering objectionable material, a mechanism to report content and timely responses to concerns, and the ability to block abusive users; and > - use in-app purchase in order to offer digital goods or services to end users. > - **4.7.2** Your app may not extend or expose native platform APIs to the software without prior permission from Apple. > - **4.7.3** Your app may not share data or privacy permissions to any individual software offered in your app without explicit user consent in each instance. > - **4.7.4** You must provide an index of software and metadata available in your app. It must include universal links that lead to all of the software offered in your app. > - **4.7.5** Your app must share the age rating of the highest age-rated content available in your app. To support this, we will likely need to: 1. Review and approve a subset of plugins. 2. Disable access to certain parts of the plugin API (e.g. clipboard access) on iOS. ## Supporting plugin review Here are a few ideas for how we might support only showing reviewed plugins on iOS: > [!NOTE] > > Both of the ideas mentioned below continue to use GitHub as the source for downloading plugins. Depending on how trusted [the GitHub mirrors](https://github.com/laurent22/joplin/blob/56b010ba0ea22b03619f387ecfd428837095f761/packages/lib/services/plugins/RepositoryApi.ts#L19) are, we may need to disable them on iOS. Alternatively, reviewed plugins could be signed. > ### 1. Create a separate repository for reviewed plugins This repository could be located at `joplin/plugins-reviewed` or perhaps be a separate branch of the existing plugin repository. Joplin maintainers manually update plugins in this repository after reviewing them. With this method, the plugin review process would be similar to the following: 1. A maintainer either 1. Reviews the source code of the plugin locally, then builds the plugin and uploads it to the "reviewed" repository, or 2. Extracts the plugin, reviews the (probably minified) JavaScript source, then uploads the `.jpl` file to the private repository. **Pros**: - This method should require very little code change on iOS. - We could support this by using a different plugin repository URL (this could be changed [here](https://github.com/laurent22/joplin/blob/56b010ba0ea22b03619f387ecfd428837095f761/packages/app-mobile/components/screens/ConfigScreen/plugins/utils/useRepoApi.ts#L19)). - We could more easily have the @joplinbot build plugins from a specific commit and auto-upload to the repository. **Cons**: - The plugin repository would be split across two GitHub repositories or branches. This may make it more difficult to work with (e.g. when reviewing plugins). - If we want to show certain plugins/versions as `reviewed` on other clients, the client will need to check both repositories. - All plugins in the `reviewed` repository will be older versions of plugins in the main plugin repository. As such, reviewed plugins will need to update from the reviewed repository and not the main repository. To support this on non-iOS clients, we'll need to store additional data (e.g. add a `_reviewed` manifest key). ### 2. Create a new `reviewed` subdirectory in the [`@joplin/plugins`](https://github.com/joplin/plugins/tree/master) repository The review process for this option would be very similar to the process outlined above for option 1. **Pros**: - We still only need one plugin repository/branch. - Creating a separate folder for reviewed plugins makes them easier to find and update. **Cons**: - May be more complicated to implement than option `1`. ### 3. Add a new private manifest property that indicates the last reviewed commit A new private manifest key ([similar to `_recommended`](https://github.com/laurent22/joplin/blob/0715340dc0437efe785b227c2ea61820728b0485/packages/plugin-repo-cli/lib/validateUntrustedManifest.ts#L17)), `_lastReviewedCommit` could be assigned to plugins using [`manifestOverrides.json`](https://github.com/joplin/plugins/blob/master/manifestOverrides.json). On iOS, plugins would then be downloaded using the JPL from that commit. The download URL might then, for example, be `https://github.com/joplin/plugins/raw/e45d1b6361e986a88ff2bb63a51134588b5991f6/plugins/io.github.personalizedrefrigerator.joplin-vimrc/plugin.jpl`. The plugin review process would then be similar to the following: 1. A maintainer downloads a plugin's `.jpl` file from a specific commit, then extracts it and reviews the (probably minified) JavaScript). - Note: `.jpl` files can also be inspected using the [Plugin Website](https://joplinapp.org/plugins/view-source.html?plugin=io.github.personalizedrefrigerator.joplin-vimrc#index.js) by drag-and-dropping a `.jpl` file into the source viewer, which can format minified files with `prettier`. - We could also encourage plugin authors to [disable minification](https://webpack.js.org/configuration/optimization/#optimizationminimize) to make the review process easier. 2. After reviewing, a `_lastReviewedCommit` field can be added to [`manifestOverrides.json`](https://github.com/joplin/plugins/blob/master/manifestOverrides.json) to indicate which commit was last reviewed. **Pros**: - No need to maintain multiple plugin repositories. - No need to change the overall structure of the main plugin repository. **Cons**: - We can't build plugins' `.jpl` files ourselves when reviewing. - This could be fine, particularly if we encourage plugin developers to create [NPM packages that are verifiably linked to a CI build](https://github.blog/2023-04-19-introducing-npm-package-provenance/) for their plugins. - Likely requires more code changes than option 1. - May be unable to use mirrors to download plugins from a specific commit.

Topic		Replies	Views
Abc plugin for android? Features	8	911	15 January 2022
Plan for plugins in mobile? Features	3	3649	2 December 2021
Plugin for music sheets Lounge	17	632	24 November 2023
Pre-release 1.3 with plugin support is now available! (Updated 31/10/20) Beta Testing	58	6547	9 November 2020
Are plug-ins creating too much gap between desktop and mobile? Features	5	1294	31 October 2021

Mobile: Plugin support

Related topics