Hi Quinn! Thanks a lot, this gives me the correct hint to go a step further! My App Store provisioning profile did not contain any certificate at all. So now I can archive may app in Xcode and distribute it: Custom > App Store Connect > Export > Manually manage signing > Distribution certificate: Mac App Distribution Installer certificate: Mac Installer Distribution frogSIP.app: frogSIP Mac App Store Connect (the fixed provisioning profile) This gives me a pkg installer. I now extract the app package from the installer, because I have to do further deployment for my Qt app package. Then the app package is deployed and code signed with Qt tool macdeployqt6 and certificate "3rd Party Mac Developer Application“. The pkg installer is build with productbuild and signed with certificate ""3rd Party Mac Developer Installer“. Finally uploaded the pkg with xcrun altool. Puh ... the old error [Missing code-signing certificate.] is fixed. But ... *** Error: ERROR: [ContentDelivery.Uploader] Validation failed (409) Invalid bundle. The executable couldn’t be re-signed for upload to App Store Connect. The app may have been built or signed with unsupported or prerelease tools. (ID: e43b0690-efd9-402d-a7c8-9fde27199a7c) *** Error: ERROR: [ContentDelivery.Uploader] Validation failed (409) Invalid Bundle. The application bundle may not contain tools or frameworks provided by Apple, or using bundle identifiers in the 'com.apple.' namespace. Invalid bundle: [com.frogblue.frogCom.pkg/Payload/frogSIP.app/Contents/Resources/qml/QtCore/libqtqmlcoreplugin.dylib.dSYM], with bundle identifier 'com.apple.xcode.dsym.qtqmlcoreplugin'. (ID: b0c9769c-9813-4674-9db5-226321dfc2c8) Guess this is related to the Qt Resources and Plugins structure which are added to the app package. I can’t see the reason for a ‚com.apple.xcode.dsym.qtqmlcoreplugin‘ bundle identifier. Any idea how to correctly manage a Mac App Store upload for Qt applications? Should I prefer static linking Qt libraries or how to correctly add Qt Frameworks, Resources and Plugins? Thank you in advance Dietmar

Hello folks! We ended up running into the same problem. We ported an existing VoIP SIP stack to watchOS and were happy that we progressed so quickly. The initial feasibility study was passed. The stack runs on simulator and could register with our SIP server and accept incoming calls. PushKit and CallKit integration functional! Very frustrated we now have to realize that with the information from TN3135 we can actually stop the project. The VoIP SIP stack (baresip) is heavily intertwined with the use of TPC/UDP/RTP sockets. The effort to change the communication to the low-level Network Framework makes no economic sense. Even more frustrating was the fact that the BSD headers are included in the WatchOS SDK. Without this, we would certainly have encountered the problem much earlier. We wouldn't have been able to compile the SIP stack in the first place. Is there still a small chance that Apple will change its policy in the future? A frustrated developer Dietmar