Automation sandboxing in macOS 10.14

macOS 10.14 introducesĀ  automation sandboxing as part of a new push for security. This change impacts installers generated with install4j prior to 7.0.8, because they use AppleScript to perform a variety of tasks. The authorization dialogs from the new sandboxing mechanims are undesirable for an installer and once a permission is denied it is difficult to reauthorize it.

To solve this problem, nearly all affected operations have been re-implemented as native code in install4j 7.0.8. As part of this work we have fixed a long-standing issue on macOS: When requesting elevated privileges, the password dialog notified the user that “install4j” wants to make changes.

However, users most likely do not know the name “install4j” and could be tempted to cancel the dialog. Starting with install4j 7.0.8, the full name that is configured in your project is displayed instead:



    Do I understand correctly that for a standard user (who has only permission to read, not to write) it’s still impossible to install an update? Installation action requires a write permission which is not granted to a standard use on Mac, thus install4j cannot elevate to a write permission by itself. Am I right?

    In my company we’re currently using install4j 5.1 and thinking of upgrading to 7. It looks like there’s no magic into granting a write permission on Mac OS šŸ˜€

      Ingo Kegel

      You either have to add a “Request privileges” action to the installer or choose to install into the home directory where write permissions are always available.


Post a comment