Hey, thanks for the reply. No, I don't want to add a GUI. The App already has a tkinter GUI and works (at least on Apple SIlicon). It's completely compiled (by PyInstaller) and I can run it by going to the folder in the terminal an running ./name_of_the binary. However, if I just double-click it (or right-click it and select open) a terminal window will open raising some file or directory not found errors due to this issue. That's the one issue that could by solved by using the AppKit (or better pyobjc). The other one is, that I would need to notarize a lot of binaries after compiling. If I send complied project to someone via Internet (or even AIrDrop) I get Gatekeeper warnings for the binary itself and most of the compiled Python modules. I stopped allowing them after the around eights warning. If I just transfer via external storage, I can run the app without any of these warnings. So, that's the other isse and I want to get a better understanding on developing macOS apps in general. AFAIU I can only solve this by notarzing every of the binaries that are created by PyInstaller and I am not sure, if PyInstaller can do this by itself. I guess, I would have to do this with Xcode (or it's command-line tools). You see, these are all quite Apple specific requirements which to my understanding are quite global for macOS app design (and I guess my understanding of these is not 100% correct). So I just want to get a better understanding on the general structure of macOS apps and their distribution. And Xcode in general since it seems like this is a pivotal tool for App development and distribution (see https://haim.dev/posts/2020-08-08-python-macos-app). A bonus would be to build a C++ project (that I use inside the app) for arm64 and x86_64, which I already did by make and make in an àrch -x86_64 zshenvironment.liposhows the correct architecture, but thex86_64binary does not work for some reason. Also, it would be great to make and combinedarm64/x86_64` binary, which I only found solutions on the Xcode GUI, but not command line tools. You see, there is a lot of new understanding. wording and knowledge to acquire for me and that's why I would like a nice tutorial to have a good point, where to start :). I'll give your link a look and check how much it's gonna help me with my specific issues. Thanks for that.

Hey @eskimo and @petered, This thread's been closed for half a year now, but I am having the exact same problem and I can't seem to find the solution. I have a Python app that I ported to macOS and compiled (or froze) using PyInstaller. I am using a lot of custom submodules that don't get imported correctly using the PyInstaller algorithm, but I found a workaround. It's not a perfect solution, but it works for the arm64 version. So here's my general process. I make the .app file using PyInstaller. <-- App working for arm64 and x86_64. I create an .dmg file from this, codesign it and sent it to notarization. <-- App working for arm64 and x86_64. The binaries that are not correctly signed I resign using a script and then I sign the complete .app again. <-- After resigning the x86_64 version stops working (with the above error message). The arm64 still works great. After resigning I create a new .dmg file, codesign it and sent it to notarization, which is accepeted (for arm64 and x86_64). <-- The arm64 version is correctly executable, but the x86_64 version does not start resp. throws the libffi error, if executed via zsh. I did this using my M1pro and an older Macbook Air with Intel CPU and macOS 11.7.6. Even if using the machine the app won't start after resigning. I am running out of ideas. Where is the difference here between arm64 and x86_64. Any ideas left?

I stumbled across this bug report: https://bugs.python.org/issue46975 I have indeed brew x86_64 (and arm64) installed and it seems that this somehow interferes. make --version generates this output: GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. ... This program built for i386-apple-darwin11.3.0 shouldn't it be arm64-apple-darwin11.3.0? And is there a way to just use the make from macOS and ignore all the other stuff from brew?

It seems that make (which is the correct make) uses the gettext library from brew. I could uninstall this, but a lot of other packages depend on it. Is there a way to make make ignore this library?

TL;DR I just found this thread and have a similar issue: Sometimes I run my pipeline two times in parallel (once for arm64 and once for x86_64) on the same machine and then I get this error (xcrun notarytool submit ***.dmg --keychain-profile "org.***.***" --wait -> Error: No Keychain password item found for profile: org.***.***) for one of the pipelines. If I just rerun xcrun notarytool submit ***.dmg --keychain-profile "org.***.***" --wait, it works fine. Is this known issue, if you use the same --keychain-profile multiple times at the same time?

I run it as a direct queue of commands linked with && in the terminal. Up to now the error only happened if I run both in parallel: Terminal 1 (works almost always): mkdir arm64 && \ cd arm64 && \ source ~/venv/arm64/3_9/appName/bin/activate && \ (PyInstaller) 2> pyinstaller_arm64.log && \ deactivate && \ rm -rf build appName.spec dist/appName && \ mv dist appName && \ hdiutil create -srcFolder appName appName_arm64.dmg && \ codesign -s "***" --timestamp -i "org.appName.appName" appName_arm64.dmg && \ xcrun notarytool submit appName_arm64.dmg --keychain-profile "org.appName.appName" --wait > notarytool_arm64.log && \ xcrun stapler staple appName_arm64.dmg > stapler_arm64.log Terminal 2 (sometimes raises the error notarytool: No Keychain password item found for profile. Almost always works on 2nd try, if the 1st fails): arch -x86_64 zsh mkdir x86_64 && \ cd x86_64 && \ source ~/venv/x86_64/3_9/appName/bin/activate && \ (PyInstaller) 2> pyinstaller_x86_64.log && \ deactivate && \ rm -rf build appName.spec dist/appName && \ mv dist appName && \ hdiutil create -srcFolder appName appName_x86_64.dmg && \ codesign -s "***" --timestamp -i "org.appName.appName" appName_x86_64.dmg && \ xcrun notarytool submit appName_x86_64.dmg --keychain-profile "org.appName.appName" --wait > notarytool_x86_64.log && \ xcrun stapler staple appName_x86_64.dmg > stapler_x86_64.log

Looks like A timestamp was expected but was not found was just a temporary error.

I can confirm that the reason it did not work anymore (macOS, arm64), was due to Xcode 15. I downloaded Xcode 14.3.1 from here (https://download.developer.apple.com/Developer_Tools/Xcode_14.3.1/Xcode_14.3.1.xip), unzipped it, renamed Xcode.app to Xcode_14.3.1.app (to be able to have both versions in parallel), copied it to /Applications and started it. After that I set the command line tools to 14.3.1 (Settings -> Locations; there are also other ways like xcode-select -s and also ways with command line tools only) and just installed PyQt5 using this command: pip install pyqt5 --config-settings --confirm-license= --verbose. I can confirm that building PyQt5 from source works again (this still needs qmake from brew or from qt.io), so there is an incompatibility with some of the contents of Xcode 15. I'll try to find out, which one this is exactly.

I also needed to revert back to Xcode 14.3.1 for building PyQt5 (different project, but might be related). See here: https://developer.apple.com/forums/thread/737863?page=1#765824022

I have a little report here: The libffi error originates from sklearn, I assume and I could indeed get rid of the libffi error by switching from conda to the distribution von Python.org. However, also here I run into a similar error, when trying to run the executable (slightly changed since the original error and not an .app file, but just an executable): rosetta error: unable to mmap __TEXT: 1 /var/db/oah/.../.../libomp.dylib.aotzsh: abort PYTORCH_ENABLE_MPS_FALLBACK=1 ./diarize_x86_64 mps AFAIK libomp is from OpenMP, which I thought macOS does not support anymore. It's weird that it's used (I guess) by PyTorch (and also seems to work for arm64). I can't find anything about trusted execution in the system.log and the crash report is very long. Any hints what to look for? The log from the notarytool came back without any warnings. { "logFormatVersion": 1, "jobId": "<omitted>", "status": "Accepted", "statusSummary": "Ready for distribution", "statusCode": 0, "archiveFilename": "diarize_x86_64.dmg", "uploadDate": "2023-09-30T18:53:04.957Z", "sha256": "<omitted>", "ticketContents": [ { "path": "diarize_x86_64.dmg", "digestAlgorithm": "SHA-256", "cdhash": "<omitted>" }, { "path": "diarize_x86_64.dmg/diarize_x86_64", "digestAlgorithm": "SHA-256", "cdhash": "<omitted>", "arch": "x86_64" } ], "issues": null }

I am also running Sonoma (though I configured it using Ventura). It might still work. Just download Xcode 14.3.1 (https://download.developer.apple.com/Developer_Tools/Xcode_14.3.1/Xcode_14.3.1.xip) Unzip it, rename Xcode.app to Xcode_14.3.1.app and move it to /Applications. Execute sudo xcode-select -s /Applications/Xcode_14.3.1.app/Contents/Developer. Not 100% sure, this will work, but it could.