Why internal classes appear in ProductName-Swift.h? May I change this file manually?

Question

I build Swift framework that is dependent on another Objective C framework (so, the project contains bridging header file). When I open auto-generated ProductName-Swift.h file inside my framework's headers I see that classes that I would not like to expose (those with internal modifier). According to Apple docs it's legit:

By default, the generated header contains interfaces for Swift declarations marked with the public or open modifier. If your app target has an Objective-C bridging header, the generated header also includes interfaces marked with the internal modifier.

But why does it happen? Can anyone explain me, please? According to my logic, if I decide to make some code to be internal it shouldn't be used outside of my framework and it shouldn't be exposed in a header.

Anyway, I can write a bash script that will delete internal classes and functions from ProductName-Swift.h after the build, but I'm not sure if it's ok to do such a thing. Will the user have any problems while using my Swift framework with "fixed" ProductName-Swift.h inside his Objective C project, for example?

Answer 1

According to Swift's official documentation SwiftDoc, it states internal modifier as:

Internal access enables entities to be used within any source file from their defining module, but not in any source file outside of that module. You typically use internal access when defining an app’s or a framework’s internal structure.

Now, if you have exposed any of those internal classes to Objective-C, the automatic created bridging header would probably include that class definition.

Because Xcode creates the bridging header for the purpose of those Swift classes to be usable from any Obejctive-C source file that you may add/write in that project.

If those classes are never to be used from any Objective-C file ever, you can try removing @objc from them (if they were already exposed), or put file private access modifier.

In this scenario, what else you can do is when you build the framework, you can check if the auto generated header file is kept as a public header from Xcode build phase settings. If it is public, make it private, and expose a custom header for your framework users, where you only put your desired swift class definitions.

If it is not listed there as a header at all, and if you choose not to use those internal classes from any of your Objective-C files in your framework (if you decide to have any Objective-C file in your project), then sure, you can go ahead with a script to remove your unwanted class definitions from that bridging header.

Hope this would help.