Swift Access Control Limits for Framework API Surface

When developing modular architectures in Xcode, managing the visibility of types across different targets is critical for maintaining a clean API. Swift provides internal as the default access level, which restricts visibility to the defining module, and public for external access.

A design challenge arises when a type must be visible to an external module, but its internal implementation details—such as specific methods or properties—should remain hidden to prevent consumers from relying on unstable internals. While public allows instantiation and usage, it does not permit subclassing or overriding outside the module.

There is a tension between providing necessary functionality and accidentally expanding the public surface area, especially when deciding between public and open modifiers for class hierarchies.

• What are the specific constraints when exposing a public class that contains internal members?
• In what scenarios does the open modifier introduce risks to API stability compared to public?