CODEWITHSUNDEEP
iosobjective-ciphoneswiftcocoapods
seanoshea
seanoshea

Reputation: 6136

Sharing Code between Objective-C based SDKs

I'm developing two Objective-C based SDKs and I have common code that I'd like to share between the two SDKs. I'd also like to be able to expose this common code to consumers of the SDKs too. For the common code that I'd like to expose to clients of the SDKs, I'd want this to be exposed to developers that are writing their apps in both Objective-C and Swift.

I was thinking of using a Cocoapod for organizing the common Objective-C based code & have started off a library with pod lib create CommonCode. For this CommonCode library, it's pretty easy to declare which .h files are exposed and which ones are private via the Target Membership options.

However, when importing this CommonCode cocoapod into one of the SDKs, I'm unsure of how to expose .h files in the CommonCode via one of the SDKs. i.e - how can I make sure that developers who are consuming one of the SDKs can get access to some of the code contained in the CommonCode library.

Is this possible with Cocoapods? Would you advise me on a better way to organize my code?

Upvotes: 0

Views: 104

Answers (1)

werediver
werediver

Reputation: 4757

It's okay to have multiple dependencies in your application, but I would strongly recommend to minimize the number of dependencies in your libraries/frameworks/SDKs.

It is important for the host application developers, because indirect dependencies could cause linkage or symbol resolution conflicts with other direct and indirect dependencies when different versions are required by different dependents.

If you need to share some code between two frameworks, consider joining them into one workspace and adding the files you're interested in to both framework targets. I would not recommend exposing any shared content publicly, because it can cause linkage or symbol resolution problems when using both of your frameworks in one application.

Also check if one of the frameworks actually depends on another — then it could make sense to just declare this dependency explicitly.

Of course, you can extract the shared code into another framework and declare this dependency explicitly — that's what you're considering in the OP. There is nothing special about this shared framework with relation to CocoaPods, prepare it as usual.

Don't worry about (in)visibility of this indirect dependency to the host application. If the host application really needs to access the shared framework, the application can import and use it explicitly.

If all of your frameworks are in Objective-C, you can try to import the umbrella header of the shared framework in the umbrella header of your main framework. If the compiler won't complain, that should do what you want.

I'm not talking about CocoaPods black magic (on-the-fly pod build settings modification) here, because I don't think you need to mess with it to solve you issue.

Upvotes: 1

Related Questions