我们正在开发 8 个 SDK，它们将作为 XCFrameworks 共享。SDK 相互依赖，我们也依赖第三方 XCFrameworks，它们作为 Cocoapods 共享。
下面是依赖图外观的简单演示。
A -> B, C
B -> D、E、F
C -> G, H
D、E、F -> H
H -> I, J
我 -> K
这里 G 和 J 是第三方 XCFrameworks。K 是第三方 FAT 框架，完全用 Objective C 编写。其他字母表示我们完全用 Swift 编写并兼容 Objective-C 的 SDK。
您可以阅读第一行，因为 A 依赖于 B 和 C。
我们通过将所有这些作为开发 Pod 添加到示例 iOS 客户端来开始开发 SDK。我们面临的唯一问题是，即使对清理构建整个项目所需的任何 pod 进行微小更改。我们在工作区设置中解决了这个设置“旧版构建系统”。
当我们接近发布时，我们生成了 XCFrameworks 并尝试将它们添加到客户端。
我们几乎在所有框架中都面临以下问题。因为我们有与 SDK 名称匹配的类名，就像旧的 FAT 框架一样。 'FrameworkName' 不是 swiftinterface 中的 'FrameworkName' 错误的成员类型
然后我们重命名了所有框架并遇到了以下问题。 XCFramework 需要以 iOS 13 为目标，以实现具有 Objective-C 兼容性的框架间依赖关系
我们从 iOS 9 开始支持。所以迁移到 iOS 13 甚至不是一个选择。.swiftinterface即使在探索了引发这些问题的生成文件之后，我们也无法找到这个问题的确切原因。我们发现这个问题可能是因为通过以下方式使用继承。
X 是一个 Swift 类，通过继承 NSObject 使 Objective C 兼容。当我们有来自任何其他 SDK 的另一个类 Y 时，像下面这样继承 X，就会抛出这个问题。
例如，我们在框架 H.
@objc class X: NSObject { }
然后在依赖于 H 的框架 D 中，我们有
class Y: X { }
我们在一个地方将其删除，问题得到解决。我们在八个 SDK 中都有这种模式，并且我们删除了所有这些。
然后当我们尝试构建时，我们遇到了以下问题。
'@objc' instance method in extension of subclass requires iOS 13.0.0.
我们将所有@objc扩展方法移至该类。这些主要是来自公共UIKit类的委托和数据源方法。
xcodeproj在客户端应用程序中使用 XCFrameworks 遇到这些问题后，我们决定删除开发 pod 设置并手动将所有 SDK的文件拖放到客户端应用程序中。我们还必须手动添加第三方框架。
这样，可以在开发期间而不是发布时识别上述一些问题。
现在的情况是，当我们对任何 SDK 进行更改时，除非我们进行干净的构建，否则它不会被反映，这需要大量时间并且不可取。
即便如此，在某些情况下，客户端应用程序只是抛出Unable to import D或任何其他框架，我们在其中进行了一些更改。然后我们在方案中选择该框架，构建一次，然后选择客户端应用程序并再次构建它以查看我们应用程序中的更改。
从长远来看，这个工作流程既麻烦又痛苦。请建议更好的替代设置来开发多个 XCFrameworks。
我们的下一个问题是在生成 XCFrameworks 时，我们需要每个 SDK 使用其他依赖 SDK 的 XCFramework。为此，我们必须从最底层的框架开始工作。生成它，添加到它上面的那个，然后继续下一个。
从长远来看，这也感觉像是一种负担。我们真诚地希望有更好的方法来做到这一点。请建议那些。
我们没有使用 Swift Package Manager (SPM)，因为我们的大多数客户使用 Cocoapods 进行依赖管理，剩下的少数只是手动将框架拖到他们的项目中。
如果 SPM 可以起到灵丹妙药的作用，一次性解决所有这些问题，那么我们可以考虑使用它。