#if canImport() does not find frameworks with CocoaPods

Question

Hello here is our Podspec which has a default_subspec and an optional subspec (which won\'t be taken since the default is already set). That subspec has more fe

Answer 1

Can't achieve that by saying that mainSDK is MainTarget and additionalSDK is your AdditionalTarget? What I see is that whatever version you want differently it will be just another target. You can right-click on the original target, select duplicate from the current target and after it you can make the changes you wish to linking frameworks within the Build Phases section.

#check1: check you have use_frameworks! uncommented like this:

# Uncomment this line if you're using Swift
use_frameworks!

#check2: try to delete the ModuleCache if you really think the Framework is there and in the right path. To delete ModuleCache just delete ~/Library/Developer/Xcode/DerivedData/ModuleCache directory, clean the project and delete project-specific derived data just to be sure. When you do the normal cleanup, the ModuleCache directory usually doesn't get rebuilt.

#check3: inspect your framework to see if it contains a Modules folder with a module.modulemap file inside it (right click on your framework > Show In Finder > make sure your modulemap is there)

Answer 2

Short answer: Using #if canImport(Module) would not allow you to achieve what you described in a closed source setup. I see some misunderstanding of how this conditional compilation works.

What I mean is that you've already built a framework. Seems that #if canImport is resolved at a compile time, so it is not dynamic.

When you use already prebuilt mainSDK.framework, the part #if canImport(additionalSDK) was already evaluated. And the result depends on the availability of 'additionalSDK' in the build chain, when it was built (so on your machine when you prepare it for shipping to clients), not when it is linked.

I found someone struggling with a similar issue here: https://flint.tools/blog/finding-a-weak-linking-solution.html

The good news is, that what you want to achieve is possible using weak linking and objective-C interoperability.

I'm working on a short article about the topic, in the meantime, here is an example repository with a working setup, similar to what you described as requirements:

https://github.com/amichnia/Swift-framework-with-optional-frameworks

It supports:

• AdditionalSDK is optional
• MainSDK have classes adopting AdditionalSDK's protocols
• MainSDK knows if additional features are available
• It is all in closed source setup

Update:

I finished an article, which should describe the solution in more details. It is available at https://medium.com/@amichnia_31596/create-a-mostly-swift-framework-with-optional-features-7e8a9ac960f9