macOS build and publish from Windows

cyberfly

macOS build and publish from Windows do not run on macOS. I have tried transferring both the build and the published versions to macOS Apple Silicon and neither worked. I'm used to doing this with my Xojo applications which I don't have problem with. My primary development machine is Windows 11 and I test the macOS versions on Host My Apple. My Windows and Linux version worked fine.

mischte

I also use Objo running under Windows (VM) because I only have an Intel Mac.
building Mac X64 worked - the only thing what to do is to set it the execute flag in the Mac App (show package,... contents..MacOS... the executable).
Then chmod +x executable.
Whitout that the app can't be started, Mac OS complains .
Pic shows the example build of Print10 ... after chmod +x Tenprint. Icon gets black(=executable) before chmod +x it was white icon= not an executable = not startable.

cyberfly

All I get still is the following window.

Garry

Thanks for reporting this. I’ve investigated the build/publish process and confirmed a bug that could explain what you’re seeing.

The generated Mac executable can be left with an invalid local code signature when prepared on Windows. In my tests of that packaging path, macOS prevented the Apple Silicon application from starting even with the correct executable permissions. Re-signing the test application allowed both Build and Publish output to run successfully.

The chmod +x suggestion addresses a separate permission issue. For published applications, transferring the generated .app.tar.gz and extracting it on the Mac preserves those permissions, although the signing bug can still prevent launch.

I’ve logged the bug here, including the investigation findings and a detailed fix plan. I’ll update this thread when a fix is available. This local signature requirement is separate from Developer ID signing and notarisation for distribution.

Could you confirm which Studio version you’re using, and whether you transferred the .app.tar.gz or the loose .app bundle? The screenshot is generic, so those details will help confirm whether your application is hitting the same problem.

cyberfly

I have just found that I had to do a chmod -R +x as well as do an ad-hoc code sign to get it to work. I transferred the .app.tar.gz and the loose .app bundle. Both needed the chmod -R +x as well as do an ad-hoc code sign to get them to work. For now I have a script to do this in my terminal. In case someone wants the script here it is.

signapp() {
target="${1:-.}"
chmod -R +x "$target"
xattr -cr "$target"
codesign --force --deep -s - "$target"
echo "Permissions set, quarantine cleared, and signed: $target"
}

Garry

Thanks, that was helpful. I’ve reproduced and fixed a signing bug affecting macOS apps built or published from Windows. Packaging was changing the executable without refreshing its signature, so macOS could reject it even after its execute permission was restored.

I’ve tested the fix by generating apps on Windows and running them on an Apple Silicon Mac. The apps extracted from Publish’s .app.tar.gz opened without chmod, re-signing, or clearing extended attributes in those tests.

The fix will be in the next release. You can follow it here on Feedback.

I recommend transferring the .app.tar.gz unchanged and extracting it on the Mac to preserve permissions. Loose Build bundles may still need the main executable’s execute permission restored after transfer. The automatic ad-hoc signature supports local testing; downloaded apps can still encounter Gatekeeper restrictions. Developer ID signing and notarisation for public distribution remain separate steps requiring a Mac.

cyberfly

Great, Thanks!