iOS: Enable plugin support

[personalizedrefrigerator]

Operating system

iOS

Joplin version

3

Desktop version info

No response

Current behaviour

Currently, plugin support is disabled in the iOS app because of this section of the iOS AppStore guidelines (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 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).
• 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 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), _lastReviewedCommit could be assigned to plugins using 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 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 to make the review process easier.
2. After reviewing, a _lastReviewedCommit field can be added to 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 for their plugins.
• Likely requires more code changes than option 1.
• May be unable to use mirrors to download plugins from a specific commit.