ej-technologies - What's new in install4j 10.0

install4j now supports Windows on ARM. In addition to the 32-bit and 64-bit x86 architectures, you can choose the arm64 architecture on the "Installer options" step of the Windows media wizard. With native ARM support, your application will run much more quickly than as an x86 binary in the emulated mode.

Both the installer as well as the generated launchers will be native arm64 executables in that case and will require a JRE with the windows-aarch64 architecture. The Zulu and Liberica JDK providers contain such builds for recent Java releases.

Also, installers will find installed Microsoft JREs on Windows ARM machines if no JRE is bundled.

It is now possible to submit apps to the Apple App Store with install4j. The macOS single bundle archive type can be configured to create a ".pkg for App Store submission". A provisioning profile has to be specified that is created in App Store Connect.

An app that is submitted to the App Store must fulfill a number of requirements and pass a review process by Apple. In the launcher, you can configure a number of properties that are relevant for this purpose. A custom bundle identifier must be set to match the identifier in the Apple Developer Account configuration, and the application category is required for an App Store submission. In addition, your app may require entitlements such as the right to read and write user-selectable files. This is done in an entitlements file. The sandbox is switched on automatically by install4j.

install4j will build a .pkg file that you can test locally to check the effects of the sandbox and your entitlements. The .pkg file is then uploaded with the Transporter app or Xcode command line tools. A dedicated chapter has been added in the documentation that deals with Apple App Store submission.

Support for adding Windows firewall rules has been added. You can add one or multiple "Add a Windows firewall rule" actions to your installer to allow incoming or outgoing connections through the built-in Windows firewall.

Each firewall rule applies to a selected launcher and handles either incoming or outgoing connections. Because firewall rules are shown in the Windows management console, they need a rule name and optionally a rule group as well as a detailed description.

The properties of the action mirror the available settings when editing firewall rules in the Windows management console. By default, any ports and IP addresses can be used on both local and remote side, but you can optionally restrict them for a more secure configuration. Windows offers different profiles for network connections that determine the security of the connection. Rules can be created in selected profiles only.

As recommended by Microsoft, rules are not created for the public profile by default. If you really want to include it, consider selecting the "Avoid public profile" child property. In that case, the public profile is only included if it is the only profile that is currently active.

Undo/Redo functionality has been added for all modifications in the install4j IDE. The corresponding tool bar buttons show the description of the last item in their tool tips. Clicking on the main area of these buttons will undo or redo the last edit.

Clicking on the drop-down arrow on the right side of the undo/redo tool bar buttons, will bring up a list of undoable or redoable items. By clicking on an item you can undo or redo all items up to the selected item.

Modifications that were performed in modal dialogs such as the launcher wizard or the media wizard show as one atomic item. In the form component configuration dialog there are separate undo/redo buttons for the life cycle of the current dialog.

Default values for properties of installer applications, screens, actions and form components are now supported in the install4j IDE. If you change a property from its default value, a star-shaped marker in the gutter will indicate the non-default status of the property.

The context menu of properties contains a menu item to reset the selected property to its default value. This will also revert the text input mode if it was set for the property.

File associations and URL handlers for macOS are now configured for each launcher. Starting with ARM-based macOS machines, the Info.plist files of launchers cannot be modified at runtime without breaking the signature, so all content must be generated at compile time.

This means that it is not possible to conditionally add file associations or URL handlers at runtime anymore. In earlier versions of install4j, the related behavior was different for Intel and ARM-based macOS machines, which was inconsistent.

To provide a way of configuring this information, the "Executable info → macOS options" step of the launcher wizard now contains a list of file associations and URL handler definitions that are translated into the corresponding entries of the Info.plist file of the installer. Previously, archives would process the definitions of selected "Create a file association" and the "Register a URL handler" actions in the "Installer → Screens & actions" section.

You can either add a file association or a URL handler. A file association is defined by its extension, a description and an optional icon file. The role indicates whether the application just displays files or also edits their content.

The URL handler is defined by the URL scheme, so for a scheme of "hello" it handles requests in the browser that start with "hello://".

The "Create a file association" and the "Register a URL handler" actions now only work for Windows and Linux. If you open projects that were saved with previous versions of install4j, the information from these actions is migrated into the new settings for macOS in the launcher wizard.

A global single instance mode has been added for generated launchers. Previously, single instance mode was always per-user, so two different users could each start an instance of the application. The new single instance mode settings have been moved to a separate step in the launcher wizard.

In addition, single instance mode has previously always been per session in Windows. The same user can run multiple RDP sessions to a remote machine, and single instance mode should be able to cover all such sessions if desired. To do that, you can deselect the "Per session on Windows" check box.

Startup notifications through the com.install4j.api.launcher.StartupNotification API are only delivered if the same user in the same UI session starts the application again.

The icon compiler can now create ICNS icons with Retina images. Image files whose file names end with @2x.png and are located next to the configured image files are picked up automatically by the icon compiler.

External launchers can now have additional desktop entries. These entries are written to the .desktop files that are created for the integration into Linux desktop environments. In archives, the .desktop files are included statically while installers use the "Create program group" action to create the .desktop files at runtime.

Unix file modes can be preserved from the source files in the distribution tree. If you prepare files and directories with the desired Unix access modes on a Linux or macOS machine, install4j can now optionally pick up this information instead of using the default file modes.

Overridden file modes that are defined for single entries in the distribution tree still take precedence over the detected file modes.

Headless JRE detection has been added for Linux/Unix. This is relevant if you do not bundle a JRE. The JRE search sequence is now aware whether an installed JRE is headless or not. This solves three problems:

If the installer should how a UI, headless JREs should be ignored and a non-headless JRE installation should be preferred
If only a headless JRE is available, the installer will fall back to console mode instead of failing to show a UI
Due to the internal screen model, installers require a working AWT subsystem. If only a headless JRE is available, the installer will now operate correctly in the AWT headless mode

The development experience for background updaters has been improved.

The complete cycle for a background updater spans 5 processes. Starting from the invoking launcher, an update downloader is invoked. The update downloader schedules the invocation of the update installer. The next launcher invocation starts the update installer which then terminates the calling launcher and restarts it again after the completion of the update.

If anything goes wrong in this chain of events, it was difficult to get logging information with previous versions of install4j. Especially when setting up the auto-update process for the first time, some settings may be misconfigured or files may not be in the expected location. install4j 10 adds unified logging for background updates. If you start your launcher with the VM parameter

-Dinstall4j.updateLog=true

a cross-process log file will be created in the updater cache directory that contains logging for important events as well as error messages that will help you pinpoint the cause of a malfunction.

The updater cache directory has a platform-specific location:

Windows: %LOCALAPPDATA%/install4j/update
macOS: $HOME/Library/Caches/install4j/update
Linux/Unix: $XDG_CACHE_HOME/install4j/update or $HOME/.cache/install4j/update if XDG_CACHE_HOME is undefined

Individual updaters store their data under two levels of directories with hash names of application ID and installation directory. You can easily find the current updater by locating the most recently modified directories.

While setting up the auto update process, you may want to perform several updates in a row for testing or debugging purposes. Because the inhibition time for auto updates is set to 24 hours, this was not possible before. Starting with install4j 10, the "Schedule update installation" action has a "Retry inhibition in minutes" property that can be reduced appropriately.

Finally, the documentation for auto-update functionality and background downloaders has been improved with more background information and trouble-shooting assistance.

Access right modifications on Windows have been improved. The "Change Windows file rights" action now has an "Access mode" property that can be configured to grant, set, deny or revoke access.

While previously you could only grant additional rights, you now have a complete set of tools at your disposal to modify access rights of installed files and directories.

Hyperlink labels can now be styled. This affects the "Hyperlink URL label" and the "Hyperlink action label" form components. Both font as well as font colors in the passive and active states of the link label can now be configured.

These properties are in the "Hyperlink label" property section which is different from the "Label" property section for the optional leading label that you can set for most form components.

The "Read text from file" action can now save lines to a string array. This is useful if the contents of a file should directly be used as the input of another action or form component.

For example, a "Drop-down list" form component expands the array value into separate items.

The "Stop a service" action now has a configurable timeout. In some cases, the default timeout of 30 seconds was too short and the action could fail prematurely.

It is now easier to find elements with comments. Installer applications, screens, actions and form components that have comments now show an overlaid badge at the bottom right of their icon.

Apart from the new comment indicator, moving between comments is facilitated by the "Show next comment" and "Show previous comment" actions.

Editing VM parameters has been improved. Text fields that hold VM parameters now have an edit button to their right that brings up a separate dialog.

In this case, VM parameters are not split into separate lines as it is done for other properties that hold sequences of values or the .vmoptions files where each VM parameter is on a separate line. This is because quoting is not resolved at this point, and compiler or installer variables can inject unquoted sequences of VM parameters. As a result, the dialog soft-breaks the VM parameters with spaces as a delimiter so you can see the entire line at once.

In addition, it is now easier to spot version-specific VM parameter configurations. In the "Java invocation step" of the launcher wizard, the number of version-specific VM parameters is displayed next to the button that shows the configuration UI.

Version-specific VM parameters are defined as pairs of Java version expressions and corresponding VM parameters. The cell editor for the VM parameters in the table also has a button that shows the separate dialog for editing VM parameters.

install4j now supports live switching between light and dark mode in the IDE. When the OS theme changes, install4j will switch automatically. In the general settings, it is also possible to select a fixed theme. Previously, live theme switching was only supported for installers.

The documentation is now available in dark mode. The default theme follows the OS theme and can be switched manually in the top right corner.