开启BUILD_LIBRARY_FOR_DISTRIBUTION为YES时如何保留@inlinable init标记？

报错的本质原因 #

开启BUILD_LIBRARY_FOR_DISTRIBUTION本质是开启了Swift的库演化模式，编译器会强制约束所有可能破坏二进制接口稳定性的写法，这也是你移除@inlinable标记后报错就消失的核心原因。

这类报错的核心逻辑是：@inlinable的影响会随构建目标变化，确实可能引发兼容性问题。如果被标记为@inlinable的方法实现发生变更，导入该框架的模块除非重新编译，否则无法应用这些修改。常规框架更新只需要替换二进制文件即可生效，但由于@inlinable会把部分方法实现内联到调用方的编译产物里，哪怕应用链接了新版本的框架二进制，实际运行的还是被内联的旧逻辑。正因如此，开启库演化、支持二进制分发的项目，必须对@inlinable的使用做严格约束，避免破坏框架的ABI稳定性。

合规保留@inlinable的可行方案 #

不需要完全移除所有@inlinable标记，只要严格遵守Swift对可分发库中内联代码的约束规则，就可以让代码顺利通过编译，同时不破坏ABI稳定性：

• 访问级别约束
  所有被@inlinable标记的公开方法、初始化方法内部，绝对不能直接访问非公开级别的内部声明：
  • 禁止直接访问internal、fileprivate、private修饰的属性、方法、自定义类型
  • 如果确实需要在@inlinable代码中复用内部实现，需要用@usableFromInline标记对应的内部成员。这个标记会把成员的符号暴露给编译器做内联优化，但不会将其加入对外公开的API列表，同时能保证跨版本的ABI兼容
• 标记位置约束
  @inlinable只能标记在public或open级别的公开声明上，给内部方法加@inlinable在开启库分发的场景下一定会触发编译报错，这也是最常见的报错触发点。

// 符合XCFramework分发要求的@inlinable写法
public class ImageLoader {
    // 内部成员用@usableFromInline标记，支持内联但不公开API
    @usableFromInline
    let memoryCacheCount: Int

    @inlinable
    public init(cacheCount: Int = 10) {
        // 仅可访问public成员或@usableFromInline标记的成员
        self.memoryCacheCount = cacheCount
    }
}

使用注意事项 #

• 一旦某个公开接口加了@inlinable，它的完整实现逻辑就相当于成为了公开契约的一部分。从你发布第一个版本开始，后续绝对不能随意修改内联的实现细节——否则只更新框架二进制、没有重新编译的调用方，依然会运行当初被内联到自身产物里的旧逻辑，引发隐蔽的兼容性问题。
• 如果你的@inlinable方法内部依赖了大量无法快速适配的内部实现，改造成本过高，不如直接移除@inlinable标记。当前Swift的跨模块优化已经足够成熟，XCFramework场景下去掉内联带来的性能损耗，远低于你为了适配规则重构代码、长期维护内联实现契约的成本。

内容的提问来源于stack exchange，提问作者echo