For testing I moved our "universal" (iOS, macOS, tvOS, watchOS) xcframework from one Mac to another for testing, and encountered this issue when testing the macOS slice: not valid for use in process using Library Validation: library load disallowed by system policy and “X.framework” can’t be opened because Apple cannot check it for malicious software. This software needs to be updated. Contact the developer for more information. It appears that the xcframework needs to be notarized. However, the WWDC on notarization talks about enabling Hardened Runtime. Our xcframework projects don't seem to have Hardened Runtime as an option. Is it not needed? And what roughly is the process of notarizing an xcframework? If I take all I've listened to about notarization from WWDC videos (keeping in mind the term xcframework I did not hear occur once) it sounds like I should be zip archiving the xcframework using ditto with some special parameters, sending it off to get notarized, and then stapling the result to the original xcframework. Is that essentially correct? Is there more documentation on notarization of xcframeworks somewhere?

I've put together a Swift Package which has a binary dependency. The xcframework contained within depends on another xcframework which is in another package. I can't get the first Swift Package to bring in the second Swift Package as a dependency beyond the .testTarget. In the WWDC 2020 video "Distribute binary frameworks as Swift packages" - https://developer.apple.com/videos/play/wwdc2020/10147/ it shows code that looks like this: import PackageDescription let package = Package( 		 name: "Emoji", 		 products: [ 					.library( 							 name: "package", 							 targets: ["Emoji"]), 		 ], 		 dependencies: [ 					.package(url: "https://github.com/JohnnyAppleSeed2020/BinaryEmoji", from: "1.0.0"), 		 ], 		 targets: [ 					.target( 							 name: "package", 							 dependencies: ["Emoji"]), 		 ] ) The presenter says, "If you want to use that same library as a package dependency, it also works the same way you are used to. In the package manifest, you can an entry to the dependencies array, which points to the repository the package is using, and define the version restrictions that you chose for this dependency." That statement isn't working for me, because I don't have a .target but a .binaryTarget. My package then looks like this: import PackageDescription let package = Package( 		 name: "Emoji", 		 products: [ 					.library( 							 name: "package", 							 targets: ["Emoji"]), 		 ], 		 dependencies: [ 					.package(url: "https://github.com/JohnnyAppleSeed2020/BinaryEmoji", from: "1.0.0"), 		 ], 		 targets: [ 					.binaryTarget( 							 name: "package", 							 path: "KochavaTracker.xcframework", 							 dependencies: ["Emoji"]), 		 ] ) Xcode complains: Extra argument 'dependencies' in call So it would seem that this same support only works for .target and not .binaryTarget. Why not? Here is my actual "first" Swift Package: // The swift-tools-version declares the minimum version of Swift required to build this package. import PackageDescription let package = Package( 		name: "KochavaTracker", 		products: 		[ 				// Products define the executables and libraries a package produces, and make them visible to other packages. 				.library( 						name: "KochavaTracker", 						targets: 						[ 								"KochavaTracker" 						] 				), 		], 		dependencies: 		[ 				// Dependencies declare other packages that this package depends on. 				// .package(name: "KochavaCore", path: "./../Apple-SwiftPackage-KochavaCore"), 				.package(name: "KochavaCore", url: "https://github.com/Kochava/Apple-SwiftPackage-KochavaCore", from: "4.0.0-alpha.1"), 		], 		targets: 		[ 				// Targets are the basic building blocks of a package. A target can define a module or a test suite. 				// Targets can depend on other targets in this package, and on products in packages this package depends on. 				.binaryTarget( 						name: "KochavaTracker", 						path: "KochavaTracker.xcframework" 				), 				.testTarget( 						name: "KochavaTrackerTests", 						dependencies: 						[ 								"KochavaCore", 								"KochavaTracker" 						] 				), 		] ) It works in general, but my clients are required to manually add KochavaCore as a package dependency in my app in addition to KochavaTracker. Is there something I can do to bring in KochavaCore automatically like .testTarget does?

In WWDC 2020 an example was given that you could use a command like the following: $ swift package compute-checksum some.xcframework.zip and it would return a checksum that you can use in a Swift Package. When I zip my xcframework and run this command from the command line I get: error: root manifest not found What am I doing wrong?

I'm finding xcframeworks are working effortlessly when importing them into a host application, or into the test target of a host application. There's one case where I can't get it to work. I have an xcframework (B) which depends on another xcframework (A). xcframework B has xcframework A added to its section "Link Binary with Libraries". That works fine. But xcframework B also has a test target, which depends upon xcframework B, but that test target cannot see what's in xcframework A. I added xcframework A to its "Link Binary with Libraries" section like I would with any normal app or other framework, but it doesn't work the same way. Previously when I had dynamic frameworks doing the same thing I added the dynamic framework to a copy files phase copying, which made it all work. The same equivalent thing isn't working with an xcframework. Is there any way to do this?

Our organization distributes pre-compiled dynamic frameworks using the method which we understood to be previously cannoical prior to Xcode 11.4. That is to say we use the method Apple provided to us in 2017 titled "Technical Q&A QA1768 Building & Using Pre-Compiled Frameworks For Simulators and Devices.pdf". To summarize that approach, it involved building two pre-compiled frameworks, one for device and one for simulator, and then having the correct one used at runtime. The latter involved modifying "Other Linker Flags" to select only the framework which should be used depending on how "Any iOS Simulator SDK" and "Any iOS SDK" were set, and adding a new run script phase to the Build Phases which strips out the simulator slices from device builds.When moving to Xcode 11.4, we now encounter the error:"Building for iOS, but the embedded framework 'X.framework' was built for iOS Simulator."We understand that migrating to XCFramework is one way to solve this problem. For those people who wish (or need) to continue for now to use earlier versions of the pre-compiled frameworks build as dynamic frameworks, what can be changed in the project settings to overcome this error?