As long as the Obj-C and Swift are in separate source or binary targets, SPM supports them being in the same package.
There was a Swift Evolution proposal at one point to go all the way and bring in support for mixed Obj-C and Swift targets [1] but it was returned for revision. It talks about the multiple target workarounds:
> Distribute binary frameworks via binary targets. Drawbacks include that the package will be less portable as it can only support platforms that the binaries support, binary dependencies are only available on Apple platforms, customers cannot view or easily debug the source in their project workspace, and tooling is required to generate the binaries for release.
> Separate a target’s implementation into sub-targets based on language type, adding dependencies where necessary. For example, a target Foo may have Swift-only sources that can call into an underlying target FooObjc that contains Clang-only sources. Drawbacks include needing to depend on the public API surfaces between the targets, increasing the complexity of the package’s manifest and organization for both maintainers and clients, and preventing package developers from incrementally migrating internal implementation from one language to another (e.g. Objective-C to Swift) since there is still a separation across targets based on language.
The upshot is that SPM has a better interoperability story with Swift and C++ [2] and maybe that can serve as a foundation for getting to the same level of interop for Obj-C.
As long as the Obj-C and Swift are in separate source or binary targets, SPM supports them being in the same package.
There was a Swift Evolution proposal at one point to go all the way and bring in support for mixed Obj-C and Swift targets [1] but it was returned for revision. It talks about the multiple target workarounds:
> Distribute binary frameworks via binary targets. Drawbacks include that the package will be less portable as it can only support platforms that the binaries support, binary dependencies are only available on Apple platforms, customers cannot view or easily debug the source in their project workspace, and tooling is required to generate the binaries for release.
> Separate a target’s implementation into sub-targets based on language type, adding dependencies where necessary. For example, a target Foo may have Swift-only sources that can call into an underlying target FooObjc that contains Clang-only sources. Drawbacks include needing to depend on the public API surfaces between the targets, increasing the complexity of the package’s manifest and organization for both maintainers and clients, and preventing package developers from incrementally migrating internal implementation from one language to another (e.g. Objective-C to Swift) since there is still a separation across targets based on language.
The upshot is that SPM has a better interoperability story with Swift and C++ [2] and maybe that can serve as a foundation for getting to the same level of interop for Obj-C.
[1]: https://github.com/swiftlang/swift-evolution/blob/main/propo...
[2]: https://www.swift.org/documentation/cxx-interop/