How to make a Swift framework submodule really pri

Question

I've found another question which brings more details regarding the problem and possible solutions. It seems like there is a known bug which is a subject for future improvements.

Objective C classes within an iOS Swift-based dynamic framework

I'm developing a framework in Swift and I'm using some Objective-C code inside the framework. So far my module map looks like this:

framework module MyModule {
    umbrella header "MyModule-umbrella.h"

    export *

    explicit module Private {
        header "MyTools.h"
    }
}

My concern is that all the APIs from MyTools.h are visible from outside the framework: for example, if you install the framework using Cocoapods, then you import MyModule into your application (not MyModule.Private), you are able to access MyTools.h which is not desirable and redundant. Is there any way to make MyTools invisible from outside the framework?

PS. I use Cocoapods to distribute the framework, here is my podspec (the most significant part):

s.module_map    = 'Pod/MyModule.modulemap'
s.frameworks    = 'CoreData', 'CoreTelephony', 'SystemConfiguration'
s.resources     = 'Pod/Classes/MessageStorage/*.xcdatamodeld'
s.public_header_files = 'Pod/Classes/**/*.h'
s.private_header_files = 'Pod/Classes/MyTools/**/*.h'
s.source_files  = 'Pod/Classes/**/*.{h,m,swift}'

PSS. My umbrella header does not import MyTools.h

PSSS. Just tried to exclude the header from the main module:

framework module MyModule {
    umbrella header "MyModule-umbrella.h"

    export *
    exclude header "MyTools.h"

    explicit module Private {
        header "MyTools.h"
    }
}

No luck.

Answer 1

I had exactly the same problems recently. The quick answer is you can't :) Even if you declare "private" modulemap, it can be always imported by your framework users. Please note, that usually, it is not a concern, especially with open source. You just say "this is an internal module, don't use it".

But (there is always but) - you can have behavior, that effectively works the same - allows you to use your Objective-C classes withing same framework target, without making them public. It works in closed source setup, I'm not 100% sure how would it behave with pods.

The case a bit too complex to paste everything here. I'm adding a link to my article about the topic, maybe it will help you. But speaking honestly - it might be a bit of overhead in your setup.

Creating Swift framework with private Objective-C members. The Good, the Bad, and the Ugly

Github example project

Answer 2

I found another question which brings more details regarding the problem and possible solutions (which don't work though). It seems like there is a known bug which is a subject for future improvements.

Objective C classes within an iOS Swift-based dynamic framework