Changelog
io.Connect Desktop 10.0.3
Release date: 16.01.2026
| Components | Version |
|---|---|
| Electron | 39.2.3 |
| Chromium | 142.0.7444.175 |
| Node.js | 22.21.1 |
New Features
Multiple Local & Remote System Configuration Sources
The system settings for io.Connect Desktop can now be retrieved from multiple local and remote configuration sources. Each source can be assigned priority and the final system configuration will be the result of merging all available configuration sources.
It's possible to use custom configuration files from remote sources. There are also certain limitations that you must take into account regarding some of the system configuration properties.
To define system configuration sources, use the
"sources"property of the"systemConfigurations"top-level key. The"sources"property accepts an array of objects each describing a local or a remote configuration source.The following example demonstrates how to define additional local and remote system configuration sources:
{ "systemConfigurations": { // All additional system configurations will be merged with the local `system.json` file based on priority. "sources": [ { // The default local configuration source. "type": "path", "source": "./config", "configs": "*", "priority": 1, "required": true }, { // Additional local configuration source. "type": "path", "source": "%IO_CD_ROOT_DIR%/my-configs", "priority": 5, // If this source isn't available, the platform will throw a system error and won't initialize. "required": true }, { // Additional remote configuration source. "type": "rest", "source": "https://my-remote-store/", // This source has higher priority than the local source and the property values defined in it // will take precedence when merging all available configurations. "priority": 10 } ] } }ℹ️ For more details on defining local and remote configuration sources, on using custom configuration files, and on the related limitations, see the Developers > Configuration > System > Multiple Local & Remote Configuration Sources section.
Custom Environment Variables
To define custom environment variables, you can now use the
"set"property of the"envVars"top-level key in thesystem.jsonfile. It accepts an object with key/value pairs holding the names and the values of the environment variables to register.Environment variables can also be defined in multiple local and remote configuration sources. The variables specified in the configuration source with the highest priority will override the values of the variables with the same names in all other lower priority configuration files.
The following example demonstrates registering environment variables that hold different app URLs for the different environments and regions in which the app will run:
{ "envVars": { "set": { "MY_APP_PROD": "https://my-app.com", "MY_APP_DEV": "https://dev.my-app.com" } } }Using the custom environment variables in an app definition:
{ "name":"my-app", "title":"My App", "icon": "%MY_APP_PROD%/icon.ico", "type": "window", "details":{ "url":"%MY_APP_DEV%/index.html" } }To clear the value of an environment variable, set it to an empty string:
// In system configuration file with higher priority. { "envVars": { "set": { // This will override the value of an existing environment variable with the same name in a lower priority configuration file, // or will set a new environment variable with an empty string as a value. "MY_EMPTY_VAR": "" } } }
Workspaces App Dialog Blur
⚠️ Note that this feature is available only in the advanced platform mode.
To instruct the Workspaces App to blur the area around a dialog it has displayed, use the
blurproperty of theFrameDialogOptionsobject:const myDialog = { type: "SingleInputDialog", title: "Email Required", message: "Please, provide your email address:", inputPlaceholder: "john.doe@example.com", inputPattern: "[a-z0-9]@my-org.com", inputPatternErrorMessage: "Invalid email address!", blur: true }; await myFrame.showDialog(myDialog);You can use the
--workspace-dialog-backdrop-backgrounddedicated CSS variable to control the blur effect parameters.
Persisting Window Zoom
io.Connect Desktop 9.10 introduced the ability to set independent zoom factors for same-origin web apps. However, in this zoom mode, the current zoom factors of web app instances were neither persisted on window refresh or on platform restart, nor saved in Global Layouts or Workspaces.
Now, the current zoom factors of web app instances are automatically persisted by the platform when the default zoom behavior is set globally to
"window"via thesystem.jsonsystem configuration file of io.Connect Desktop or per app via the app definition:{ "windows": { "zoom": { "enabled": true, "mode": "window" } } }The current zoom factors of all web app instances are persisted and restored automatically when:
- the window is refreshed;
- the platform is restarted;
- the window is saved in a Global Layout or in a Workspace;
Each new instance of the same web app will have the last persisted zoom factor for that app. For example, if there are two running instances of the same app and the user sets the zoom factor of the first one to 125, then sets the zoom factor of the second one to 150, the third started instance of that app will have a zoom factor of 150.
Trusted App Stores
When fetching FDC3 app definitions from public FDC3 App Directory stores, io.Connect Desktop automatically converts the FDC3 app definitions to io.Connect app definitions and overrides all security settings specified in the FDC3 app definitions with the security settings specified in the
system.jsonsystem configuration file of io.Connect Desktop. This is a default platform security mechanism which ensures that unknown apps from public FDC3 App Directory stores won't be able to override the security settings of the underlying Electron app.While FDC3 app definitions are usually stored in such public FDC3 App Directory stores, you may also decide to store them in one of the supported io.Connect app stores. If this is the case, you can prevent overriding the security settings specified in your FDC3 app definitions by configuring the respective io.Connect store as trusted.
The following example demonstrates configuring a local app store as trusted:
{ "appStores": [ { "type": "path", "details": { "path": "./config/apps", // The app store will be considered trusted by the platform and any security settings // you may have specified in FDC3 app definitions won't be automatically overridden. "trusted": true } } ] }
Improvements & Bug Fixes
Reduced the file path lengths in the platform bundle where possible in order to avoid potential errors during client deployments due to the restriction on Windows for a maximum of 256-character path string. The longest path in the io.Connect Desktop installation is 91 characters. You should consider this when deciding on a location for the installation bundle when using a bundle deployment, or if you decide to move the default installation folder to a new location when using an installer.
Improved internal handling of the default tray icon on Windows.
Fixed an issue related to importing Layouts from local file stores.
Fixed an issue related to setting the current working directory when in advanced mode.
Fixed an issue related to sending crash reports via the Feedback form where the platform would shutdown when running in advanced mode and the crash file is missing.