On one hand we distribute these xcframeworks as part of an SDK, but on the other hand, the copies which move through AirDrop are only moved this way for testing purposes-- to be tested on the other machine. The xcframeworks which we ultimately put into Swift Packages and distribute never go through the AirDrop process, as they move to this place from the original build machine. It sounds like you're saying that notarization is not needed in this case then. Is that correct? It also sounds as though you're saying that AirDrop specifically created this issue. Can this issue be bypassed today by transferring the xcframework by using a means other than AirDrop, such as using a thumb drive or copying over the network to a shared drive?

Runtime. The app is a multi-target app with targets for iOS, macOS, tvOS, watchOS. If you run or test the app for something other than macOS, such as iOS, it runs fine. If you run or test the app for macOS, it reaches the point where it says "Running" at the top of Xcode. Then the popup occurs saying "“X.framework” can’t be opened because Apple cannot check it for malicious software." It produces eight popups modally, one at a time, one for each xcframework. To get this result, eight xcframeworks were built on Mac A. These eight xcframeworks were transferred to Mac B via AirDrop. From there through script(s) they were copied into and embedded into eight Swift Packages. These swift packages are embedded into the test app through being included locally. The same steps work fine when run on Mac A exclusively. The AirDrop to Mac B of the eight xcframeworks creates the problem. I first encountered it when running our command line test scripts on the build, where the macOS specific tests failed.