Electron 15.0.0 has been released! It includes upgrades to Chromium 94, V8 9.4, and Node.js 16.5.0. We've added API updates to window.open, bug fixes, and general improvements. Read below for more details!

The Electron team is excited to announce the release of Electron 15.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release and please share any feedback you have!

Notable Changes​

Electron Release Cadence Change​

Starting with Electron 15, Electron will release a new major stable version every 8 weeks. You can read the full details here.

Additionally, Electron will be changing supported versions from latest three versions to latest four versions until May 2022. See our versioning documentfor more detailed information about versioning in Electron.

Stack Changes​

• Chromium 94
  • New in Chrome 94
• Node.js 16.5.0
  • Node 16.5.0 blog post
• V8 9.4
  • V8 9.4 blog post

Highlight Features​

• nativeWindowOpen: true is no longer experimental, and is now the default.
• Added safeStorage string encryption API. #30430
• Added 'frame-created' event to WebContents which emits when a frame is created in the page. #30801
• Added resize edge info to BrowserWindow's will-resize event. #29199

See the 15.0.0 release notes for a full list of new features and changes.

Breaking Changes​

Below are breaking changes introduced in Electron 15. More information about these and future changes can be found on the Planned Breaking Changes page.

Default Changed: nativeWindowOpen defaults to true​

Prior to Electron 15, window.open was by default shimmed to use BrowserWindowProxy. This meant that window.open('about:blank') did not work to open synchronously scriptable child windows, among other incompatibilities. nativeWindowOpen: true is no longer experimental, and is now the default.

See the documentation for window.open in Electron for more details.

API Changes​

• Added 'frame-created' event to WebContents which emits when a frame is created in the page. #30801
• Added safeStorage string encryption API. #30430
• Added signal option to dialog.showMessageBox. #26102
• Added an Electron Fuse for enforcing code signatures on the app.asar file your application loads. Requires the latest asar module (v3.1.0 or higher). #30900
• Added fuses to disable NODE_OPTIONS and --inspect debug arguments in packaged apps. #30420
• Added new MenuItem.userAccelerator property to read user-assigned macOS accelerator overrides. #26682
• Added new app.runningUnderARM64Translation property to detect when running under Rosetta on Apple Silicon, or WOW on Windows for ARM. #29168
• Added new imageAnimationPolicy web preference to control how images are animated. #29095
• Added support for sending Blobs over the context bridge. #29247

Removed/Deprecated Changes​

No APIs have been removed or deprecated.

Supported Versions​

Starting in Electron 15, we will change supported versions from latest three versions to latest four versions until May 2022 with Electron 19. After Electron 19, we will return to supporting the latest three versions. This version support change is part of our new cadence change. Please see our blog post for full details here.

Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly.

You can find Electron's public timeline here.

More information about future changes can be found on the Planned Breaking Changes page.

Electron 14.0.0 has been released! It includes upgrades to Chromium 93 and V8 9.3. We've added several API updates, bug fixes, and general improvements. Read below for more details!

The Electron team is excited to announce the release of Electron 14.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release and please share any feedback you have!

Notable Changes​

Electron Release Cadence Change​

Beginning in September 2021 with Electron 15, Electron will release a new major stable version every 8 weeks. You can read the full details here. Electron 15 will begin beta on September 1, 2021 and stable release will be on September 21, 2021. You can find Electron's public timeline here. Additionally, Electron will be changing supported versions from latest three versions to latest four versions until May 2022. See see our versioning document for more detailed information about versioning in Electron.

Stack Changes​

• Chromium 93
  • New in Chrome 93
  • New in Chrome 92
• Node.js 14.17.0
  • Node 14.17.0 blog post
• V8 9.3
  • V8 9.3 blog post
  • V8 9.2 blog post

Highlight Features​

• Default Changed: nativeWindowOpen now defaults to true. (see docs)
• Child windows no longer inherit BrowserWindow construction options from their parents. #28550
• Added new session.storagePath API to get the path on disk for session-specific data. #28665
• Added process.contextId used by @electron/remote. #28007
• Added experimental cookie encryption support behind an Electron Fuse. #29492

See the 14.0.0 release notes for a full list of new features and changes.

Breaking Changes​

Below are breaking changes introduced in Electron 14. More information about these and future changes can be found on the Planned Breaking Changes page.

Removed: app.allowRendererProcessReuse​

The app.allowRendererProcessReuse property has been removed as part of our plan to more closely align with Chromium's process model for security, performance and maintainability.

For more detailed information see #18397.

Removed: Browser Window Affinity​

The affinity option when constructing a new BrowserWindow has been removed as part of our plan to more closely align with Chromium's process model for security, performance and maintainability.

For more detailed information see #18397.

API Changed: window.open()​

The optional parameter frameName no longer sets the title of the window. This behavior now follows the specification described by the native documentation for the windowName parameter.

If you were using this parameter to set the title of a window, you can instead use the win.setTitle(title) method.

Removed: worldSafeExecuteJavaScript​

worldSafeExecuteJavaScript has been removed with no alternative. Please ensure your code works with this property enabled. It has been enabled by default since Electron 12.

You will be affected by this change if you use either webFrame.executeJavaScript or webFrame.executeJavaScriptInIsolatedWorld. You will need to ensure that values returned by either of those methods are supported by the Context Bridge API as these methods use the same value passing semantics.

Default Changed: nativeWindowOpen defaults to true​

Prior to Electron 14, window.open was by default shimmed to use BrowserWindowProxy. This meant that window.open('about:blank') did not work to open synchronously scriptable child windows, among other incompatibilities. nativeWindowOpen is no longer experimental, and is now the default.

See the documentation for window.open in Electron for more details.

Removed: BrowserWindowConstructorOptions inheriting from parent windows​

Prior to Electron 14, windows opened with window.open would inherit BrowserWindow constructor options such as transparent and resizable from their parent window. Beginning with Electron 14, this behavior has been removed and windows will not inherit any BrowserWindow constructor options from their parents.

Instead, explicitly set options for the new window with setWindowOpenHandler:

webContents.setWindowOpenHandler((details) => {
  return {
    action: 'allow',
    overrideBrowserWindowOptions: {
      // ...
    },
  };
});

Removed: additionalFeatures​

The deprecated additionalFeatures property in the new-window and did-create-window events of WebContents has been removed. Since new-window uses positional arguments, the argument is still present, but will always be the empty array []. (Note: the new-window event itself is already deprecated and has been replaced by setWindowOpenHandler.) Bare keys in window features will now present as keys with the value true in the options object.

// Removed in Electron 14
// Triggered by window.open('...', '', 'my-key')
webContents.on('did-create-window', (window, details) => {
  if (details.additionalFeatures.includes('my-key')) {
    // ...
  }
});

// Replace with
webContents.on('did-create-window', (window, details) => {
  if (details.options['my-key']) {
    // ...
  }
});

Removed: remote module​

Deprecated in Electron 12, the remote module has now been removed from Electron itself and extracted into a separate package, @electron/remote. The @electron/remote module bridges JavaScript objects from the main process to the renderer process. This lets you access main-process-only objects as if they were available in the renderer process. This is a direct replacement for the remote module. See the module's readme for migration instructions and reference.

API Changes​

• Added BrowserWindow.isFocusable() method to determine whether a window is focusable. #28642
• Added WebFrameMain.visibilityState instance property. #28706
• Added disposition, referrer and postBody to the details object passed to the window open handler registered with setWindowOpenHandler. #28518
• Added process.contextId used by @electron/remote. #28007
• Added experimental cookie encryption support behind an Electron Fuse. #29492
• Added missing resourceType conversions for webRequest listener details: font, ping, cspReport, media, webSocket. #30050
• Added new session.storagePath API to get the path on disk for session-specific data. #28665
• Added support for Windows Control Overlay on macOS. #29986
• Added support for directing Chromium logging to a file with --log-file=.../path/to/file.log. Also, it's now possible to enable logging from JavaScript by appending command-line switches during the first JS tick. #29963
• Added support for the des-ede3 cipher in node crypto. #27897
• Added a ContextBridgeMutability feature that allows context bridge objects to be mutated. #27348

Removed/Deprecated Changes​

The following APIs have been removed or are now deprecated:

• The remote module has been removed after being deprecated in Electron 12. #25734
• Child windows no longer inherit BrowserWindow construction options from their parents. #28550
• Removed deprecated additionalFeatures property from new-window and did-create-window WebContents events. #28548
• Removed the deprecated app.allowRendererProcessReuse and BrowserWindow affinity options. #26874
• The submitURL option for crashReporter.start is no longer a required argument when uploadToServer is false. #28105

End of Support for 11.x.y​

Electron 11.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes.

Over the past weeks, we’ve received several questions about the differences between the new WebView2 and Electron.

Both teams have the expressed goal of making web-tech the best it can be on the Desktop, and a shared comprehensive comparison is being discussed.

Electron and WebView2 are fast-moving and constantly evolving projects. We have assembled a brief snapshot of similarities and differences between Electron and WebView2 as they exist today.

Architecture Overview​

Electron and WebView2 both build from the Chromium source for rendering web content. Strictly speaking, WebView2 builds from the Edge source, but Edge is built using a fork of the Chromium source. Electron does not share any DLLs with Chrome. WebView2 binaries hard link against Edge (Stable channel as of Edge 90), so they share disk and some working set. See Evergreen distribution mode for more info.

Electron apps always bundle and distribute the exact version of Electron with which they were developed. WebView2 has two options in distribution. You can bundle the exact WebView2 library your application was developed with, or you can use a shared-runtime version that may already be present on the system. WebView2 provides tools for each approach, including a bootstrapping installer in case the shared runtime is missing. WebView2 is shipped inbox starting with Windows 11.

Applications that bundle their frameworks are responsible for updating those frameworks, including minor security releases. For apps using the shared WebView2 runtime, WebView2 has its own updater, similar to Chrome or Edge, that runs independent of your application. Updating the application's code or any of its other dependencies is still a responsibility for the developer, same as with Electron. Neither Electron nor WebView2 is managed by Windows Update.

Both Electron and WebView2 inherit Chromium’s multi-process architecture - namely, a single main process that communicates with one-or-more renderer processes. These processes are entirely separate from other applications running on the system. Every Electron application is a separate process tree, containing a root browser-process, some utility processes, and zero or more render processes. WebView2 apps that use the same user data folder (like a suite of apps would do), share non-renderer processes. WebView2 apps using different data folders do not share processes.

• ElectronJS Process Model:

  

• WebView2 Based Application Process Model:

  

Read more about WebView2’s process model and Electron’s process model here.

Electron provides APIs for common desktop application needs such as menus, file system access, notifications, and more. WebView2 is a component meant to be integrated into an application framework such as WinForms, WPF, WinUI, or Win32. WebView2 does not provide operating system APIs outside the web standard via JavaScript.

Node.js is integrated into Electron. Electron applications may use any Node.js API, module, or node-native-addon from the renderer and main processes. A WebView2 application does not assume which language or framework the rest of your application is written in. Your JavaScript code must proxy any operating system access through the application-host process.

Electron strives to maintain compatibility with the web API, including APIs developed from the Fugu Project. We have a snapshot of Electron’s Fugu API compatibility. WebView2 maintains a similar list of API differences from Edge.

Electron has a configurable security model for web content, from full-access to full-sandbox. WebView2 content is always sandboxed. Electron has comprehensive security documentation on choosing your security model. WebView2 also has security best practices.

The Electron source is maintained and available on GitHub. Applications can modify can build their own brands of Electron. The WebView2 source is not available on GitHub.

Quick Summary:

Performance Discussion​

When it comes to rendering your web content, we expect little performance difference between Electron, WebView2, and any other Chromium-based renderer. We created scaffolding for apps built using Electron, C++ + WebView2, and C# + WebView2 for those interested to investigate potential performance differences.

There are a few differences that come into play outside of rendering web content, and folks from Electron, WebView2, Edge, and others have expressed interest in working on a detailed comparison including PWAs.

Inter-Process Communication (IPC)​

There is one difference we want to highlight immediately, as we believe it is often a performance consideration in Electron apps.

In Chromium, the browser process acts as an IPC broker between sandboxed renderers and the rest of the system. While Electron allows unsandboxed render processes, many apps choose to enable the sandbox for added security. WebView2 always has the sandbox enabled, so for most Electron and WebView2 apps IPC can impact overall performance.

Even though Electron and WebView2 have a similar process models, the underlying IPC differs. Communicating between JavaScript and C++ or C# requires marshalling, most commonly to a JSON string. JSON serialization/parsing is an expensive operation, and IPC-bottlenecks can negatively impact performance. Starting with Edge 93, WV2 will use CBOR for network events.

Electron supports direct IPC between any two processes via the MessagePorts API, which utilize the structured clone algorithm. Applications which leverage this can avoid paying the JSON-serialization tax when sending objects between processes.

Summary​

Electron and WebView2 have a number of differences, but don't expect much difference with respect to how they perform rendering web content. Ultimately, an app’s architecture and JavaScript libraries/frameworks have a larger impact on memory and performance than anything else because Chromium is Chromium regardless of where it is running.

Special thanks to the WebView2 team for reviewing this post, and ensuring we have an up-to-date view of the WebView2 architecture. They welcome any feedback on the project.

Beginning in September 2021, Electron will release a new major stable version every 8 weeks.

In 2019, Electron moved to a 12 week release cycle to match Chromium's 6 week release cycle. Recently, both Chrome and Microsoft announced changes that made us reconsider Electron's current release cadence:

1. Chromium plans to release a new milestone every 4 weeks, starting with Chrome 94 on September 21st, 2021. This release cadence also adds a new Extended Stable option every 8 weeks, which will contain all updated security fixes.

2. The Microsoft Store will require Chromium-based apps to be no older than within 2 major versions. As an example, if the latest released major version of Chromium is 85, any browser based on Chromium must be on at least Chromium version 83 or higher. This rule includes Electron apps.

Beginning in September 2021, Electron will release a new major stable version every 8 weeks, to match Chromium's 8 week Extended Stable releases.

Our first release with Chromium Extended Stable will be Electron 15 on September 21st, 2021.

Knowing that a release cadence change will impact other downstream applications, we wanted to let our developer community know as soon as possible. Read on for more details about our 2021 release schedule.

Electron 15: Temporary Alpha​

Given that our original Electron 15 release targeted a non-Extended Stable version (Chromium's Extended Stable versions are based on their even-numbered versions), we needed to change our original target release date. However, an Electron app must use the most recent 2 major versions of Chromium to be accepted to the Microsoft Store, which made waiting for two Chromium versions untenable.

With these two requirements, our team faced a timing dilemma. Moving Electron 15 to include Chromium M94 would allow app developers to get on the very first Extended Stable version of Chromium; however, it would also shorten the beta-to-stable cycle to only 3 weeks.

To help with this switchover, Electron will offer a temporary alpha build, only for the Electron 15 release. This alpha build will allow developers more time to test and plan for an Electron 15 release, with a more stable build than our current nightlies.

The alpha channel build will ship for Electron 15 on July 20th, 2021. It will transition to a beta release on September 1st, 2021 with a stable release target of September 21st, 2021. Subsequent Electron releases will not have alpha releases.

2021 Plan for Releases​

Below is our current release schedule for 2021:

Adding the alpha channel extends the development time before Electron 15's launch from 3 weeks to 9 weeks - closer to our new 8 week cycle, while still meeting the requirements for Windows Store submission.

To further help app developers, for the remainder of 2021 until May 2022, we will also be extending our supported versions policy from the latest 3 versions to the latest 4 versions of Electron. That means that even if you can't immediately alter your upgrade schedule, older versions of Electron will still receive security updates and fixes.

Addressing Concerns​

There's a reason we're publishing this post well before this release cycle change is scheduled. We know that a faster release cycle will have a real impact on Electron apps - some of which may already find our major release cadence aggressive.

We've tried to address common concerns below:

❓ Why even make this change? Why not keep the 12 week release cadence?​

To deliver the most up-to-date versions of Chromium in Electron, our schedule needs to track theirs. More information around Chromium's release cycle can be found here.

Additionally, the current 12 week release cadence would be untenable with the Microsoft Store's new submission requirements. Even apps on the latest stable version of Electron would experience a roughly two week period where their app may be rejected under the new security requirements.

Every new Chromium release contains new features, bug fixes / security fixes, and V8 improvements. We want you, as app developers, to have these changes in a timely manner, so our stable release dates will continue to match every other Chromium stable release. As an app developer, you'll have access to new Chromium and V8 features and fixes sooner than before.

❓ The existing 12 week release schedule already moves quickly. What steps are the team taking to make upgrading easier?​

One advantage of more frequent releases is having smaller releases. We understand that upgrading Electron's major versions can be difficult. We hope that smaller releases will introduce fewer major Chromium and Node changes, as well as fewer breaking changes, per release.

❓ Will there been an alpha release available for future Electron versions?​

There are no plans to support a permanent alpha release at this time. This alpha is only intended for Electron 15, as a way to help developers upgrade more easily in the shortened release period.

❓ Will Electron extend the number of supported versions?​

We will be extending our supported version policy from the latest three versions to the latest four versions of Electron until May 2022, with the release of Electron 19. After Electron 19 is released, we'll return to supporting the latest three major versions, as well as the beta and nightly releases.

Questions?​

📨 If you have questions or concerns, please mail us at info@electronjs.org or join our Discord. We know this is a change that will impact many apps and developers, and your feedback is very important to us. We want to hear from you!

Electron 13.0.0 has been released! It includes upgrades to Chromium 91 and V8 9.1. We've added several API updates, bug fixes, and general improvements. Read below for more details!

The Electron team is excited to announce the release of Electron 13.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

Stack Changes​

• Chromium 91
  • New in Chrome 91
  • New in Chrome 90
• Node.js 14.16.0
  • Node 14.16.0 blog post
  • Node 14.0.0 blog post
• V8 9.1
  • V8 9.1 blog post
  • V8 9.0 blog post

Highlight Features​

• Added process.contextIsolated property that indicates whether the current renderer context has contextIsolation enabled. #28252
• Added new session.storagePath API to get the path on disk for session-specific data. #28866
• Deprecated the new-window event of WebContents. It is replaced by webContents.setWindowOpenHandler()
• Added process.contextId used by @electron/remote. #28251

See the 13.0.0 release notes for a full list of new features and changes.

Breaking Changes​

• window.open() parameter frameName is no longer set as window title. #27481
• Changed session.setPermissionCheckHandler(handler) to allow for handler's first parameter, webContents to be null. #19903

More information about these and future changes can be found on the Planned Breaking Changes page.

API Changes​

• Added roundedCorners option for BrowserWindow. #27572
• Added new session.storagePath API to get the path on disk for session-specific data.28866
• Added support for passing DOM elements over the context bridge. #26776
• Added process.uptime() to sandboxed renderers. #26684
• Added missing fields to the parameters emitted as part of the context-menu event.#26788
• Added support for registering Manifest V3 extension service workers.
• Added ‘registration-completed’ event to ServiceWorkers. #27562

Removed/Deprecated Changes​

The following APIs have been removed or are now deprecated:

• Deprecated the new-window event of WebContents. It is replaced by webContents.setWindowOpenHandler()

• Removed deprecated shell.moveItemToTrash(). #26723

• Removed the following deprecated BrowserWindow extension APIs:

  • BrowserWindow.addExtension(path)
  • BrowserWindow.addDevToolsExtension(path)
  • BrowserWindow.removeExtension(name)
  • BrowserWindow.removeDevToolsExtension(name)
  • BrowserWindow.getExtensions()
  • BrowserWindow.getDevToolsExtensions()

  Use the session APIs instead:

  • ses.loadExtension(path)
  • ses.removeExtension(extension_id)
  • ses.getAllExtensions()

• The following systemPreferences methods have been deprecated:

  • systemPreferences.isDarkMode()
  • systemPreferences.isInvertedColorScheme()
  • systemPreferences.isHighContrastColorScheme()

  Use the following nativeTheme properties instead:

  • nativeTheme.shouldUseDarkColors
  • nativeTheme.shouldUseInvertedColorScheme
  • nativeTheme.shouldUseHighContrastColors

End of Support for 10.x.y​

Electron 10.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 14.0.0 schedule maps out key dates in the Electron 14.0 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Electron 12.0.0 has been released! It includes upgrades to Chromium 89, V8 8.9 and Node.js 14.16. We've added changes to the remote module, new defaults for contextIsolation, a new webFrameMain API, and general improvements. Read below for more details!

The Electron team is excited to announce the release of Electron 12.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

Stack Changes​

• Chromium 89
  • New in Chrome 88
  • New in Chrome 89
• Node.js 14.16
  • Node 14.16.0 blog post
  • Node 14.0.0 blog post
• V8 8.9
  • V8 8.8 blog post
  • V8 8.9 blog post

Highlight Features​

• The ContextBridge exposeInMainWorld method can now expose non-object APIs. #26834
• Upgraded from Node 12 to Node 14. #23249
• Added a new webFrameMain API for accessing sub-frames of a WebContents instance from the main process. #25464
• The default values of contextIsolation and worldSafeExecuteJavaScript are now true. #27949 #27502

See the 12.0.0 release notes for a full list of new features and changes.

Breaking Changes​

• Deprecated the remote module. It is replaced by @electron/remote. #25293
  • If you are currently using the remote module, we've written a guide to migrating to @electron/remote here.
• Changed the default value of contextIsolation to true. #27949
• Changed the default value of worldSafeExecuteJavaScript to true. #27502
• Changed the default of crashReporter.start({ compress }) from false to true. #25288
• Removed Flash support: Chromium has removed support for Flash, which was also removed in Electron 12. See Chromium's Flash Roadmap for more details.
• Required SSE3 for Chrome on x86: Chromium has removed support for older x86 CPUs that do not meet a minimum of SSE3 (Streaming SIMD Extensions 3) support. This support was also removed in Electron 12.

More information about these and future changes can be found on the Planned Breaking Changes page.

API Changes​

• Added webFrameMain API: The webFrameMain module can be used to look up frames across existing WebContents instances. This is the main process equivalent of the existing webFrame API. More information about this new API can be found here, and in our documentation.
• app API changes:
  • Added non-localized serviceName to 'child-process-gone' / app.getAppMetrics(). #25975
  • Added new app.runningUnderRosettaTranslation property to detect when running under rosetta on Apple silicon. #26444
  • Added exitCode to render-process-gone details (app & webContents). #27677
• BrowserWindow API changes:
  • Added BrowserWindow.isTabletMode() API. #25209
  • Added resized (Windows/macOS) and moved (Windows) events to BrowserWindow. #26216
  • Added new system-context-menu event to allow preventing and overriding the system context menu. #25795
  • Added win.setTopBrowserView() so that BrowserViews can be raised. #27713
  • Added webPreferences.preferredSizeMode to allow sizing views according to their document's minimum size. #25874
• contextBridge API changes:
  • Allowed ContextBridge exposeInMainWorld method to expose non-object APIs. #26834
• display API changes:
  • Added displayFrequency property to the Display object to allow getting information about the refresh rate on Windows. #26472
• extensions API changes:
  • Added support for some chrome.management APIs. #25098
• MenuItem API changes:
  • Added support for showing macOS share menu. #25629
• net API changes:
  • Added a new credentials option for net.request(). #25284
  • Added net.online for detecting whether there is currently internet connection. #21004
• powerMonitor API changes:
  • Added powerMonitor.onBatteryPower. #26494
  • Added fast user switching event to powerMonitor on macOS. #25321
• session API changes:
  • Added allowFileAccess option to ses.loadExtension() API. #27702
  • Added display-capture API for session.setPermissionRequestHandler. #27696
  • Added a disabledCipherSuites option to session.setSSLConfig. #25818
  • Added extension-loaded, extension-unloaded, and extension-ready events to session. #25385
  • Added session.setSSLConfig() to allow configuring SSL. #25461
  • Added support for explicitly specifying direct, auto_detect or system modes in session.setProxy(). #24937
  • Added Serial API support. #25237
  • Added APIs to enable/disable spell checker. #26276
• shell API changes:
  • Added a new asynchronous shell.trashItem() API, replacing the synchronous shell.moveItemToTrash(). #25114
• webContents API changes:
  • Added a small console hint to console to help debug renderer crashes. #25317
  • Added frame and webContents properties to the details object in webRequest handlers. #27334
  • Added webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process to assist with recovering a hung renderer. #25580
  • Added setWindowOpenHandler API for renderer-created child windows, and deprecate new-window event. #24517
• webFrame API changes:
  • Added spellcheck API to renderer. #25060

Removed/Deprecated Changes​

The following APIs have been removed or are now deprecated:

• Deprecated the remote module. It is replaced by @electron/remote. #25293
• Removed deprecated crashReporter APIs. #26709
• Removed links to the Electron website from the default 'Help' menu in packaged apps. #25831

End of Support for 9.x.y​

Electron 9.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 13.0.0 schedule maps out key dates in the Electron 13.0 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Electron 11.0.0 has been released! It includes upgrades to Chromium 87, V8 8.7, and Node.js 12.18.3. We've added support for Apple silicon, and general improvements. Read below for more details!

The Electron team is excited to announce the release of Electron 11.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new support for Apple's M1 hardware.

We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

Stack Changes​

• Chromium 87.0.4280.47
  • New in Chrome 86
  • New in Chrome 87
• Node.js 12.18.3
  • Node 12.18.3 blog post
  • Node 12.7.0 blog post
• V8 8.7
  • V8 8.6 blog post
  • V8 8.7 blog post

Highlight Features​

• Support for Apple M1: On November 10, Apple announced their new M1 chips, which will be included in their upcoming hardware. Beginning in Electron 11, Electron will be shipping separate versions of Electron for Intel Macs (x64) and Apple's upcoming M1 hardware (arm64). You can learn more about how to get your Electron app running on Apple's M1 hardware here. #24545
• Added V8 crash message and location information to crashReport parameters. #24771
• Improved the performance of sending wide objects over the context bridge. #24671

See the 11.0.0 release notes for a full list of new features and changes.

Breaking Changes​

• Removed experimental APIs: BrowserView.{fromId, fromWebContents, getAllViews} and the id property of BrowserView. #23578

More information about these and future changes can be found on the Planned Breaking Changes page.

API Changes​

• Added app.getApplicationInfoForProtocol() API that returns detailed information about the app that handles a certain protocol. #24112
• Added app.createThumbnailFromPath() API that returns a preview image of a file given its file path and a maximum thumbnail size. #24802
• Added webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process to assist with recovering a hung renderer. #25756

End of Support for 8.x.y​

Electron 8.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately quarterly. The tentative 12.0.0 schedule maps out key dates in the Electron 12.0 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Continued Work for Deprecation of remote Module​

We started work to remove the remote module in Electron 9. We plan to remove the remote module itself in Electron 14.

Read and follow this issue for full plans and details for deprecation.

Final Step for Requiring Native Node Modules to be Context Aware or N-API (in Electron 12)​

From Electron 6 onwards, we've been laying the groundwork to require native Node modules loaded in the renderer process to be either N-API or Context Aware. Enforcing this change allows for stronger security, faster performance, and reduced maintenance workload. The final step of this plan is to remove the ability to disable render process reuse in Electron 12.

Read and follow this issue for full details, including the proposed timeline.

With Apple Silicon hardware being released later this year, what does the path look like for you to get your Electron app running on the new hardware?

With the release of Electron 11.0.0-beta.1, the Electron team is now shipping builds of Electron that run on the new Apple Silicon hardware that Apple plans on shipping later this year. You can grab the latest beta with npm install electron@beta or download it directly from our releases website.

How does it work?​

As of Electron 11, we will be shipping separate versions of Electron for Intel Macs and Apple Silicon Macs. Prior to this change, we were already shipping two artifacts, darwin-x64 and mas-x64, with the latter being for Mac App Store compatibility usage. We are now shipping another two artifacts, darwin-arm64 and mas-arm64, which are the Apple Silicon equivalents of the aforementioned artifacts.

What do I need to do?​

You will need to ship two versions of your app: one for x64 (Intel Mac) and one for arm64 (Apple Silicon). The good news is that electron-packager, electron-rebuild and electron-forge already support targeting the arm64 architecture. As long as you're running the latest versions of those packages, your app should work flawlessly once you update the target architecture to arm64.

In the future, we will release a package that allows you to "merge" your arm64 and x64 apps into a single universal binary, but it's worth noting that this binary would be huge and probably isn't ideal for shipping to users.

Update: This package is now available at @electron/universal. You can use it to merge two packaged x64 and arm64 apps into a single binary.

Potential Issues​

Native Modules​

As you are targeting a new architecture, you'll need to update several dependencies which may cause build issues. The minimum version of certain dependencies are included below for your reference.

As a result of these dependency version requirements, you may have to fix/update certain native modules. One thing of note is that the Xcode upgrade will introduce a new version of the macOS SDK, which may cause build failures for your native modules.

How do I test it?​

Currently, Apple Silicon applications only run on Apple Silicon hardware, which isn't commercially available at the time of writing this blog post. If you have a Developer Transition Kit, you can test your application on that. Otherwise, you'll have to wait for the release of production Apple Silicon hardware to test if your application works.

What about Rosetta 2?​

Rosetta 2 is Apple's latest iteration of their Rosetta technology, which allows you to run x64 Intel applications on their new arm64 Apple Silicon hardware. Although we believe that x64 Electron apps will run under Rosetta 2, there are some important things to note (and reasons why you should ship a native arm64 binary).

• Your app's performance will be significantly degraded. Electron / V8 uses JIT compilation for JavaScript, and due to how Rosetta works, you will effectively be running JIT twice (once in V8 and once in Rosetta).
• You lose the benefit of new technology in Apple Silicon, such as the increased memory page size.
• Did we mention that the performance will be significantly degraded?

Join us for community bonding and a month-long celebration of open-source.

Electron Community Discord Launch

Electron’s Outreach Working Group is excited to announce the launch of our official community Discord server!

Why a new Discord server?​

In its early days as the backbone of the Atom text editor, community discussion on the Electron framework occurred in a single channel in Atom’s Slack workspace. As time passed and the two projects were increasingly decoupled, the relevance of the Atom workspace to the Electron project decreased, and maintainer participation in the Slack channel declined in the same manner.

Up until now, we had still been redirecting our broader community to the Atom Slack workspace, even though we’ve had many reports from folks who have had trouble receiving invitations, and few of our core maintainers were frequenting the channel.

We’re setting up this shiny new server to be a central discussion hub for the community where you can get the latest news on all things Electron.

Get in here!​

So far, the server’s membership consists of a few maintainers who have been working together to set it up, but we’re so excited to chat with you all! Come ask for help, keep up to date with Electron releases, or just hang out with other developers. We’ve got a handy invite for you that’ll give you access to the server!

Hacktoberfest 2020

As a large and long-running open-source project, Electron wouldn’t have been nearly as successful without all the contributions from its community, from code submissions to bug reports to documentation changes, and much more. That’s why we believe in the importance of participating in Hacktoberfest to usher in a wider community of developers of all skill levels into the project.

Odds and ends​

This year, we don’t have a wider project to give you all to work on, but we’d like to focus on opportunities to contribute across the Electron JavaScript ecosystem.

Look out for issues tagged hacktoberfest across our various repositories, including the main electron/electron repository, the electron/electronjs.org website, electron/fiddle, and electron-userland/electron-forge!

P.S. If you're feeling particularly adventurous, we also have a backlog of issues marked with help wanted tags if you're looking for more of a challenge.

Stuck? Come chat with us!​

Moreover, it’s also no coincidence that the grand opening of our Discord server coincides with the largest celebration of open-source software of the year. Check out the #hacktoberfest channel to ask for help on your Hacktoberfest PR. In case you missed it, here's the invite link again!

Electron 10.0.0 has been released! It includes upgrades to Chromium 85, V8 8.5, and Node.js 12.16. We've added several new API integrations and improvements. Read below for more details!

The Electron team is excited to announce the release of Electron 10.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features.

In the Electron 10 release, we also made a change to our release notes. To make it easier to tell what's brand new in Electron 10 and what may have changed between Electron 10 and past releases, we now also include changes that were introduced to Electron 10, but backported to previous releases. We hope this makes it easier to apps to find new features and bug fixes when upgrading Electron.

We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

Stack Changes​

• Chromium 85.0.4183.84
  • New in Chrome 84
  • New in Chrome 85
• Node.js 12.16.3
  • Node 12.16.3 blog post
• V8 8.5
  • V8 8.4 blog post
  • V8 8.5 blog post

Highlight Features​

• Added contents.getBackgroundThrottling() method and contents.backgroundThrottling property. [#21036]
• Exposed the desktopCapturer module in the main process. #23548
• Can now check if a given session is persistent by calling the ses.isPersistent() API. #22622
• Resolve network issues that prevented RTC calls from being connected due to network IP address changes and ICE. (Chromium issue 1113227). #24998

See the 10.0.0 release notes for a full list of new features and changes.

Breaking Changes​

• Changed the default value of enableRemoteModule to false. #22091
  • This is part of our plans for deprecating the remote module and moving it to userland. You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.
• Changed the default value of app.allowRendererProcessReuse to true. #22336 (Also in Electron 9)
  • This will prevent loading of non-context-aware native modules in renderer processes.
  • You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.
• Fixed the positioning of window buttons on macOS when the OS locale is set to an RTL language (like Arabic or Hebrew). Frameless window apps may have to account for this change while styling their windows. #22016

More information about these and future changes can be found on the Planned Breaking Changes page.

API Changes​

• Session: Can now check if a given session is persistent by calling the ses.isPersistent() API. #22622
• Contents: Added contents.getBackgroundThrottling() method and contents.backgroundThrottling property. #21036

Deprecated APIs​

The following APIs are now deprecated or removed:

• Removed the deprecated currentlyLoggingPath property of netLog. Additionally, netLog.stopLogging no longer returns the path to the recorded log. #22732
• Deprecated uncompressed crash uploads in crashReporter. #23598

End of Support for 7.x.y​

Electron 7.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 11.0.0 schedule maps out key dates in the Electron 11.0 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Continued Work for Deprecation of remote Module (in Electron 11)​

We started work to remove the remote module in Electron 9 and we're continuing plans to remove the remote module. In Electron 11, we plan to continue refactor work for implementing WeakRef as we have done in Electron 10. Please read and follow this issue for full plans and details for deprecation.

Final Step for Requiring Native Node Modules to be Context Aware or N-API (in Electron 12)​

Edit: Originally, this blog post stated that we would disable renderer process reuse in Electron 11. Disabling renderer process reuse has now been pushed to Electron 12.

From Electron 6 onwards, we've been laying the groundwork to require native Node modules loaded in the renderer process to be either N-API or Context Aware. Enforcing this change allows for stronger security, faster performance, and reduced maintenance workload. The final step of this plan is to remove the ability to disable render process reuse in Electron 12. Read this issue for full details including the proposed timeline.