Why one module has access to another when the first hasn't the second in 'Linked Frameworks and Libraries'?

Viewed 136

I have two Cocoa Touch Framework projects main and sub in the same workspace. main uses protocols and classes from sub. main is compilable. But it has no link to sub in 'Linked Frameworks and Libraries' and in 'Build Phases'.

Why is it compilable? As for me, it isn't correct. I want to control dependencies between modules. How to close access to the sub module in the main?


Note 1 (31.10.19)

The same story with two Cocoa Touch Static Library, but in this case I have no ability to add something into 'Linked Frameworks and Libraries', only into 'Build Phases'. Also, when tried to import Cocoa Touch Static Library into Cocoa Touch Framework and vice versa — nothing changed.


Note 2 (05.11.19)

The current note is a reaction to answers. Because for me it looks like I didn't describe problem clearly. And the note tries to fix it.

All my frameworks and libraries during the research was in the single workspace. I thought before that workspace is an Xcode document that groups projects and other documents so developer can work on them together. As I see now, the workspace is something more than UX improvement. It creates effects in code level. Does removing of projects from workspace solve my problem? And if yes, how to do it? Are 'UX improvement for developer' and 'Dependencies control side effect' inseparably combined in the workspace? Can I use only 'UX improvement for developer' part of workspace? If yes, how?

Also I see no way how access specifiers (private, public, etc) can help me. I need to control dependencies between components. My problem is at the architecture level. I need to organize borders between components (important part of software architecting). The question is about technical limitation that I found and that prevents to create borders. 'Access specifiers' is about walls building, 'dependencies' is about rooms constructing in building.

The problem is that protection from borders breaking can live only in air (Some developers know... some documentation contains...) As an analogy, I need static typing, I found that language supports dynamic only but in way that looks like mysterious. I can't believe. I don't clearly understand. I ask.

1 Answers

The Linked Frameworks and Libraries section just tells Xcode to link the sub module with the main module after it builds. That way, at runtime when something in main calls import Sub, the sub module can in fact be found and imported.

You might want to check in the Dependencies section of Build Phases. If sub is in there, this tells the build system that when you build main, you also want to rebuild sub, if it was changed at all.

However, I don't think even that will make it so that main cannot import Sub. The reason is both frameworks are in the same workspace. Even without Dependencies or Link Frameworks configured, if you open the workspace, build sub, then try to import Sub inside main — this will work.

That's because Xcode workspaces effectively create a shared location for their build artifacts. As long as the frameworks are in the same workspace, it will be possible to import one into another. Although, you will get very weird behaviors if you do that without configuring Dependencies or Link Frameworks, so I'd take care to avoid that.

If you're trying to locate all the import Sub calls, I'd recommend doing a project-wide search.

If you want to make certain parts of the sub framework unavailable to other frameworks, you should use Swift's access control modifiers. Anything public or open will be visible to other frameworks.

If you're trying to just prevent other developers from accidentally importing sub, I don't believe you can do that as long as they're in a shared workspace.

Related