Great question about Swift Package Manager (SPM) dependencies! It looks like you're interested in having MyFramework depend on SecondFramework, so that when customers install MyFramework, they also get SecondFramework as a dependency.
For more information on SPM dependencies, check out the official documentation. If you have any further questions or would like to discuss using target dependencies versus package dependencies, feel free to share your Swift Package file in the forums.
https://developer.apple.com/documentation/xcode/distributing-binary-frameworks-as-swift-packages
Swift Package Manager configuration:
https://docs.swift.org/package-manager/PackageDescription/PackageDescription.html
https://docs.swift.org/package-manager/PackageDescription/PackageDescription.html#package-dependency
An example of a dependency file:
let package = Package(
...
dependencies: [
.package(
url: "https://github.com/apple/allfiles.git",
from: “1.0.0”
)
],
....
There are many dependencies, if you are using local packages then you can just add the dependency path, however your customer’s will not have that path on their computer nor the path.
.package(path: “../SecondFramwork")
When distributing Swift libraries using the Swift Package Manager (SPM), it's crucial to have a well-thought-out strategy. One key aspect is to make sure your dependencies are publicly available for download by Xcode. This ensures that other developers can easily integrate your library into their projects.
Based on your description, the issue might be related to the availability of your dependencies. To get more help and find potential solutions, I recommend posting your package file here. When publishing your package, consider exploring the options for binary dependencies. There are different approaches you can take to distribute your framework, and each has its own pros and cons. Here are some of the options to keep in mind:
- Source Code Dependencies: This is the default option where your library's source code is downloaded and compiled during development.
- Binary Dependencies: Precompiled binaries of your library are made available for download. This can significantly reduce build times for users who integrate your library into their projects.
- Package Bundles: You can include any additional resources, such as binaries, frameworks, or assets, in a package bundle. This makes it easier for users to deploy your library without having to manually manage external dependencies.
By sharing your package file and exploring the options for binary dependencies, I'm confident that you can find a solution that works best for your framework distribution.