We see this problem on the latest OS X version (Catalina 10.15.2 ). We tested it on 2 Mac machines.
Symptoms: The installation process is not launched.
"The application “InstallerName.app” can’t be opened." alert displayed.
However, the same installer works correctly on previous versions of OS X.
We found that this problem caused by wrong permissions on InstallerName.app/Contents/MacOS/InstallerName. The latest OS X version requires the execution permission. Old versions of OS X do not require this permission to run the application.
Fix: unzip the installer manually, add execution permission to that file, zip it again.
We use InstallAnywhere 2018 on the Windows platform to create all installers.
Is there any chance to fix it in IS Anywhere updates?
The same issue happens to installers created with InstallAnywhere 2022 Version: 22.0 Build: 6691. Customers need to give explicit execute permission to the installer app.
The strange part is that all the other files and folders DO have the +x permission.
This permission issue is specific to MAX OSX Catalina version. Fix will be available in InstallAnywhere2021 release.
Workaround provided will make sense because, you are building installer in windows platform and Apple is making codesign and Notarization of any app outside App store mandatory. So app built on windows needs to taken to Mac platform and unzip, codesign and notarization needs to be done manually and then again zip the installer. So until fix is available you need to manage with the workaround.
The same issue happens to installers created with InstallAnywhere 2022 Version: 22.0 Build: 6691. Customers need to give explicit execute permission to the installer app.
The strange part is that all the other files and folders DO have the +x permission.
Well, going deeper into the rabbit hole... It seems the installer is actually creating the zip file WITHOUT any unix permissions. But the signing and Mac OS notarization is setting the DEFAULT unix permissions as: Folder = drwxr-xr-x Files = -rw-r--r--
So we found a solution, just add back the execute permissions on the missing file inside the zip file before signing it, since if unix permissions are already set, the signing will preserve them. but you need to split the zip creation and the signing.
