Resolving LOGO! Soft Comfort V9 macOS Installation

Extract the installer in Terminal, confirm that Gatekeeper identifies the bundle as an unnotarized Siemens Developer ID application, remove the bundle’s quarantine attributes, and launch it directly. Do not depend on spctl --add: newer macOS releases can return This operation is no longer supported., and disabling Gatekeeper globally creates an unnecessary system-wide exception.

Symptom Classification

The affected package is the LOGO_Soft_Comfort_V9 Mac_aarch64 build. Two failures can occur in sequence: Finder-based archive tools fail to extract setup.zip, and a successfully extracted Setup.app fails during process creation.

The Intel Mac build was not tested in this installation. Diagnose it with the same assessment command instead of transferring the Apple Silicon result to that build.

Gatekeeper and Notarization Mechanism

Code signing identifies the signer and detects changes to signed content. Notarization is a separate Apple service and policy result. The term quarantine here means extended metadata attached to downloaded content that causes macOS to subject the application to its normal first-launch security assessment.

The affected bundle is signed by Siemens AG with Developer ID 65J23SE987, but its assessment reports source=Unnotarized Developer ID. On the affected Apple Silicon installation, Gatekeeper stops launchd from spawning the application. That produces the reported RBSRequestErrorDomain Code=5 and underlying Code=111 messages rather than the more recognizable unidentified-developer dialog.

Removing quarantine attributes changes how this local copy enters the launch assessment path; it does not notarize the bundle, replace its signature, or correct the distributed package. A Siemens-supplied package submitted successfully for Apple notarization is the permanent correction.

Remediation Decision Path

Use the workaround only when the assessment output matches the known condition. A different rejection reason requires a different investigation. In particular, do not treat every Code=111 occurrence as proof of missing notarization.

Corrected Installation Procedure

1. Open Terminal and change to the installer’s Mac_aarch64/VM directory. The command must run from the directory containing setup.zip, or the archive and destination paths must be adjusted explicitly.

2. Extract the archive:

   unzip -o setup.zip -d extracted

   The -o option overwrites same-named files in an existing extracted directory. Use it only when replacing that prior extraction is intentional.

3. Assess the extracted application before changing its attributes:

   spctl -a -vv extracted/Setup.app

   Proceed only when the result identifies the known combination: rejected, source=Unnotarized Developer ID, and the expected Siemens AG signing identity.

4. Remove quarantine and related extended attributes recursively from this application bundle:

   sudo xattr -cr extracted/Setup.app

   Enter the macOS administrator password when prompted. Scope the command to extracted/Setup.app; do not aim a recursive attribute-removal command at the Downloads directory or another broad path.

5. Launch the local bundle:

   open extracted/Setup.app

6. If macOS still blocks the launch, use the Mac’s managed security-approval path or obtain a notarized installer. Do not escalate to a global Gatekeeper disablement.

Verification Checks

1. Check 1: archive extraction. Expect the destination to contain extracted/Setup.app. If it does not, resolve the archive path or extraction error before investigating Gatekeeper.

2. Check 2: pre-remediation assessment. Expect spctl -a -vv extracted/Setup.app to report rejected and source=Unnotarized Developer ID for this known packaging problem.

3. Check 3: signer identity. Expect the application to identify Siemens AG and Developer ID 65J23SE987. An unexpected identity is a stop condition, not a reason to remove security metadata.

4. Check 4: process creation. After running open extracted/Setup.app, expect the installer interface to appear without RBSRequestErrorDomain Code=5, underlying Code=111, or Launchd job spawn failed.

5. Check 5: permanent package correction. When Siemens supplies a replacement, extract a fresh copy and assess it before applying any workaround. Expect the new package to pass Gatekeeper without quarantine removal or a local exception.

Recurring Security and Diagnostic Pitfalls

Running sudo spctl --add extracted/Setup.app is not a portable fix across macOS releases. The reported response This operation is no longer supported. means the operating system no longer accepts that policy-list operation; it does not mean the password was wrong or that Setup.app is absent.

Using sudo spctl --master-disable changes Gatekeeper policy for the whole Mac. That action is disproportionate to a single unnotarized application, expands exposure beyond the installer, and can conflict with managed security controls. Keep any exception limited to the inspected application bundle.

Another wrong practice is clearing attributes before recording the assessment. That destroys the most useful diagnostic distinction: an unnotarized but expected signer versus a package with a different trust failure. Retain the initial spctl output with installation records.

Repeatedly downloading or changing GUI extraction utilities will not correct notarization. Treat extraction and launch as separate gates: first produce an intact Setup.app, then diagnose its security assessment. Likewise, a successful local launch does not repair the vendor package for other Macs; each downloaded copy remains subject to its own security metadata and system policy.

FAQ