The following is a set of guidelines for contributing to
These are just guidelines, not rules. Use your best judgment and feel free to
propose changes to this document in a pull request.
- Adding your app
- Removing or Disabling Apps
Adding your app
If you have an Electron application you'd like to see added, please open a pull request! All that's required is a basic YML file and a PNG icon.
Using the wizard
This repository has a CLI wizard much like
npm init that you can use to generate
a YML datafile for your app. To use the wizard,
fork and clone this repository,
git clone https://github.com/electron/electron-apps cd electron-apps npm install && npm run wizard
Adding your app by hand
Another easy way to add a new app is to copy an existing app and edit its metadata.
To do so, create a new directory in the
apps directory and include a
.png icon file. The directory can only contain numbers,
lowercase letters, and dashes, and the yml and icon files should be named
apps └── my-cool-app ├── my-cool-app-icon.png └── my-cool-app.yml
YML File Rules
websiteis required, and must be a fully-qualified URL.
repositoryis optional, but must be a fully-qualified URL if provided.
keywordsis optional, but should be an array if provided.
homebrewCaskNamecan be specified if your app is on homebrew cask.
snapcraftNamecan be specified if your app is on snapcraft.
npmPackageNamecan be specified if your app is on npm.
youtube_video_urlis optional, but must be a fully-qualified URL if provided.
- No fields should be left blank.
category is required and must be one of the following values:
- Developer Tools
- Food & Drink
- Health & Fitness
- Graphics & Design
- Magazines & Newspapers
- Photo & Video
- Social Networking
Screenshots are optional, but must be https and should be an array in the following format if provided:
screenshots: - imageUrl: 'https://mysite.com/awesome1.png' caption: 'Awesome screenshot 1' imageLink: 'https://mysite.com/awesome.html' - imageUrl: 'https://mysite.com/awesome2.png' caption: 'Awesome screenshot 2' imageLink: 'https://mysite.com/awesome.html'
imageUrl- required - fully-qualified URL of screenshot image. Allowed image types are png, jpg, and gif.
caption- an optional caption to display with the screenshot.
imageLink- an optional link URL to indicate the link that should be directed to when someone clicks on an image. If this field is not specified, clicking on a screenshot will go to the application website.
goodColorOnWhiteis an optional hex string, e.g.
goodColorOnBlackis an optional hex string.
faintColorOnWhiteis an optional rgba string, e.g.
rgba(100, 0, 0, 0.1)
If unspecified, an accessible colors will be picked or derived from the provided icon file.
- Must be a
- Must be a square
- Must be at least 256px by 256px
- Must not be a copy of another company's or application's icon (see submission guidelines below)
By default, your app is assumed to be designed for English speakers. If your
app supports a different language (or multiple languages), please add a
locales property that lists all locales supported.
name: fangyuanjian description: 'collaboration and messaging for small-to-medium sized businesses.' website: 'http://bzsns.cn/' keywords: - messaging - collaboration locales: - zh-CN
Company Logos and Names
Our legal team has advised us to disallow apps that are using the names of other companies or icons that we find too similar to the logos of other companies without verifying their permission to do so.
App names should not start with the word "GitHub". In general, you may refer to GitHub in a relational phrase to say that the project is "compatible with", "on", or "for" GitHub, or something along those lines.
For more details, see the GitHub logo guidelines.
Some things to keep in mind when preparing your app for submission. Heavily inspired by the awesome-electron submission guidelines.
- The pull request should have a useful title and include a link to the thing you're submitting and why it should be included.
- Don't use another company's trademarks (icon, logo or name) without supplying evidence of prior permission
- If you just created something, wait at least 20 days before submitting.
- If you're submitting a closed source app, include evidence of it being built with Electron.
- Submitted open source apps should have a readme, screenshot of the app in the readme, and a binary for at least one OS, preferably macOS, Linux and Windows.
- Keep descriptions short and simple, but descriptive.
- Start the description with a capital and end with a full stop/period.
- Don't mention
Electronin the description as it's implied.
- Don't start the description with
- Check your spelling and grammar.
Once your pull request has been merged, your changes will automatically be published in a new release of the
electron-apps npm module, and will be displayed on the electronjs.org website shortly thereafter. This process
involves a number of scheduled process, and typically takes 20-30 minutes.
Removing or Disabling Apps
Sometimes it's necessary to remove an app for this registry. To do so,
disabled property to the app's YML file, followed a comment
explaining the reason for removing it.
disabled: true # Nylas was sunset and replaced by Mailspring
This approach keeps the app data on hand, giving the app developer an option to resurrect the app at a later date by simply removing the flag.
How it Works
This package is a joint effort between humans and robots.
First, a human adds an app:
apps └── hyper ├── hyper-icon.png └── hyper.yml
The yml file requires just a few fields:
name: Hyper description: 'HTML/JS/CSS Terminal' website: 'https://hyper.is' repository: 'https://github.com/zeit/hyper' category: 'Developer Tools'
Humans can include other data like
license, but they're not required to do so.
The human then opens a PR. Tests pass, the PR gets merged. Yay!
Later, a bot comes along and adds more data about the app.
First, the date the app was submitted is inferred from the git history. Humans could provide this metadata, but they shouldn't have to. Let the machines do the work.
Then, the bot creates resized versions of the app icon:
hyper ├── hyper-icon-128.png ├── hyper-icon-32.png ├── hyper-icon-64.png ├── hyper-icon.png └── hyper.yml
Then the bot extracts a color palette from the app icon:
iconColors: ['#FF0000', '#C54F23', '#DD8833']
And it also picks some colors that are "on brand" for use on black or white backgrounds:
goodColorOnWhite: '#916E02' goodColorOnBlack: '#FCCC36' faintColorOnWhite: 'rgba(80, 0, 0, 0.1)
Lastly, the bot commits changes to git, pushes to GitHub, and publishes a new release to npm.
To develop this thing locally, there are a few things you should know:
You'll need a GitHub token to run the build task. Put it in a file named
.env. It will be ignored by git.
cp .env.example .env
On Travis CI, the
npm test command is run, which only tests human-submitted
When cutting a new release (which is normally done automatically by a Heroku
scheduler process), the
npm run test-all command is run, which tests not
only the human-submitted data, but also the artifacts generated by the
build process, like resized icons, icon color palettes, releases data, etc.