I think it is unlikely that packages will support plain frameworks since we aim for packages to be multi-platform and frameworks inherently are not.
Currently our Carthage dependencies are frameworks, and we support iOS and iOS Simulator platforms with no issues. Why can't we just tell our Swift packages, "here is the framework search path" and it will trust that the right platform's frameworks will be there at compile time and runtime?
Another issue for us is that we have a lot of locally-declared frameworks that are not already built at compile-time. Currently there is no way to import one of these frameworks into a Swift Package, to my knowledge. This is very limiting in terms of how we can use Swift Packages as modules within our application, and I don't understand why it should be a limitation considering the fact that our local frameworks will be built for the same platform the Swift packages are being built for.
We'd be open to building XCFrameworks at build-time if it meant we could import them into the Swift Packages but Xcode does not give you a way to build an XCFrameworks at build-time—you have to archive, then do some command-line stuff.
Both Swift Packages and XCFrameworks both seem designed just to cater to people distributing a library, either prebuilt or not. They don't seem to have many considerations for people using Swift Packages to define modules inside their existing applications. Like, what if you want to import a framework from the same workspace as the package?
You might say, "Well, Swift Packages weren't designed for what you're using them for." But I'd say, they should be! We kind of hate Xcode project files and all the merge conflicts that result from them. Swift Packages seem like a godsend but they have too many limitations and gotchas right now.
Maybe you could wrap the frameworks produced by Carthage into XCFrameworks yourself, the
xcodebuild -create-xcframework command can do that in one step.
The problem is that Carthage makes multi-platform frameworks on the assumption that before it bundles a framework into a given bundle, it will strip out the bits that don't go with that platform at build-time. So it's not really feasible to take its "frameworks" and make XCFrameworks using that command, since that command expects that frameworks are already single-platform.
Fortunately, there is a new version of Carthage coming up (it's in PR right now) that creates XCFrameworks instead of frameworks. However so far it only works for things you can build from source—but unfortunately, we have third-party dependencies like Firebase/Crashlytics etc. that are only available as .frameworks.
So it's super annoying not to be able to import .frameworks directly into our local Swift packages, because of course, everything has to depend on the thing that depends on Crashlytics, unless we use some dependency inversion scheme (which is what we're resorting to).
That being said, I guess I don't understand why Swift Packages couldn't be made to import regular .frameworks, given certain conditional build settings, or assuming that the right framework will be at the search path at runtime etc.
Using conditional imports and compiler directives to keep certain code specific to certain platform builds seems like it could have worked as a solution for this, rather than blocking off an entire use case from Swift Packages.