Hi, thanks for your reply. Just to make few things clear and some follow-up notes.- Stappling the bundle was of no help. The Gatekeeper still refused to allow the bundle to run.- It's the first and the only thing I have ever written for MacOS, so I have no previous experience to mine from. As such, I rely mostly on docs, sample codes and forums.- The linked official fix has a topic/message which is quite far from what I was experiencing. I had Info.plist included and I get no error message, so there was no chance I would ever consider looking into it.- If the docs are not consistent, non-existant or they use too vague language, there is a high change I would follow the version which is not correct.- If the implementations of the same requirement are not consistent across different parts of the same product and its related services, its hard to find the cause. Xcode was happy, macOS loader was happy, Gatekeeper was sometimes happy, notarization were false-happy.- If the docs says the field is optional, has a default value and macOS behaves like that, I expect that all the macOS-related parts and services (I consider the notarization service and the Gatekeeper as a native part of macOS) either follow the same logic or issue clear message if they are more strict. If not, I consider that as a bug, either in docs, in design or in a product.Either way, thanks for your collaboration. It helped me to focus on the right metric (having the overall bundle included in the logs) and to isolate the cause of the issue.

I'm not stappling during these tests. I understand from the docs that stappling is meant mainly for offline purposes, otherwise, online checks are equal to stappling.Edit: I found the reason. Check my last reply to Eskimo. Thanks for your collaboration in triggering this issue.

Thanks for your collaboration. After changing the deployment target to 10.14.4 so Swift libraries not being included in the bundle, the Gatekeeper seems to let the plug-in run and the stapler checking tool reports Accepted. Even that the ticketContents still does not contain the overall bundle entry.I made no other change to the code nor to the commands to build and notarize the bundle.However, I finally found how to force the notarization service to recognize the overall bundle. The notarization service started to list the overall bundle as well as the Gatekeeper becomes satisfied (even after lowering back to 10.14 so Swift libraries becomes present again) after I added CFBundlePackageType: BNDL into Info.plist. Strange that the notarization service depends on it as if I understand docs correctly, macOS should default to BNDL if the key is not found or not recognized.Thanks for your collaboration in triggering this issue.

The plug-in is built solely by Xcode itself. There is no script outside of Xcode nor there are "complications" intentionally added into the built process. I just call xcode archive. If theres anything non-standard or not-recommended, please, let me know what, ideally with tips how to correct it. Thanks.There are 5 build phases in Xcode:Dependencies (0 items) Compile sources (x items - m and swift files) Link Binary With Libraries (2 items - Swift and the host app SDK) Copy Bundle Resources (x items - pdf, xib, pem, pch) Copy Files (0 items)These are Release's Build Settings (I've copied everything from Build Settings - Customized - Combined):COMBINE_HIDPI_IMAGES = YES DSTROOT = (-PathWhereHostAppExpectsPlugins-) INSTALL_PATH = / MACOSX_DEPLOYMENT_TARGET = 10.14 LD_RUNPATH_SEARCH_PATHS = $(inherited) @executable_path/../Frameworks @loader_path/../Frameworks DEFINES_MODULE = YES INFOPLIST_FILE = $(SRCROOT)/MyPlugin/Info.plist PRODUCT_BUNDLE_IDENTIFIER = com.MyPlugin PRODUCT_NAME = $(TARGET_NAME) WRAPPER_EXTENSION = bundle FRAMEWORK_SEARCH_PATHS = $(SYSTEM_APPS_DIR)/(-HostApp-).app/Contents/Frameworks CODE_SIGN_IDENTITY = Developer ID Application CODE_SIGN_STYLE = Manual DEVELOPMENT_TEAM = (-TeamID-) ENABLE_HARDENED_RUNTIME = YES PROVISIONING_PROFILE_SPECIFIER = GCC_PREFIX_HEADER = MyPlugin/MyPlugin-Prefix.pch CLANG_ENABLE_MODULES = YES SWIFT_OBJC_BRIDGING_HEADER = MyPlugin/MyPlugin-Bridging-Header.h SWIFT_VERSION = 5.0 SWIFT_INCLUDE_PATHS =Here's what otool prints out (LC_LOAD_DYLIB and LC_RPATH only):Load command 9 cmd LC_LOAD_DYLIB cmdsize 80 name @rpath/(-HostApp-).framework/Versions/A/(-HostApp-)Core (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 0.0.0 compatibility version 1.0.0 Load command 10 cmd LC_LOAD_DYLIB cmdsize 88 name /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 23.0.0 compatibility version 1.0.0 Load command 11 cmd LC_LOAD_DYLIB cmdsize 96 name /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 1673.126.0 compatibility version 300.0.0 Load command 12 cmd LC_LOAD_DYLIB cmdsize 56 name /usr/lib/libobjc.A.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 228.0.0 compatibility version 1.0.0 Load command 13 cmd LC_LOAD_DYLIB cmdsize 56 name /usr/lib/libSystem.B.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 1281.0.0 compatibility version 1.0.0 Load command 14 cmd LC_LOAD_DYLIB cmdsize 88 name /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 1894.10.126 compatibility version 45.0.0 Load command 15 cmd LC_LOAD_DYLIB cmdsize 104 name /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 1673.126.0 compatibility version 150.0.0 Load command 16 cmd LC_LOAD_DYLIB cmdsize 104 name /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 1348.12.4 compatibility version 64.0.0 Load command 17 cmd LC_LOAD_DYLIB cmdsize 96 name /System/Library/Frameworks/Security.framework/Versions/A/Security (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 59306.41.2 compatibility version 1.0.0 Load command 18 cmd LC_LOAD_DYLIB cmdsize 56 name @rpath/libswiftCore.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 1100.8.255 compatibility version 1.0.0 Load command 19 cmd LC_LOAD_DYLIB cmdsize 64 name @rpath/libswiftCoreGraphics.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 0.0.0 compatibility version 1.0.0 Load command 20 cmd LC_LOAD_DYLIB cmdsize 56 name @rpath/libswiftFoundation.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 0.0.0 compatibility version 1.0.0 Load command 21 cmd LC_LOAD_DYLIB cmdsize 56 name @rpath/libswiftObjectiveC.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 0.0.0 compatibility version 1.0.0 Load command 22 cmd LC_RPATH cmdsize 32 path /usr/lib/swift (offset 12) Load command 23 cmd LC_RPATH cmdsize 48 path @executable_path/../Frameworks (offset 12) Load command 24 cmd LC_RPATH cmdsize 40 path @loader_path/../Frameworks (offset 12)Is everything as expected? What other places to look else for potential issues?

The Info.plist files are identical.Both working and non-working versions are from the same code base. I've just deleted all Swift files, the Swift-ObjectiveC bridging header file and the part of Objective-C code calling the Swift code. I did no other change - neither in the project metadata, all potential metadata/setting changes were made automatically by Xcode because there was no longer any Swift code in the project so the Swift-related options disappeared. However, the Info.plist file is identical.

First of all, I am going to summarize recent findings:The notarization service does not include the overall bundle in the ticketContents list so it does not recognize the overall bundle as a candidate for notarization. It lists just the dylib files and the main executable. As said by eskimo, the overall bundle should be listed as well.The dylib files themself do not seem to be the issue - I've changed deployment target to 14.4.4 so the swift's dylib files were no longer put into the bundle. The notarization service still did not included the overall bundle in the ticketContents list.Sending dmg instead of zip to the notarization service result in no change (except of including the dmg file in the ticketContents list). The overall bundle ticket is still missing.As long as the eskimo is right that the overall bundle should be included in the ticketContents list, it seems that something is causing the notarization service to skip the overall bundle.3. I've packed the bundle and transfered via web (so it becomes quarantined) to a fresh Catalina virtual machimeHow did you pack it? Are you distributing it as a pkg file?For the sake of these tests, I were transfering the same zip file as was sent to the notarization service.When distributing to real users, the bundle is copied in a directory next to several other files, than tar-ed and gzip-ed. The server replaces a content of one "other" file found in the archive before serving it to the user while keeping other file entries intact in the stream. Little complicated but there is no known issue with this approach yet.4. I've installed the third-party host application for which the our product is a plug-in onto the Catalina virtual machineDid you run the host application first?It does not matter. I've tried both variants.5. I've placed the plug-in into a folder where the host application expects itWhere is that?~/Library/Application Support/TheApp/Plugins4. You are not running the host app first. Therefore, the host hasn't passed Gatekeeper yet. There could be some extra checks as part of the initial Gatekeeper check that are failing due to your differently-signed plug-in that is being loaded.The failure appears on subsequent app starts as well.3. Are you distributing this as a pkg file? If so, you could just run your fix as part of a post-install script. If not, you would write a custom installer (maybe even in AppleScript) that performs those tasks, in addition to installing the plugin.1) The host app has its own plugin manager. When it downloads plugins, their signatures may be invalid or might not even exist. This may cause problems for said host app in the future. Apple has said that unsigned code will not run by default in a future version of macOS. But that's not your problem.We are not distributing the plugin via the plugin manager (yet).The user downloads the plugin from our website, uncompresses and double clicks on the bundle. This starts the host app (as the host app registers itself as a handler to that file extension) and the host app copies the bundle to its plugins folder located inside its Application Support subdirectory. On start-up, the host app tries to load all the bundles presents in that directory.2) Again, revisit how those Apple dylibs are getting into your bundle. Are you still codesigning and notarizing them? What if you don't do that?I were not codesigning and notarizing the dylib files in subsequent tests. I built the app to a new separate xcarchive for subsequent tests to have a clear starting point.3) The host app provides some templates and instructions. Are you using those? Specifically, the instructions tell you to use the "--deep" flag on the codesign. That flag is frowned upon, but you might need it in this case, assuming 2) above doesn't fix it.I've tried running codesign command initially as well. Now I let the Xcode to codesign (it did some codesigning as part of xcode archive).I think eskimo's suggestion to set your deployment to 10.14.4 and omit those dylibs is probably the easiest solution. That will make your plug in available. In this market, there are likely some people running old versions so this might actually be a problem for you.It did not help. I have not tried to run it yet but I followed eskimo's answer that the overall bundle should be listed in the notarization log. So I'm checking the log whether the overall bundle entry appeared.

I've tried to set the deployment target to 14.4.4. Yes, the Swift's dylibs disappeard from the bundle but the notarization log still misses include the overall bundle in the list.

Thanks for the pch recommendation. I'll remove it from the bundle after we fix the notarization.Neither the disk image's ticket has an entry for the overall bundle - it contains every entry present in the zip's ticket (the executable file and the dylib files) plus an entry for the dmg file, but not for the overall bundle. It also has issues: null.The bundle file structure is in an above reply. If I understand Bundle Structures correctly, our bundle is a Loadable Bundle and all the paths are standard and all the required files of Loadable Bundle are there.Here's the dmg content:% find /Volumes/1 /Volumes/1 /Volumes/1/MyPlugin.bundle /Volumes/1/MyPlugin.bundle/Contents /Volumes/1/MyPlugin.bundle/Contents/_CodeSignature /Volumes/1/MyPlugin.bundle/Contents/_CodeSignature/CodeResources /Volumes/1/MyPlugin.bundle/Contents/MacOS /Volumes/1/MyPlugin.bundle/Contents/MacOS/MyPlugin /Volumes/1/MyPlugin.bundle/Contents/Resources /Volumes/1/MyPlugin.bundle/Contents/Resources/[pdf, nib, pem files] /Volumes/1/MyPlugin.bundle/Contents/Resources/MyPlugin-Prefix.pch /Volumes/1/MyPlugin.bundle/Contents/Frameworks /Volumes/1/MyPlugin.bundle/Contents/Frameworks/libswiftObjectiveC.dylib /Volumes/1/MyPlugin.bundle/Contents/Frameworks/libswiftCore.dylib /Volumes/1/MyPlugin.bundle/Contents/Frameworks/libswiftCoreGraphics.dylib /Volumes/1/MyPlugin.bundle/Contents/Frameworks/libswiftDispatch.dylib /Volumes/1/MyPlugin.bundle/Contents/Frameworks/libswiftCoreFoundation.dylib /Volumes/1/MyPlugin.bundle/Contents/Frameworks/libswiftDarwin.dylib /Volumes/1/MyPlugin.bundle/Contents/Frameworks/libswiftIOKit.dylib /Volumes/1/MyPlugin.bundle/Contents/Frameworks/libswiftFoundation.dylib /Volumes/1/MyPlugin.bundle/Contents/Info.plistHere's the Info.plist. / It looks exactly the same as the Info.plist file in a bundle in which I have removed all Swift code (so that bundle no longer contains the Frameworks directory) and in which the notarization works as expected - it gets notarized and makes Gatekeepr happy. /% cat Info.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>BuildMachineOSBuild</key> <string>18G3020</string> <key>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleExecutable</key> <string>MyPlugin</string> <key>CFBundleIdentifier</key> <string>com.MyPlugin</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>MyPlugin</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleSupportedPlatforms</key> <array> <string>MacOSX</string> </array> <key>CFBundleVersion</key> <string>1</string> <key>DTCompiler</key> <string>com.apple.compilers.llvm.clang.1_0</string> <key>DTPlatformBuild</key> <string>11C504</string> <key>DTPlatformVersion</key> <string>GM</string> <key>DTSDKBuild</key> <string>19B90</string> <key>DTSDKName</key> <string>macosx10.15</string> <key>DTXcode</key> <string>1130</string> <key>DTXcodeBuild</key> <string>11C504</string> <key>LSMinimumSystemVersion</key> <string>10.14</string> <key>NSPrincipalClass</key> <string>MyPlugin</string> </dict> </plist>

After sending to a notarization service.% find MyPlugin.bundle MyPlugin.bundle MyPlugin.bundle/Contents MyPlugin.bundle/Contents/_CodeSignature MyPlugin.bundle/Contents/_CodeSignature/CodeResources MyPlugin.bundle/Contents/MacOS MyPlugin.bundle/Contents/MacOS/MyPlugin MyPlugin.bundle/Contents/Resources MyPlugin.bundle/Contents/Resources/[pdf, nib, pem files] MyPlugin.bundle/Contents/Resources/MyPlugin-Prefix.pch MyPlugin.bundle/Contents/Frameworks MyPlugin.bundle/Contents/Frameworks/libswiftObjectiveC.dylib MyPlugin.bundle/Contents/Frameworks/libswiftCore.dylib MyPlugin.bundle/Contents/Frameworks/libswiftCoreGraphics.dylib MyPlugin.bundle/Contents/Frameworks/libswiftDispatch.dylib MyPlugin.bundle/Contents/Frameworks/libswiftCoreFoundation.dylib MyPlugin.bundle/Contents/Frameworks/libswiftDarwin.dylib MyPlugin.bundle/Contents/Frameworks/libswiftIOKit.dylib MyPlugin.bundle/Contents/Frameworks/libswiftFoundation.dylib MyPlugin.bundle/Contents/Info.plist

I've then copied the zip file sent to the notarization service to the 10.15 virtual machine, unzipped and run spctl --assess:% spctl --assess --type install -vvvv MyPlugin.bundle MyPlugin.bundle: rejected source=Unnotarized Developer ID origin=Developer ID Application: OurTeamName (OutTeamId) % spctl --assess --type exec -vvvv MyPlugin.bundle MyPlugin.bundle: rejected (the code is valid but does not seem to be an app) origin=Developer ID Application: OurTeamName (OutTeamId) % spctl --assess -vvvv MyPlugin.bundle MyPlugin.bundle: rejected (the code is valid but does not seem to be an app) origin=Developer ID Application: OurTeamName (OutTeamId)

I am not sure but I think the plug-in is loaded within the host app's process.Deployment target is 10.14.Swift language version is Swift 5.I'm aware of the possible compatibility issues if different Swift runtimes are present in a process. The host app is pure Objective-C and our plug-in is the only plug-in using Swift. We re in a process of moving the Swift part to Objective-C. The replacement is not ready yet so we need to get the Swift version working in Catalina for a while.

Notarization log (I've just stripped jobId, uploadDate, sha256 and cdhash, renamed actual zip and bundle names to a dummy names):{ "logFormatVersion": 1, "status": "Accepted", "statusSummary": "Ready for distribution", "statusCode": 0, "archiveFilename": "MyPlugin.zip", "ticketContents": [ { "path": "MyPlugin.zip/MyPlugin.bundle/Contents/MacOS/MyPlugin", "digestAlgorithm": "SHA-256", "arch": "x86_64" }, { "path": "MyPlugin.zip/MyPlugin.bundle/Contents/Frameworks/libswiftObjectiveC.dylib", "digestAlgorithm": "SHA-256", "arch": "x86_64" }, { "path": "MyPlugin.zip/MyPlugin.bundle/Contents/Frameworks/libswiftCore.dylib", "digestAlgorithm": "SHA-256", "arch": "x86_64" }, { "path": "MyPlugin.zip/MyPlugin.bundle/Contents/Frameworks/libswiftCoreGraphics.dylib", "digestAlgorithm": "SHA-256", "arch": "x86_64" }, { "path": "MyPlugin.zip/MyPlugin.bundle/Contents/Frameworks/libswiftDispatch.dylib", "digestAlgorithm": "SHA-256", "arch": "x86_64" }, { "path": "MyPlugin.zip/MyPlugin.bundle/Contents/Frameworks/libswiftCoreFoundation.dylib", "digestAlgorithm": "SHA-256", "arch": "x86_64" }, { "path": "MyPlugin.zip/MyPlugin.bundle/Contents/Frameworks/libswiftDarwin.dylib", "digestAlgorithm": "SHA-256", "arch": "x86_64" }, { "path": "MyPlugin.zip/MyPlugin.bundle/Contents/Frameworks/libswiftIOKit.dylib", "digestAlgorithm": "SHA-256", "arch": "x86_64" }, { "path": "MyPlugin.zip/MyPlugin.bundle/Contents/Frameworks/libswiftFoundation.dylib", "digestAlgorithm": "SHA-256", "arch": "x86_64" } ], "issues": null }

I've included the plug-in's file structure at the top of the question above. I've skipped just the files created by codesign and spctl.

1. In production, I tar czf the whole directory which contains the bundle (the parent directory contains additional files like How to PDF etc.).2. While investigating, I was also trying the exactly same zip file sent for notarization by the xcrun altool --notarize-app command (the zip file was created calling ditto -c -k --keepParent --rsrc)

I've tried notarizing only the outer package but I failed. As I noted in the linked thread, everything started working when I removed all dylib from the plug-in. As official docs were of no help, I've searched web and I've found lots of thread stating issues if dylib files are present but missing any answer. Then I found this thread stating that if they notarized dylib files separatedly, it helped. So I've tried that and really, it made a progress.It's strange that the assessment fails unless I perform assessment on inside files first. I would expect that manually performing assessments on inside files would not change the outcome of the bundle-wide assessment as it should be either ok or not. The behaviour I experience is quite weird to me as it reports the exactly same binaries both as rejected and as accepted.