“missing package product”

Apple sometimes is really strange... I tried to find a solution 2 or 3 days, and missed out this thread. Product name is the answer. Use english in product name, problem will solved. Thanks to chungchung1315.

You archive a dynamic library using the standard process, so Product > Archive, but you’re correct that you can’t distribute a dynamic library from Xcode. Most of the time that doesn’t matter because you don’t need to sign and notarise a dynamic library. Rather, someone who uses your dynamic library in their product is expected to sign and notarise it as part of their distribution processing. In some cases it is necessary to do this, for example, when you’re creating a plug-in for some other app. In such situations you must manually sign, package, and notarise your product. For advice on how to do that, see: Creating Distribution-Signed Code for Mac Packaging Mac Software for Distribution Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

@JetForMe I faced same issue today on Xcode 13.1, checking raw project file format and there is Products group and entires exists. However, the project file is missing Frameworks group, and after I added dummy Framework linking in that product target to create Frameworks group, then Products reappears again. (After restore it, I can remove dummy Framework linking and that dummy Framework reference in Frameworks group without losing Products group in Project tree.) I don't know if you can fix your project file in same way, but just I want to share this very weird Xcode behaviors.

I'm working with a number of multi-platform apps that have local packages, and sometimes have your problem because I'd forgotten key steps. For each Target (platform), build the Library (package) before building the main product of that target (e.g. MacOS). You will probably have to rebuild the Library (package) after any Clean Build Folder. For each target, at the General tab of the Target explorer, make sure you've included the library (package output) in the Frameworks, Libraries and Embedded Content. Each target needs to have the Library specified, not just once at the project level. I've had problems with local packages when I've included the source(s) in my app's project, rather than having the package in a separate directory and included in the app project. Best wishes and regards, Michaela

Thanks for the reply Rich.To make sure this works on production, we uploaded the production AppStore signed build to testflight this morning and we are still seeing this error.Are AppStore signed builds on test flight considered *real* production AppStore builds? Is there something that we might be missing?Thanks

For more up-to-date advice on how to sign and package Mac products, for both the Mac App Store and independent distribution using Developer ID, see: Creating Distribution-Signed Code for Mac Packaging Mac Software for Distribution Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Sorry, I'm not clear on the sequence of events - I thought you had reinstalled from beta 1, then updated to 2 and then to 3 today after realising that you were missing core components of your OS.To reinstall beta 3 over itelf, just download from this link and install the .pkg file:http://swcdn.apple.com/content/downloads/45/55/031-27723/jfp6s17zwamp7zr7iwmkmdigzudq3fd72e/OSXUpd10.11.pkg

However, Gatekeeper is not letting direct installation. Can you clarify why you mean by that? Does Gatekeeper prevent you from opening the installer package? Did you notarise and staple that package? ps We generally recommend that you sign everything from the inside out and then only notarise your outermost container (in this case your installer package). For more hints on this topic, see Signing a Mac Product For Distribution - https://forums.developer.apple.com/thread/128166. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @apple.com

Thank you for your inputs.What bothers us with notarization requirements is that there is no way to test it.You know, testing is fail first, understand the why, then fix.We did put our product on macOS 10.14.5 beta and public release, and we though we were be able to fail there, but we never experienced a failure to demonstrate that notarization helped us to fix it in order to have it run.Implementing notarization in our context represents some kind of work, as we currently build and package our bundles with a build agent.In order to prioritize the implementation of the notarization process in our automated build workflow, I have to explain the why to my product owner and my stakeholder.Currently the why is only because Apple told us to do it, not because we are able to reproduce the failure on macOS beta software by not doing it.If I follow you clearly on the user testing workflow you are suggesting, we will surely encounter a failure.But that won't be a testing failure in the Gate