analytics is a relatively simple API so exposing that isn't as heavy as exposing something like a bunch of database tables

Soo … here’s something I’ve noticed anecdotally … My

allShared

module has a dependency on another module called

adw-program

.

adw-program

defines a class, called

Program

.

allShared

defines a class called

IosContainer

.

IosContainer

has a function,

getProgram()

that returns an instance of

Program

. in my

allShared

module, if i use

implementation

for the

adw-program

dependency, and don’t export it via the cocoapods framework, then in my swift code, the

Program

class’s type is actually

Adw_programProgram

… Also, any of the other classes in my

adw-program

module are NOT available at all in my ios/swift project. the

Adw_programProgram

class is available only because the

IosContainer

has a method that returns an instance of it. However, if I make the

adw-program

an

api()

dependency (and export it via cocoapods), then things in Swift are more “what you would expect”. I have a

Program

class, and I can see all of the (public) classes declared in

adw-program

.

One option for more fine-grained control is to split

adw-program

into two separate modules. One has just the public API that you'll expose through

allShared

and the other has impls and internal details. Then you can export the API module but still control what gets exported based on whether it's in the api or the impl module, and you won't see the module name prefix on things from the api module.

So I’ll probably end up with

adw-program

and

adw-models

being exported api’s, and all the others being implementations that are kept “internal” to the library