iOS
13.6.10
I recently reinstalled Joplin on my 11th gen iPad and noticed that there a number of plug-ins (that I use on my Android TCL NXTPaper 11+) don't appear in the search results at all.
Searching for them on my Mac, Windows, and Android devices do appear.
Is this working as designed or is there an issue?
The plug-ins that I searched for on the iPad that didn't appear (but do appear on Android):
Regardless of whether or not they're compatible I would expect them to appear in the search results.
Due to apple's app store rules, joplin only allows plugins tagged as "recommended" to be installed on the iOS version:
# Recommended Plugins
Those are the plugins recommended by the Joplin team because they meet our standards for security and performance.
Currently there is no review process so the selected plugins are those developed by either the Joplin team or by frequent contributors.
In the future, there may be a review process so that other plugins can be submitted and potentially have the Recommended tag too.
opened 04:29PM - 18 Mar 24 UTC
closed 12:40PM - 29 Mar 24 UTC
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.
Thank you for the information, that is helpful.... (and also a bummer).