Code-signing allows Windows to verify the identity of an application'spublisher, making it authentic and trustworthy. Additionally, code-signing helpsapplications comply with Windows security policies, avoiding warnings andinstallation blocks, ultimately building user confidence and providing asmoother, safer experience.

What is code-signing?

At its core, code-signing involves using a cryptographic hash function to createa unique digital fingerprint of the code. This fingerprint and a certificatefrom a trusted Certificate Authority (CA) form the digital signature. When usersdownload and run the software, their operating system or browser checks thedigital signature to verify its authenticity.

There are two types of certificates we can use to sign a Windows application:

• Code-signing Certificate
• EV Code-signing Certificate

A Standard Code-signing Certificate provides our application a baselinelevel of security and trust. While it verifies the software publisher's identityand ensures that the code has not been tampered with since it was signed, thevalidation process is less rigorous than EV certificates. It shows a warningduring installation that goes away once enough users have installed ourapplication and we've built up trust.

Extended Validation (EV) Code-signing Certificates, on the other hand, offerthe highest level of security and trust. These certificates require a morerigorous vetting process by the Certificate Authority (CA) before they areissued, ensuring that the entity requesting the certificate is thoroughlyverified. This process involves verifying the legal, physical, and operationalexistence of the entity, as well as confirming the identity of the individualrequesting the certificate.

Unlike Apple, Microsoft allows developers to purchase these certificates on theopen market. They are typically sold by the same companies that offer HTTPScertificates. Prices can vary, so it's worth shopping around. Some popularresellers include:

• DigiCert code-signing certificate
• Certum EV code-signing certificate
• Entrust code-signing certificate
• SSL.com EV code-signing certificate

Why choose EV code-signing?

Even though EV code-signing certificates are comparatively pricier than standardcode-signing certificates and have a rigorous vetting process. It is importantto note that, effective June 2023, thenew CA/Browser Forum code-signing requirementsis in effect. As a result, publicly trusted Certificate Authorities (CA) willrequire that certificate requestors use an appropriately certified (FIPS 140-2level 2 or Common Criteria EAL 4+) hardware security module (HSM) to protecttheir code-signing private keys. This requirement applies to the issuance ofboth extended validation (EV) certificates and non-EV certificates.

In simple words, what this means is that standard code-signing certificates nolonger provides benefits they provided in the past. Windows will treat ourapplication as completely unsigned and display the equivalent warning dialogs.Another thing to note here is that since certificates are required to be storedon an HSM, the certificate cannot be simply downloaded onto a CI infrastructure.

Cloud-based EV code-signing

In the past, EV code-signing could only be performed using a physical USBdongle. Upon purchasing an EV certificate, the provider would send a physicalUSB device containing the certificate. This method required code-signing to beexecuted from a local machine, which posed flexibility challenges, especiallyfor team environments. Additionally, physical USB dongles are prone to loss ordamage.

As a solution to this, many certificate providers now offer "cloud-based EVsigning," where the signing hardware is housed in their data centers, allowingus to remotely sign code.

In this blog, we will look into how we can remotely EV code-sign a Windowsapplication built using Electron, using SSL.com'seSigner CodeSignTool

Purchase and validate EV certificate from SSL.com

For the NeetoRecord desktop application, we used EV certificate from ssl.com andhence we will use ssl.com as an example in this blog.

Once we sign into SSL.com and purchase theEV code-signing certificate,We need to validate the certificate. For this, we need to fill out the EVsubscriber agreement and EV authorization form. Both of them can bedownloaded fromhere.Also, make sure we have D-U-N-Snumber or equivalent ready before starting the validation process. To know aboutall the requirements in detail, followthis articleor watch this Youtube video.

eSigner and CodeSignTool

eSigner is SSL.com's cloud signing service thatallows remote access to its HSM hardware from anywhere. We can use our SSL.comsigning credentials to access it.

CodeSignTool isa command-line tool for remotely signing various types of scripts like MSIinstallers, Microsoft Authenticode etc., with eSigner EV code-signingcertificates. Hashes of the files are sent to SSL.com for signing so that thecode itself is not sent. This is ideal where sensitive files need to be signedbut should not be sent over the wire for signing. CodeSignTool is also ideal forautomated batch processes for high-volume signings or integration into existingCI/CD pipeline workflows.

Enroll in eSigner

To be able to code-sign the application using eSigner, we need to first enrollin eSigner. To do so,

• Navigate to an issued Code-signing order in our SSL.com account. Note that theorder is labeled eSigner Ready.
• Click one of the download links.
• Create and confirm a 4-digit PIN and click the create PIN button.
• Our certificate will be generated, and after a few moments, a QR code willappear above the certificate downloads table.

When the eSigner QR code is displayed for our certificate, copy and save thesecret code value shown in a safe location. This is the TOTP (time-basedone-time password) secret associated with our eSigner certificate. Just as 2FAauthentication software like Authy can scan this value from the QR code togenerate valid OTPs for code-signing, CodeSignTool can also use it to generateOTPs are automatically generated during the signing process. In the nextsection, we will use this secret code as totp_secret while integrating withCodeSignTool.

For more information, check out these articles:How to Enroll in eSignerandAutomate eSigner EV Code-signing.

Obtain Required Credentials

We need to provide the following credentials to the CodeSignTool for it tosuccessfully connect with eSigner and code-sign the application.

If we haven't purchased a certificate yet and want to try out how it works,SSL.com offerseSigner Demo Credentials and Certificates.

• username
• password
• totp_secret
• credential_id

For username and password, use the same credentials we used to sign in toSSL.com. If needed, we can also add additional users to the same account. Forthe totp_secret, use the secret code we saved during the eSigner enrollmentprocess.

To obtain the credential_id, navigate to the certificate details section onthe SSL.com dashboard. The credential_id will be listed underSIGNING CREDENTIALS.

After acquiring all the credentials, add them to GitHub Secrets with thefollowing names:

• username -> WINDOWS_SIGN_USER_NAME
• password -> WINDOWS_SIGN_USER_PASSWORD
• totp_secret -> WINDOWS_SIGN_USER_TOTP
• credential_id -> WINDOWS_SIGN_CREDENTIAL_ID

Load up these secrets as environment variables in our Github Action workflow.

- name: Publish releases    env:      AWS_ACCESS_KEY_ID: ${{secrets.AWS_ACCESS_KEY}}      AWS_SECRET_ACCESS_KEY: ${{secrets.AWS_SECRET}}      WINDOWS_SIGN_USER_NAME: ${{ secrets.WINDOWS_SIGN_USER_NAME }}      WINDOWS_SIGN_USER_PASSWORD: ${{ secrets.WINDOWS_SIGN_USER_PASSWORD }}      WINDOWS_SIGN_USER_TOTP: ${{ secrets.WINDOWS_SIGN_USER_TOTP }}      WINDOWS_SIGN_CREDENTIAL_ID: ${{ secrets.WINDOWS_SIGN_CREDENTIAL_ID }}    run: npm exec electron-builder -- --publish always -mwl

Integrate CodeSignTool

The Windows version of CodeSignTool is provided as a batch file(CodeSignTool.bat), while the Linux/macOS version is available as a shellscript (CodeSignTool.sh). We can find the download links and more detailsabout CodeSignTool inthis article

For our purposes, we'll be using the shell script. Download the Linux/macOSversion, unzip it, and place it in the root directory of our Electron project.

To integrate the CodeSignTool into the Electron build process, create a script(./scripts/windows-sign.mjs) that runs the CodeSignTool shell script.

import path from "path";import fs from "fs";import childProcess from "child_process";const TEMP_DIR = path.join(__dirname, "../release", "temp");if (!fs.existsSync(TEMP_DIR)) {  fs.mkdirSync(TEMP_DIR);}const sign = file => {  const USER_NAME = process.env.WINDOWS_SIGN_USER_NAME;  const USER_PASSWORD = process.env.WINDOWS_SIGN_USER_PASSWORD;  const CREDENTIAL_ID = process.env.WINDOWS_SIGN_CREDENTIAL_ID;  const USER_TOTP = process.env.WINDOWS_SIGN_USER_TOTP;  if (USER_NAME && USER_PASSWORD && USER_TOTP && CREDENTIAL_ID) {    console.log(`Windows code-signing ${file.path}`);    const { name, dir } = path.parse(file.path);    const tempFile = path.join(TEMP_DIR, name);    const setDir = `cd ./CodeSignTool-v1.3.0`;    const signFile = `./CodeSignTool.sh sign -input_file_path="${file.path}" -output_dir_path="${TEMP_DIR}" -credential_id=${CREDENTIAL_ID}   -username="${USER_NAME}" -password="${USER_PASSWORD}" -totp_secret="${USER_TOTP}"`;    const moveFile = `mv "${tempFile}.exe" "${dir}"`;    childProcess.execSync(`${setDir} && ${signFile} && ${moveFile}`, {      stdio: "inherit",    });  } else {    console.warn(`windows-sign.js - Can't sign file, credentials are missing`);    process.exit(1);  }};export default sign;

The script exports a sign function that accepts an object containing the pathto the file that needs to be signed. It reads all the necessary credentials fromenvironment variables and then passes these credentials along with the filepath.

To finish up, pass this script to the electron-builder configuration.

 "build": {    "productName": "MyProduct",     "win": {      "target": {        "target": "nsis",        "arch": [          "x64"        ]      },      "signingHashAlgorithms": [        "sha256"      ],      "sign": "./scripts/windows-sign.mjs",      "publisherName": "Neeto LLC",      "artifactName": "${productName}-Setup-${version}.${ext}"    }, }

Here, we pass the script path to the win.sign field in the electron-builderconfiguration. Once added, electron-builder will call this script for eachfile that needs to be signed.

Great! With this, we've completed the EV code-signing process for our Windowsapplication. Now, when we run the GitHub Action workflow, it will successfullycode-sign our Windows application.

SSL.com pricing

As mentioned earlier, EV code signing certificates are expensive. SSL.comcharges $349 per year for an EV code signing certificate, with discountsavailable for multi-year purchases. For more information, visit:https://www.ssl.com/certificates/ev-code-signing/buy/.

In addition to the certificate cost, we must also subscribe to the eSigner cloudsigning service, which is a subscription-based service. The Tier 1 plan costs$100 per month and allows a maximum of 10 files to be signed, equating to aminimum of $10 per signing. An Electron application requires four files to besigned per build. This means we can only build an Electron application twice permonth under the Tier 1 plan.

If we need to build the application more than twice per month, we recommendupgrading to Tier 2. This plan costs $300 per month and allows up to 100 filesignings, reducing the cost to $3 per signing. For more information, visit:https://www.ssl.com/guide/esigner-pricing-for-code-signing/

Native modules allow developers to access low-level APIs like hardwareinteraction, native GUI components, or other system-specific features. BecauseElectron applications run across different platforms (Windows, macOS, Linux),native modules must be compiled for each target platform. This can introducechallenges in cross-platform development.

To simplify this process, Electron provides tools likeelectron-rebuild to automate therecompilation of native modules against Electron's custom Node.js environment,ensuring compatibility and stability in the Electron application.

How to use electron-rebuild

electron-rebuild can automatically determine the version of Electron andhandle the manual steps of downloading headers and rebuilding native modules forour app.

To do a manual rebuild, run the below command.

./node_modules/.bin/electron-rebuild// If we are on windows.\node_modules\.bin\electron-rebuild.cmd

This process should be run after each native package is installed. We can addthis command to the postinstall script to automate it.

"scripts": {    "postinstall": "./node_modules/.bin/electron-rebuild"    //...others}

Since Electron uses Chromium browser windows as the user interface, we need toexclude any native modules from being bundled in the renderer process, whichruns inside the browser window. To achieve this, we need to separate frontendmodules from native modules and install them in separate node_modules folders.

Two package.json structure

To tackle this problem, Electron developers started using two package.jsonstructure, where the first one, which sits at the root of the project, includesthe dependencies that are needed for the user interface and all thedevDependencies that are needed to develop, build, and package theapplication.

// root package.json{  "name": "my-app",  "version": "1.0.0",  "description": "A sample application",  "license": "Apache-2.0",  "main": "./src/main/main.mjs",  "dependencies": {    "react": "^18.2.0",    "react-router-dom": "5.3.3"  },  "devDependencies": {    "electron": "^31.2.1",    "electron-builder": "^25.0.1"  }}

And a second package.json file, located at ./app/package.json, includes allthe native dependencies that should only run in a Node.js environment. Theelectron-rebuild postinstall script we discussed should be added to the./app/package.json.

// ./app/package.json{  "name": "my-app",  "version": "1.0.0",  "description": "A sample application",  "license": "Apache-2.0",  "main": "./dist/main/main.js",  "scripts": {    "postinstall": "./node_modules/.bin/electron-rebuild"  },  "dependencies": {    "sqlite3": "^5.1.7",    "sharp": "^0.33.5"  }}

We can add a postinstall script in the root to automatically install thedependencies listed in ./app/package.json when installing the rootpackage.json.

// root package.json{  "name": "my-app",  "version": "1.0.0",  "description": "A sample application",  "license": "Apache-2.0",  "main": "./src/main/main.mjs",  "dependencies": {    "react": "^18.2.0",    "react-router-dom": "5.3.3",  }  "devDependencies": {    "electron": "^31.2.1",    "electron-builder": "^25.0.1",  },  "scripts": {    "postinstall": "yarn --cwd ./app install"  }}

Now, if we run the yarn install from the root, after installing rootdependencies, it will install native dependencies in the app/ folder and thenrebuild the native packages. All in one command.

When building, we should output the frontend bundles to the app/dist folder.This way, when packaging, both our native packages and other dependencies willbe contained within the app folder. Readthis blog tolearn more about how to build and publish an Electron application.

electron-app assets app    node_modules    dist    package.json src node_modules package.json

This approach works well while packaging the app, but during development, howcan we access the native modules? To solve this, we need to create a symlinkfrom app/node_modules to src/main/node_modules. We can create a script tohandle this.

// ./scripts/link-modules.mjsimport fs from "fs";fs.symlinkSync("./app/node_modules", "./src/main/node_modules", "junction");

We can run this script in postinstall as well:

// ./app/package.json{  "name": "my-app",  "version": "1.0.0",  "description": "A sample application",  "license": "Apache-2.0",  "main": "./dist/main/main.js",  "scripts": {    "link-modules": "node ../scripts/link-modules.mjs",    "postinstall": "./node_modules/.bin/electron-rebuild && yarn link-modules"  },  "dependencies": {    "sqlite3": "^5.1.7",    "sharp": "^0.33.5"  }}

Problem with two package.json structure

In most JavaScript projects, metadata such as version, name, anddescription is typically stored in the root package.json. However, in thiscase, when packaging the app, we'll be including ./app/package.json instead ofthe root package.json. This means all metadata should be in./app/package.json rather than in the root file.

This approach poses a challenge, particularly with tasks like automatic versionbumping. When updating the version or other metadata, changes need to be made intwo places, which can lead to inconsistencies.

To simplify this process and avoid maintaining two separate package.jsonfiles, we can dynamically create ./app/package.json, allowing us to manageeverything in one place. Since we cannot add native dependencies directly to theroot dependencies, we can introduce a new field called nativeDependencies.When dynamically generating ./app/package.json, we can copy thenativeDependencies into the dependencies field of ./app/package.json.

This can be accomplished by creating a script to automate the process:

// ./script/create-native-package-json.jsimport fse from "fs-extra";const packageJson = JSON.parse(fse.readFileSync("./package.json", "utf8"));const APP_DIR = "./app/";const releaseJson = {  name: packageJson.name,  version: packageJson.version,  description: packageJson.description,  license: packageJson.license,  author: packageJson.author,  main: "./dist/main/main.js",  scripts: {    postinstall: "/node_modules/.bin/electron-rebuild && yarn link-modules",    "link-modules": "node ../scripts/link-modules.mjs",  },  dependencies: packageJson.nativeDependencies,};fse.mkdirSync(APP_DIR, { recursive: true });fse.writeFileSync(  APP_DIR + "package.json",  JSON.stringify(releaseJson, null, 2));

In the script, we first fetch the root package.json, create a JSON file, andcopy all the metadata. We then update the main field to point to the compiledversion of main.js, copy nativeDependencies into the dependencies, and addthe postinstall script for electron-rebuild and node_modules linking wediscussed earlier.

We can run this script in the root postinstall, so that if we make any changesto package.json, it will be updated in ./app/package.json duringyarn install.

// root package.json"scripts": {    "nativeInstall": "yarn --cwd ./app install",    "postinstall": "node ./script/create-native-package-json.js && yarn nativeInstall",    //...others}

When developing a desktop application, including every feature directly withinthe app is often unnecessary. Instead, we can offload some tasks such aslogin/signup to a web application. And from the web app, create deep-links tothe desktop app. We can also create shareable links that opens specific contenton the app.

In this blog, we are going to discuss how to create deep-links in ourElectron application.

Register a custom protocol

A protocol is a custom URL scheme that an application can handle, similar to howbrowsers handle protocols like http, https, mailto, or ftp. Everyoperating system supports the handling of custom protocols. We can register anapplication as a default handler for a custom protocol with the operatingsystem. Electron provides a simple API to register a default protocol client.

if (process.defaultApp) {  if (process.argv.length >= 2) {    app.setAsDefaultProtocolClient("my-app", process.execPath, [      path.resolve(process.argv[1]),    ]);  }} else {  app.setAsDefaultProtocolClient("my-app");}

The code snippet above is a simple example of registering a default protocolclient. In the example, we registered a custom protocol named my-app with theoperating system. It's important to note that the application must be properlypackaged and installed so that the operating system can correctly handle andlaunch the registered app.

We used process.defaultApp instead of app.isPackaged because Electron allowsus to run a packaged app using the electron . command. In such cases, we needto provide the execution path for the system to recognize the app. However, ifthe app is running in normal mode, simply callingapp.setAsDefaultProtocolClient is sufficient.

Handling custom protocol

Though registering the protocol is simple and the same for every platform, thereare some differences when it comes to handling it.

For macOS, we need to listen to the open-url event.

const handleCustomUrl = url => {  // Handle url};app.on("open-url", (event, url) => {  handleCustomUrl(url);});

On both Windows and Linux, if the application is up and running, asecond-instance event is emitted instead of open-url when a protocol requestis received. This means a new instance of our app will be created. If we want toavoid this behavior and notify the existing instance instead, we'll need toensure the app runs as a single instance. We can achieve this by usingrequestSingleInstanceLock.

const gotTheLock = app.requestSingleInstanceLock();if (!gotTheLock) {  app.quit();}

The above code ensures that our Windows or Linux app runs as a single instance.If a user attempts to open a new instance, that instance will try to acquire thesingle instance lock. If it fails, the newly created instance will simply quit.

const gotTheLock = app.requestSingleInstanceLock();if (!gotTheLock) {  app.quit();} else {  app.on("second-instance", (event, commands, workingDir) => {    handleCustomUrl(commands.pop());  });}

If we successfully acquire the single instance lock, it means we're running thefirst instance of the app. When a user attempts to open another instance,Electron emits a second-instance event to the existing instance. The secondargument of this event contains an array of command-line arguments, and we canretrieve the custom URL from the last item in this array.

We've addressed the case where the app is already running, but what happens ifthe app is completely closed and a protocol request is made? On macOS,there's nothing extra to do; the app will launch, and the open-url event willbe triggered automatically.

However, for Windows and Linux, the behavior is different. Thesecond-instance event won't be triggered since the app is starting for thefirst time. Instead, we can retrieve the custom URL from process.argv, as theapp will start with the protocol URL passed as one of its parameters. To handlethis case, we need to check process.argv when the app is started.

const handleCustomUrl = url => {  // Handle url};app.whenReady().then(() => {  const customUrl = process.argv.find(item => item.startsWith("my-app://"));  if (customUrl) {    handleCustomUrl(customUrl);  }});

Here, when the app is ready, we look for an item in process.argv that startswith our URL scheme (my-app://), if yes we can confirm that this instance isstarted when a protocol request is received.

Great! Here's the complete solution that works across all platforms, whether theapp is already running or not.

if (process.defaultApp) {  if (process.argv.length >= 2) {    app.setAsDefaultProtocolClient("my-app", process.execPath, [      path.resolve(process.argv[1]),    ]);  }} else {  app.setAsDefaultProtocolClient("my-app");}const handleCustomUrl = url => {  // Handle url};app.on("open-url", (event, url) => {  handleCustomUrl(url);});const gotTheLock = app.requestSingleInstanceLock();if (!gotTheLock) {  app.quit();} else {  app.on("second-instance", (event, commands, workingDir) => {    handleCustomUrl(commands.pop());  });}app.whenReady().then(() => {  const customUrl = process.argv.find(item => item.startsWith("my-app://"));  if (customUrl) {    handleCustomUrl(customUrl);  }});

Packaging

On macOS and Linux, this feature is only functional when our app is packaged; itwon't work during development when launching from the command line. To ensureproper functionality, we must update the macOS Info.plist file and the Linux.desktop file to include the new protocol handler when packaging our app. Thisallows the operating system to recognize and handle the custom URLs correctly.

electron-builder handles this internally when packaging the app; We just needto configure the electron-builder accordingly. To learn more about how topackage our app using electron-builder, check outthis blog.

"build": {    "productName": "NeetoRecord",    "appId": "com.neeto.neetoRecord",    "protocols": {      "name": "my-app-protocol",      "schemes": [        "my-app"      ]    },    "win": {...},    "linux": {...},    "mac": {...}}

We can use the protocols field for that, give a name, then pass an array ofURL schemes the app supports, and the rest electron-builder will handle it.

macOS identifies applications that are not code-signed and notarized as beingfrom unknown publishers and blocks their installation. Code-signing allows macOSto recognize the application's creator. Notarization, an additional step,provides extra credibility and security, ensuring a safer experience for users.

What is code-signing?

Code-signing is the process of generating a unique digital fingerprint of thecode using a cryptographic hash function. This fingerprint is combined with acertificate from a trusted Certificate Authority (CA) to create the digitalsignature. When users download or execute the software, the operating systemverifies this signature to confirm its authenticity.

Apple prefers developers to use certificates issued through the Apple DeveloperProgram to sign macOS applications. This is because macOS verifies signaturesagainst Apple's own Certificate Authority. If a third-party certificate is used,macOS might not recognize it as trusted, leading to warnings or blocking theapplication from running due toGatekeeper,Apple's security feature.

Enroll in the Apple developer program

We should enroll in the Apple developer program (which costs $99 per year) tocreate a certificate that we can use to code-sign our application. We can followthis link to know what we needto enroll in the Apple developer program.

Apple certificates

Apple provides two main types of code-signing certificates:

• Developer ID Certificate: Used to sign apps distributed outside the MacApp Store. Apps signed with this can be gatekeeper-approved.
• Mac App Distribution Certificate: Required for submitting apps to the MacApp Store. Apple will re-sign the application after review and approval fordistribution on the Mac App Store.

In this blog, we will look into how to code-sign anElectron application using Developer IDCertificate.

Create a Developer ID certificate

To create a Developer ID certificate, we can follow Apple's detailed guide onhow to create a Developer ID certificate.

Once we've successfully created the certificate and downloaded the .cer file,the next step is to convert this file into a .p12 format.

First, we'll need to convert the .cer file into a .pem format. We can dothis using openssl.

openssl x509 -in certificate.cer -inform DER -out certificate.pem -outform PEM

Then, use the .pem file and our private .key to generate the .p12 file.

openssl pkcs12 -export -out certificate.p12 -inkey certificate-private.key -in certificate.pem

When generating the .p12 file, we'll be prompted to set a password. Save thispassword in a secure location, as we'll need it later when code-signing theapplication.

To use this certificate with our existing GitHub Action workflow to automate thedeployment process, we need to convert this .p12 file into a base64 string.This is necessary because GitHub doesn't allow uploading files as secrets, butwe can store the base64 string instead.

openssl base64 -in certificate.p12 -out certificate.txt

The command will output the base64 version of the .p12 file into acertificate.txt file. We can then add the text contents of this file as asecret in GitHub. Save the base64 string in GitHub secrets with the nameCSC_CONTENT and password as CSC_KEY_PASSWORD

Update Electron build process

To code-sign a macOS app, we just need to pass the certificate and password tothe electron-builder publish command. However,since we saved our certificate as a base64 string, we need to convert it back toa .p12 file before publishing.

 - name: Publish releases    env:      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}      AWS_ACCESS_KEY_ID: ${{secrets.AWS_ACCESS_KEY}}      AWS_SECRET_ACCESS_KEY: ${{secrets.AWS_SECRET}}      CSC_CONTENT: ${{ secrets.CSC_CONTENT }}      CSC_KEY_PASSWORD: ${{ secrets.CSC_KEY_PASSWORD }}    run: |      echo "$CSC_CONTENT" | base64 --decode > certificate.p12      export CSC_LINK="./certificate.p12"      npm exec electron-builder -- --publish always -mwl

As mentioned above, we first decoded the base64 string back to acertificate.p12 file. We then set the path to this file as CSC_LINK, whichelectron-builder expects.

Great! With everything in place, running this workflow should successfullycode-sign our application.

Notarize

Code-signing allows macOS to recognize the application's creator, but this aloneis insufficient. Users will still see a warning stating, "macOS cannot verifyif the app is free from malware."

To eliminate this warning, we need to notarize our application.Notarizationis a security feature introduced by Apple to ensure that macOS applications aresafe and free of malicious content. It's an additional layer of security thatbuilds on code-signing. The notarization process involves submitting our app toApple for automated security checks. Once notarized, macOS will recognize theapp as trustworthy, ensuring smooth installation and execution on users'systems, even when downloaded from outside the Mac App Store.

To notarize, we need to create an "App-specific password". To create anApp-specific password:

• Sign in to appleid.apple.com
• In the Sign-In and Security section, select App-Specific Passwords.
• Select Generate an app-specific password or select the Add button(+).
• Then give a name for the password and click Create.

A new App-Specific Password will be generated. Save it in a safe place. We willuse this password to notarize our macOS application.

Update Electron build process

Add APPLE_APP_SPECIFIC_PASSWORD, TEAM_ID, and APPLE_ID to GitHub secrets.Then load up these secrets as environment variables along with others in ourGithub Action workflow.

 - name: Publish releases    env:      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}      AWS_ACCESS_KEY_ID: ${{secrets.AWS_ACCESS_KEY}}      AWS_SECRET_ACCESS_KEY: ${{secrets.AWS_SECRET}}      CSC_CONTENT: ${{ secrets.CSC_CONTENT }}      CSC_KEY_PASSWORD: ${{ secrets.CSC_KEY_PASSWORD }}      TEAM_ID: ${{ secrets.TEAM_ID }}      APPLE_ID: ${{ secrets.APPLE_ID }}      APPLE_APP_SPECIFIC_PASSWORD: ${{ secrets.APPLE_APP_SPECIFIC_PASSWORD }}    run: |      echo "$CSC_CONTENT" | base64 --decode > certificate.p12      export CSC_LINK="./certificate.p12"      npm exec electron-builder -- --publish always -mwl

At the time of writing this, we encountered issues with the built-in notarizefeature of electron-builder, so we created a custom script to handle thenotarization process.

const { notarize } = require("@electron/notarize");const { build } = require("../package.json");const notarizeMacos = async context => {  const { electronPlatformName, appOutDir } = context;  if (electronPlatformName !== "darwin") return;  if (process.env.CI !== "true") {    console.warn("Skipping notarizing step. Packaging is not running in CI");    return;  }  const appName = context.packager.appInfo.productFilename;  await notarize({    tool: "notarytool",    appBundleId: build.appId,    appPath: `${appOutDir}/${appName}.app`,    teamId: process.env.TEAM_ID,    appleId: process.env.APPLE_ID,    appleIdPassword: process.env.APPLE_APP_SPECIFIC_PASSWORD,    verbose: true,  });  console.log("--- notarization completed ---");};exports.default = notarizeMacos;

The script uses the notarize function from the @electron/notarize package.It passes the path to the generated .app file during the build process, alongwith the required TEAM_ID, APPLE_ID, and APPLE_APP_SPECIFIC_PASSWORD,which were obtained earlier.

To run the custom notarization script, disable the built-in notarization featurein the electron-builder configuration. Then, call this script from theafterSign callback to ensure it runs after the signing process is complete.

"build": {    "mac": {      "notarize": false,      "target": {        "target": "default",        "arch": [          "arm64",          "x64"        ]      },    },    "afterSign": "./scripts/notarize.js",}

Great! We have successfully code-signed and notarized our macOS application.Now, macOS will trust our application, and an added benefit of this process isthat it allows us to auto-update our application seamlessly, ensuring that usersalways have the latest version.

When developing desktop applications with Electron, managing multiple browserwindows within a single app is often necessary. Whether we need to displaydifferent types of content or create a more complex user interface, handlingmultiple windows efficiently can be challenging.

In this blog, we'll explore how to configure Webpack to manage multiple browserwindows in our Electron application, ensuring that each window operates smoothlyin our project.

Configuring Webpack for a Single Browser Window

Before diving into the setup for multiple windows, let's first review how toconfigure Webpack for a single browser window. This example focuses on therenderer process, which is responsible for rendering the UI and handlinginteractions. If interested in learning how to configure Webpack for the entireElectron app, including the main process, check outthis blog.

Consider the following typical folder structure for an Electron project:

electron-app assets app src    main      main.js    renderer      App.jsx      index.ejs node_modules package.json

This structure separates the code for the main and renderer processes, whichis a standard practice in Electron projects.

Here's how we can configure Webpack for a single browser window:

// ./config/webpack/renderer.mjsimport webpack from "webpack";import HtmlWebpackPlugin from "html-webpack-plugin";const configuration = {  target: ["web", "electron-renderer"],  entry: "src/renderer/App.jsx",  output: {    path: "app/dist/renderer",    publicPath: "./",    filename: "renderer.js",    library: {      type: "umd",    },  },  module: {...},  // Module configuration (loaders, etc.)  optimization: {...},  // Optimization settings (minification, etc.)  plugins: [    // Other plugins...    new HtmlWebpackPlugin({      filename: "app.html",      template: "src/renderer/index.ejs",    }),  ],};export default configuration;

In this configuration:

• The target is set to ["web", "electron-renderer"], enabling both standardweb and Electron renderer environments.
• The entry specifies the entry point for the renderer process, which issrc/renderer/App.jsx.
• The output is bundled into a single file named renderer.js, which is storedin the app/dist/renderer directory. In an Electron app, it's oftenpreferable to bundle everything into a single file since the files are loadedlocally.
• The HtmlWebpackPlugin generates an app.html file from a template(index.ejs), embedding the necessary script to load renderer.js.

We can compile and bundle our frontend code using the following command:

webpack --config ./config/webpack/renderer.mjs

This will produce an app.html file in the app/dist/renderer directory, alongwith renderer.js.

<!DOCTYPE html><html>   <head>      <meta charset=utf-8>      <meta http-equiv=Content-Security-Policy content="script-src 'self' 'unsafe-inline'">      <title>MyApp</title>      <script defer=defer src=./renderer.js></script>   </head>   <body>      <div id=root></div>   </body></html>

The HtmlWebpackPlugin correctly injects the <script/> tag to loadrenderer.js. This app.html can now be loaded into a browser window from themain process.

const appWindow = new BrowserWindow({  show: false,  width: 1408,  height: 896,});appWindow.loadURL("app/dist/renderer/app.html");appWindow.on("ready-to-show", () => {  appWindow.show();});

Configuring Webpack for Multiple Browser Windows

With the single window setup complete, let's add another browser window to theapp. For example, let's say we want to create a Settings.jsx component withinthe renderer folder:

electron-app assets app src    main      main.js    renderer      App.jsx      Settings.jsx      index.ejs node_modules package.json

Previously, we bundled all JavaScript code into a single renderer.js file.However, since we're now working with multiple windows, it makes sense to createseparate bundles for each windowone for the App window and another for theSettings window. To achieve this, we can specify multiple entry points inWebpack:

// ./config/webpack/renderer.mjsimport webpack from "webpack";import HtmlWebpackPlugin from "html-webpack-plugin";const configuration = {  target: ["web", "electron-renderer"],  entry: {    app: "src/renderer/App.jsx",    settings: "src/renderer/Settings.jsx",  },  output: {    path: "app/dist/renderer",    publicPath: "./",    filename: "[name].js", // Use placeholders to generate separate bundles    library: {      type: "umd",    },  },  // Other configuration options...};export default configuration;

In this configuration:

• The entry property now contains two entry points: app and settings.Webpack will generate separate bundles for each, named app.js andsettings.js respectively.
• The filename in the output section uses the [name] placeholder todynamically generate filenames based on the entry point names.

Next, we need to generate two HTML filesone for each window. We can achievethis by adding another instance of HtmlWebpackPlugin to the plugins array:

// ./config/webpack/renderer.mjsimport webpack from "webpack";import HtmlWebpackPlugin from "html-webpack-plugin";const configuration = {  target: ["web", "electron-renderer"],  entry: {    app: "src/renderer/App.jsx",    settings:"src/renderer/Settings.jsx"  },  output: {    path: "app/dist/renderer",    publicPath: "./",    filename: '[name].js',    library: {      type: "umd",    },  },  module: {...},  optimization: {...},  plugins: [    // Other plugins...    new HtmlWebpackPlugin({      filename: "app.html",      template: "src/renderer/index.ejs",      chunks: ['app'],  // Load only the 'app' bundle    }),    new HtmlWebpackPlugin({      filename: "settings.html",      template: "src/renderer/index.ejs",      chunks: ['settings'],  // Load only the 'settings' bundle    }),  ],};export default configuration;

By specifying the chunks property for each HtmlWebpackPlugin instance, weensure that each HTML file only includes the appropriate JavaScript bundle. Thefinal output will include two HTML files:

<!-- app.html --><!DOCTYPE html><html>   <head>      <meta charset=utf-8>      <meta http-equiv=Content-Security-Policy content="script-src 'self' 'unsafe-inline'">      <title>MyApp</title>      <script defer=defer src=./app.js></script>   </head>   <body>      <div id=root></div>   </body></html><!-- settings.html --><!DOCTYPE html><html>   <head>      <meta charset=utf-8>      <meta http-equiv=Content-Security-Policy content="script-src 'self' 'unsafe-inline'">      <title>MyApp</title>      <script defer=defer src=./settings.js></script>   </head>   <body>      <div id=root></div>   </body></html>

Finally, from the main process, we can easily create two browser windows, eachwith its own renderer code:

const appWindow = new BrowserWindow({  show: false,  width: 1408,  height: 896,});appWindow.loadURL("app/dist/renderer/app.html");appWindow.on("ready-to-show", () => {  appWindow.show();});const settingsWindow = new BrowserWindow({  show: false,  width: 1408,  height: 896,});settingsWindow.loadURL("app/dist/renderer/settings.html");settingsWindow.on("ready-to-show", () => {  settingsWindow.show();});

With this setup, each browser window will load its own dedicated JavaScriptbundle, ensuring that our Electron application is both efficient and modular.This approach not only makes our code easier to manage but also enhances theperformance of our application by reducing unnecessary code loading.

Building, packaging and publishing an app with the default Electron npm packagescan be quite challenging. It involves multiple packages and offers limitedcustomization. Additionally, setting up auto-updates requires significantadditional effort, often involving separate tools or services.

electron-builder is a complete solution forbuilding, packaging, and distributing Electronapplications for macOS, Windows, and Linux. It is a highly configurablealternative to the default Electron packaging process that supports auto-updateout of the box.

In this blog, we look into how we can build, package and distribute Electronapplications using electron-builder.

Electron processes

Electron has two types of processes: the main process and the rendererprocess. The main process acts as the entry point to the application, where wecan create a browser window and load a webpage. This webpage runs in therenderer process. The main process is written in Node.js, while therenderer process can be developed using JavaScript or any JS framework likeReact, Vue, or Angular.

Project structure

When building an Electron application, it's best to keep the main andrenderer processes in separate folders since they are built separately.

electron-app assets release src    main      main.js    renderer      App.jsx      index.ejs node_modules package.json

Browser window preload script

Since the main process is written in Node.js, it has access to Node.js andElectron APIs, but the renderer process does not. To bridge this gap, Electronsupports a special script called a preload script, which we can specify whencreating a BrowserWindow. This script runs in a context that has access toboth the HTML DOM and a limited subset of Node.js and Electron APIs. An examplepreload script looks like this:

import { contextBridge, ipcRenderer } from "electron";const electronHandler = {  ipcRenderer: {    sendMessage(channel, ...args) {      ipcRenderer.send(channel, ...args);    },    on(channel, func) {      const subscription = (_event, ...args) => func(...args);      ipcRenderer.on(channel, subscription);      return () => {        ipcRenderer.removeListener(channel, subscription);      };    },    once(channel, func) {      ipcRenderer.once(channel, (_event, ...args) => func(...args));    },  },};contextBridge.exposeInMainWorld("electron", electronHandler);

This preload script exposes send, on and once methods of ipcRenderer tothe renderer process via the contextBridge. It allows the renderer to sendmessages, listen for events, and handle one-time events from the main processwhile maintaining security by controlling which APIs are accessible.

Build

Since an Electron application has two processes, we need two separate Webpackconfigurationsone for the main process and another for the rendererprocess.

// ./config/webpack/main.mjsimport path from "path";import webpack from "webpack";import { merge } from "webpack-merge";import TerserPlugin from "terser-webpack-plugin";const configuration = {  target: "electron-main",  entry: {    main: "src/main/main.mjs",    preload: "src/main/preload.mjs",  },  output: {    path: "release/app/dist/main",    filename: "[name].js",    library: {      type: "umd",    },  },  optimization: {    minimizer: [      new TerserPlugin({        parallel: true,      }),    ],  },  node: {    __dirname: false,    __filename: false,  },};export default configuration;

The above is a basic Webpack configuration for the main process. Webpacksupports Electron out of the box, so by setting target: "electron-main",Webpack includes all the necessary Electron variables. Since we also have apreload script, we added preload.mjs as an entry point as well. We will beminifying the code using TerserPlugin.

Another important detail is that we've disabled __dirname and __filename.This prevents Webpack's handling of these variables from interfering withNode.js's native __dirname and __filename, ensuring they behave as expectedin our Electron app.

// ./config/webpack/renderer.mjsimport path from "path";import webpack from "webpack";import HtmlWebpackPlugin from "html-webpack-plugin";import MiniCssExtractPlugin from "mini-css-extract-plugin";import { BundleAnalyzerPlugin } from "webpack-bundle-analyzer";import CssMinimizerPlugin from "css-minimizer-webpack-plugin";import { merge } from "webpack-merge";import TerserPlugin from "terser-webpack-plugin";const configuration = {  target: ["web", "electron-renderer"],  entry: "src/renderer/App.jsx",  output: {    path: "release/app/dist/renderer",    publicPath: "./",    filename: "renderer.js",    library: {      type: "umd",    },  },  module: {    rules: [      {        test: /\.s?(a|c)ss$/,        use: [          MiniCssExtractPlugin.loader,          {            loader: "css-loader",            options: {              modules: true,              sourceMap: true,              importLoaders: 1,            },          },          "sass-loader",        ],        include: /\.module\.s?(c|a)ss$/,      },      {        test: /\.s?(a|c)ss$/,        use: [          MiniCssExtractPlugin.loader,          "css-loader",          "sass-loader",          "postcss-loader",        ],        exclude: /\.module\.s?(c|a)ss$/,      },      // Fonts      {        test: /\.(woff|woff2|eot|ttf|otf)$/i,        type: "asset/resource",      },      // Images      {        test: /\.(png|jpg|jpeg|gif)$/i,        type: "asset/resource",      },      // SVG      {        test: /\.svg$/,        use: [          {            loader: "@svgr/webpack",            options: {              prettier: false,              svgo: false,              svgoConfig: {                plugins: [{ removeViewBox: false }],              },              titleProp: true,              ref: true,            },          },          "file-loader",        ],      },    ],  },  optimization: {    minimize: true,    minimizer: [new TerserPlugin(), new CssMinimizerPlugin()],  },  plugins: [    new MiniCssExtractPlugin({      filename: "style.css",    }),    new HtmlWebpackPlugin({      filename: "index.html",      template: "src/renderer/index.ejs",      minify: {        collapseWhitespace: true,        removeAttributeQuotes: true,        removeComments: true,      },      isBrowser: false,      isDevelopment: false,    }),  ],};export default configuration;

In the renderer configuration, we set the target totarget: ["web", "electron-renderer"], which provides both standard web andElectron's renderer variables. Similar to a typical web application setup, weload various plugins to handle fonts, images, and SVGs and to minify CSS andJavaScript. Since JavaScript files are loaded locally in an Electronapplication, we can bundle everything into a single file called renderer.jsinstead of splitting it into multiple chunks as we would for a standard webapplication.

Our build configuration is ready; add it to scripts in package.json for easyexecution.

"scripts": {    "build:main": "cross-env NODE_ENV=production webpack --config ./config/webpack/main.mjs",    "build:renderer": "cross-env NODE_ENV=production webpack --config ./config/webpack/renderer.mjs",    "build": "yarn build:main && yarn build:renderer",}

Great! Now, we can build the entire Electron application using a singleyarn build command.

Package

We can configure the electron-builder in package.json using the buildfield. Below is an example configuration for an app named MyApp.

 "build": {    "productName": "MyApp",    "appId": "com.neeto.MyApp",    "directories": {      "app": "release/app",      "buildResources": "assets",      "output": "release/build"    },     "mac": {      "target": {        "target": "default",        "arch": [          "arm64",          "x64"        ]      }    },    "win": {      "target": {        "target": "nsis",        "arch": [          "x64"        ]      },      "artifactName": "${productName}-Setup-${version}.${ext}"    },    "linux": {      "category": "Utility",      "target": [        {          "target": "rpm",          "arch": [            "x64"          ]        },        {          "target": "deb",          "arch": [            "x64"          ]        }      ],    }, }

In the Webpack configuration, we specified release/app as the output directoryfor the compiled JS code. This directory needs to be specified inelectron-builder so it knows where to find the compiled code during packaging.Use the directories.app field to specify this path, and we can also definewhere the packaged builds should be output using the directories.output field.

In addition to directories, the configuration includes settings for appId,productName and platform-specific configurations for mac, win(Windows),and linux. For each platform, we specify the installer target andarchitecture. This configuration will produce builds for both Intel (x64) andApple Silicon (arm64) on macOS. For Windows, it generates an NSISinstaller targeting 64-bit architecture (x64). On Linux, it produces bothRPM and DEB installers for 64-bit architecture (x64).

With the electron-builder configuration set, we can proceed to package ourapplication using the electron-builder build command.

"scripts": {    "build:main": "cross-env NODE_ENV=production webpack --config ./webpack/main.prod.mjs",    "build:renderer": "cross-env NODE_ENV=production webpack --config ./webpack/renderer.prod.mjs",    "build": "yarn build:main && yarn build:renderer",    "package": "yarn build && electron-builder build",}

We run yarn build before electron-builder build to ensure that theJavaScript code is compiled before packaging. This enables us to handle both thebuild and packaging processes in a single command.

Publish

To publish the app to a server where users can download and use it, we can passthe --publish flag to electron-builder build command. Before we can do that,we need to update our electron-builder configuration with publish serverinformation.

Here is an example configuration to publish the builds to an S3 bucket namedmy-app-downloads:

 "build": {  // other configs  "publish": [      {        "provider": "s3",        "bucket": "my-app-downloads",        "path": "/electron/my-app/",        "region": "us-east-1",        "acl": null      },    ] }

The publish field accepts an array, allowing us to publish to multiplelocations. We need to specify a provider, such as s3, but electron-builderalso supports other providers like github and more by default. For a completelist of all publishing options, check out thepublish documentation.

To wrap things up, let's automate the deployment process by creating a GitHubActions workflow. Since building macOS apps is only supported on macOS, we'llneed to run the workflow from a macOS environment.

name: Publishjobs:  publish:    runs-on: ${{ matrix.os }}    strategy:      matrix:        os: [macos-latest]    steps:      - name: Setup Java        uses: actions/setup-java@v3        with:          distribution: "adopt"          java-version: "11"      - name: Checkout git repo        uses: actions/checkout@v3      - name: Install Node and NPM        uses: actions/setup-node@v3        with:          node-version: 20          cache: npm      - name: Install rpm using Homebrew        run: brew install rpm      - name: Install and build        run: |          yarn install          yarn build      - name: Publish releases        env:          AWS_ACCESS_KEY_ID: ${{secrets.AWS_ACCESS_KEY}}          AWS_SECRET_ACCESS_KEY: ${{secrets.AWS_SECRET}}        run: npm exec electron-builder -- --publish always -mwl

To successfully build for Windows and Linux from macOS, we'll need to set up aJava version and install the rpm package. Additionally, configure ourAWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for the S3 bucket where we planto upload the builds. Once these steps are complete, we should be able to buildand publish our Electron app using the electron-builder -- --publish command.The -mwl flag indicates that the build should target macOS, Windows, andLinux.

Auto-update

To enable auto-updating for our application, we first need to code-sign andnotarize it. We'll cover the code-signing and notarization details in upcomingblog posts. Stay tuned!

When building desktop applications with Electron, oneof the key challenges developers often face is managing the shared state betweenthe main process and multiple renderer processes. While the main processhandles the core application logic, renderer processes are responsible for theuser interface. However, they often need access to the same data, like userpreferences, application state, or session information.

Electron does not natively provide a way to persist data, let alone give asynchronized state across these processes.

electron-store to store data persistently

Since Electron doesn't have a built-in way to persist data, We can useelectron-store, an npm packageto store data persistently. electron-store stores the data in a JSON filenamed config.json in app.getPath('userData').

Even though we can configure electron-store to be made directly available inthe renderer process, it is recommended not to do so. The best way is toexpose it viaElectron's preload script.

Let's look at how we can expose the electron store to the renderer via apreload script.

// preload.jsimport { contextBridge, ipcRenderer } from "electron";const electronHandler = {  store: {    get(key) {      return ipcRenderer.sendSync("get-store", key);    },    set(property, val) {      ipcRenderer.send("set-store", property, val);    },  },  // ...others code};contextBridge.exposeInMainWorld("electron", electronHandler);

Here, we exposed a set function that calls the ipcRenderer.send method,which just sends a message to the main process. The get function calls theipcRenderer.sendSync method, which will send a message to the main processwhile expecting a return value.

Now, let's add ipcMain events to handle these requests in the main process.

import Store from "electron-store";const store = new Store();ipcMain.on("get-store", async (event, val) => {  event.returnValue = store.get(val);});ipcMain.on("set-store", async (_, key, val) => {  store.set(key, val);});

In the main process, we created an electron-store instance and addedget-store and set-store event handlers to retrieve and set data from thestore.

Now, we can read and write data from any renderer process without exposing thewhole electron-store class to it.

window.electron.store.set("key", "value");window.electron.store.get("key");

Synchronization

Since we sorted out the storage issue, let's look into how we can synchronizedata between the main process and all its renderer processes.

Before we start synchronization, let's create a simple utility function that cansend a message to all active renderer processes or, in other words, browserwindows (we will use the terms renderer process and browser windowsinterchangeably).

export const sendToAll = (channel, msg) => {  BrowserWindow.getAllWindows().forEach(browseWindow => {    browseWindow.webContents.send(channel, msg);  });};

BrowserWindow.getAllWindows() returns all active browser windows, andbrowseWindow.webContents.send is the standard way of sending a message frommain to a renderer process.

electron-store onDidChange

electron-store provides an option to add an event listener when there is achange in the store called onDidChange. This is the key feature we are goingto use to create synchronization.

store.onDidChange("key", newValue => {  // TODO});

Not all data needs to be synchronized. So, instead of adding onDidChange toevery field, let's expose an API for the renderer process so that it candecide which data it needs and subscribe to it.

import Store from "electron-store";const store = new Store();const subscriptions = new Map();ipcMain.on("get-store", async (event, val) => {  event.returnValue = store.get(val);});ipcMain.on("set-store", async (_, key, val) => {  store.set(key, val);});ipcMain.on("subscribe-store", async (event, key) => {  const unsubscribeFn = store.onDidChange(key, newValue => {    sendToAll(`onChange:${key}`, newValue);  });  subscriptions.set(key, unsubscribeFn);});

Here, we exposed another API called subscribe-store. When calling that APIwith a key, we listen to that field's onDidChange event. Then, when theonDidChange triggers, we call the sendToAll function we created earlier, andall the renderer processes listening to these changes will be notified withthe latest data. For example, if a field called user is subscribed to changes,we send a message to all renderer processes with the new value on a channelcalled onChange:user. We will soon add code in the renderer process tohandle this.

store.onDidChange returns the unsubscribe function for that particular key.Since we won't be unsubscribing straight away, we need to store this functionfor later use. Here, we are storing it in a hash map against the same key.

Let's add an option to unsubscribe as well.

//... other codesipcMain.on("unsubscribe-store", async (event, key) => {  subscriptions.get(key)();});

Update preload script

Let's update the preload script to support the store'ssubscription/unsubscribing.

// preload.jsimport { contextBridge, ipcRenderer } from "electron";const electronHandler = {  store: {    get(key) {      return ipcRenderer.sendSync("get-store", key);    },    set(property, val) {      ipcRenderer.send("set-store", property, val);    },    subscribe(key, func) {      ipcRenderer.send("subscribe-store", key);      const subscription = (_event, ...args) => func(...args);      const channelName = `onChange:${key}`;      ipcRenderer.on(channelName, subscription);      return () => {        ipcRenderer.removeListener(channelName, subscription);      };    },    unsubscribe(key) {      ipcRenderer.send("unsubscribe-store", key);    },  },  // ...others code};contextBridge.exposeInMainWorld("electron", electronHandler);

We add two APIs here, subscribe and unsubscribe. While unsubscribe isstraightforward, subscribe might need some explanation. It exposes twoarguments, a store key and a callback function, to be called when there is achange to that field.

First, we call subscribe-store to subscribe to change to that data field;then, we listen to ipcRenderer.on for any changes. For example, when there isa change to the user field, sendToAll will propagate the change, and here weare listening to it on onChange:user.

Now, from a renderer process, if it needs to be notified of changes to theuser field, we can subscribe to it like below.

window.electron.store.subscribe("user", newUser => {  // TODO});

useSyncExternalStore

React provides a hook to connect to an external store calleduseSyncExternalStore. It expects two functions as arguments.

• The subscribe function should subscribe to the store and return anunsubscribe function.
• The getSnapshot function should read a snapshot of the data from the store.

In the renderer process, create a SyncedStore class with subscribe andgetSnapshot functions that useSyncExternalStore expects.

class SyncedStore {  snapshot;  defaultValue;  storageKey;  constructor(defaultValue = "", storageKey) {    this.defaultValue = defaultValue;    this.snapshot = window.electron.store.get(storageKey) ?? defaultValue;    this.storageKey = storageKey;  }  getSnapshot = () => this.snapshot;  subscribe = callback => {    // TODO  };}

Here, we created a generic class that takes a defaultValue and storageKey.While creating the object, we loaded the existing data for that field from themain store.

When React tries to subscribe to this using useSyncExternalStore, we need tocall our main store's subscribe.

class SyncedStore {  snapshot;  defaultValue;  storageKey;  constructor(defaultValue = "", storageKey) {    this.defaultValue = defaultValue;    this.snapshot = window.electron.store.get(storageKey) ?? defaultValue;    this.storageKey = storageKey;  }  getSnapshot = () => this.snapshot;  subscribe = callback => {    window.electron.store.subscribe(this.storageKey, callback);    return () => {      window.electron.store.unsubscribe(this.storageKey);    };  };}

We have our SyncedStore ready, but it's a bit inefficient; for example, if weare subscribed to the same storageKey in multiple places, it will create asubscription for each instance in the main store. That is needless IPCcommunications for the same data.

Let's improve this a bit so that only one subscription is registered per browserwindow(renderer process), and if there are multiple use cases of the same,let's handle it internally.

class SyncedStore {  snapshot;  defaultValue;  storageKey;  listeners = new Set();  constructor(defaultValue = "", storageKey) {    this.defaultValue = defaultValue;    this.snapshot = window.electron.store.get(storageKey) ?? defaultValue;    this.storageKey = storageKey;  }  getSnapshot = () => this.snapshot;  onChange = newValue => {    if (JSON.stringify(newValue) === JSON.stringify(this.snapshot)) return;    this.snapshot = newValue ?? this.defaultValue;    this.listeners.forEach(listener => listener());  };  subscribe = callback => {    this.listeners.add(callback);    if (this.listeners.size === 1) {      window.electron.store.subscribe(this.storageKey, this.onChange);    }    return () => {      this.listeners.delete(callback);      if (this.listeners.size !== 0) return;      window.electron.store.unsubscribe(this.storageKey);    };  };}

We made the change so that only one request is sent to main; the rest of thesubscriptions are stored internally and respond to it when the first one isnotified.

We also added additional checks to ensure that rerender is not triggered ifthere are no changes to the data.

Usage

Now, whenever a synchronized store for a field is needed, we just need to createan instance of this class and pass it to useSyncExternalStore.

import { useSyncExternalStore } from "react";const createSyncedStore = ({ defaultValue, storageKey }) => {  const store = new SyncedStore(defaultValue, storageKey);  return () => useSyncExternalStore(store.subscribe, store.getSnapshot);};const useUser = createSyncedStore({  storageKey: "user",  defaultValue: { firstName: "Oliver", lastName: "Smith" },});const App = () => {  const user = useUser();  return <div>Name: {`${user.firstName} ${user.lastName}`}</div>;};

Now, if we update the user field from anywhere, let it be from any rendererprocess or main.

window.electron.store.set("user", { firstName: "John", lastName: "Smith" });

The above App component will be rerendered with the latest user data.