Suggestions for project setup for xcframework with internal and public modules

Using Swift
,
1

Context

We have a closed source binary that is distributed as an .xcframework. We would like to leverage modules to help support a growing codebase and team.

Project Setup

Our project has many internal modules and we leverage the @_implementationOnly attribute. Risks aside, this works great. We have types that need to be referenced by both the public API and an internal module.

Problem Statement

How can we setup the project to support using types in both the public API and the internal modules?

Details

It is understood that an .xcframework can only have one module. In order for internal modules to reference the public facing types we need to either

  1. Have internal modules reference the public API module (Not possible given it creates a circular reference)
  2. Create a second .xcframework that contains the public types which both SDK and internal modules can reference (Requires special packaging to associate the .xcframework dependencies.
  3. Maintain a public API type and an internal type (Requires mapping layer)

Does anyone else have similar requirements? If so, how did you work around this constraint? Are there other options that are being overlooked?

2

Personally, I think option 2 is really the cleanest and matches what would typically be done in a source-based setup.

1 Like
3

Thank you for your quick reply. I have a few follow up questions.

Do you have any recommended readings on this topic? I am really interested in learning more about any red flag setups, design considerations when separating a single framework in this manner and general tips on API management.

Not breaking the existing public API is really important for us right now. For backwards compatibility would providing type aliases in the main SDK avoid breaking the existing API? Would the @_exported attribute on the new xcframework from the within the main SDK solve the same problem?