Publishing Your App

MacOS

Distributing an Electron application on MacOS requires two critical security steps: code signing and notarization. Both are requirements from Apple to ensure users can safely download and run your application without security warnings. For both of these steps, we recommend using Electron Forge.

❗️

For a bundled app to properly handle permissions, it must be code signed and notarized. A bundled app that is not code signed and notarized will fail to be granted any permissions, even if they are shown to be granted in MacOS system settings.

Code signing

Code signing is the process of digitally signing your application with a certificate from Apple. This signature proves your application comes from a verified developer, and allows MacOS to trust your application and run it without blocking. Without code signing, MacOS Gatekeeper will prevent users from running your app, showing warnings like "This app is from an unidentified developer."

Requirements:

• An Apple Developer account ($99/year)
• A valid Developer ID Application certificate
• Access to your signing credentials (certificate and private key)

To get started with code signing, we recommend following the code signing guide from Electron Forge.

DSDK-Specific Configuration

Electron Forge's standard osx-sign tool has issues with the Desktop Recording SDK's structure, which can cause it to take a long time to sign applications using the Desktop Recording SDK. To resolve this, Recall provides a modified version of the osx-sign package to properly sign all bundled components. Use Recall's fork of osx-sign by adding the following to your package.json:

  "overrides": {
    "@electron/packager": {
      "@electron/osx-sign": "github:recallai/osx-sign"
    }
  },

If you don't want to worry about configuring this, you can also try our sample project which already has this configured!

Notarization

Notarization is Apple's automated security scan of your already-signed application. When you submit your app to Apple for notarization, Apple scans it for malicious content and code-signing issues. If approved, Apple adds a notarization ticket to your app.

Without notarization, MacOS (Catalina and later) will show security warnings even if your app is code-signed. Users will see "Apple cannot check it for malicious software" warnings.

❗️

Notarization can take multiple hours

Notarization is typically a fast process, but it can take multiple hours to notarize your application when running it for the first time. After the initial notarization, subsequent attempts should be much faster.

Setting up notarization

Unlike with code-signing, there are no specific changes you'll need to make for applications running the Desktop Recording SDK. We recommend the comprehensive notarization guide from Electron Forge, which shows the the different methods you can use to notarize your application.

Complete Build Process

Once you've configured code signing and notarization as explained above, you're almost ready to distribute your app. The next step is to run electron-forge make. When you run electron-forge make, Electron Forge will automatically:

1. Package your application
2. Code sign all components using the Recall.ai fork of osx-sign
3. Submit to Apple for notarization
4. Wait for Apple's approval (usually 2-10 minutes, can be multiple hours on the first try)
5. Staple the notarization ticket to your app

The final .dmg or .zip file will be fully signed and notarized, ready for distribution.

Windows

Windows applications also require code-signing, but do not require the same notarization process that Apple mandates. You'll need to get access to a code signing certificate, and there are many different companies that you can purchase these certificates from. You can find a comprehensive list of these companies here: https://www.electronjs.org/docs/latest/tutorial/code-signing#signing-windows-builds

You can follow the guidance in the docs above to understand how to code sign your app. As far as general guidance, make sure that when code signing, you do not include any file that isn't a .exe/.dll file.

Best Practices

Some customers may have a corporate firewall in place that blocks some of the endpoints needed by the Desktop Recording SDK. At a minimum, they will need to whitelist any <region>.recall.ai endpoints.

In order for Recall to receive debug information, customers with more restrictive security policies will also have to whitelist the following endpoints:

browser-intake-datadoghq.com
*.datadoghq.com
sentry.io
*.sentry.io

This will allow the Recall team to debug any issues that may come up for these customers.