emits an invalid Swift module interface, due to a public type (IOSSecuritySuite.IOSSecuritySuite class) has the same name as a module

[marsepu]

Due to the invalid Swift module interface, a IOSSecuritySuite binary outputted with an older Swift toolchain will not be considered compatible newer Swift toolchains.

Example:

• I previously built IOSSecuritySuite xcframework binary with an older Xcode 14.x
• Attempts to build a project, that links against that xcframework with Xcode 15.x will result in build errors.
• See bottom of this message for an example of the Xcode 15 build error.

Analysis:

1. Root cause is the public IOSSecuritySuite class which has the same name as the module.
2. The official Swift github issue tracker has already documented this as a known issue:
   • https://github.com/apple/swift/issues/56573

Solution:

• Update build setting BUILD_LIBRARY_FOR_DISTRIBUTION to YES
  • This will enable Swift library evolution and Swift module stability. For details see: https://www.swift.org/blog/library-evolution/
• Update build setting OTHER_SWIFT_FLAGS with value -verify-emitted-module-interface
  • this will ensure that future Swift Module Interface issues result in a compile time error.
• Change the module to IOSSecuritySuiteLib, instead of IOSSecuritySuite
  • This will break builds, due to any previous Import statement using the now incorrect Module name.
  • I have already verified that this works.
  • i.e. outputting a binary with Xcode 13.x/14.x is now compatible with Xcode 15.x
• I will submit a Pull Request with these changes to resolve this issue.

Example of the Xcode 15.x build error: Failed to build module 'IOSSecuritySuite'; this SDK is not supported by the compiler (the SDK is built with 'Apple Swift version 5.6.1 (swiftlang-5.6.0.323.66 clang-1316.0.20.12)', while this compiler is 'Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)'). Please select a toolchain which matches the SDK.

[r3ggi]

Hey!

First of all - thank you for your suggestion. After further analysis and discussion with some iOS devs we decided not to implement this. It would break backwards compatibility which in our opinion has worse impact than incompatibility with outputs from old Swift toolchains