Compilation error "Carbon is not available when building for iOS Simulator"

[nonameplum]

Checklist

• This is not a Apple's bug.
• Reviewed the README and documents.
• Searched existing issues for ensure not duplicated.

Expected Behavior

The example application compiles without the error message

Current Behavior

~/Carbon/Examples/Example-iOS/Example-iOS.xcodeproj Carbon is not available when building for iOS Simulator.

Steps to Reproduce

Install Xcode 11.4
Follow the steps to run the example app from the README.

Reproducible Demo Project

The as is Example app from the Carbon repository.

Environments

• Carbon version:
  https://github.com/ra1028/Carbon/tree/1.0.0-rc.6

• Swift version:
  5.2

• iOS version:
  11.0, 12.0, 13.0

• Xcode version:
  11.4

• Devices/Simulators:
  Both

• CocoaPods/Carthage version:
  CocoaPods 1.9.1

I was thinking that this is related to CocoaPods only but seems like the Example app from the Carbon that is not using CocoaPods to resolve dependencies has the same issue in Xcode 11.4.

[bofeizhu]

I think there is a name conflict with macOS's Carbon framework. The only solution might be renaming the framework to something else.

[ra1028]

@nonameplum

Thanks for your reporting.

I fixed this problem by here.
Please check it with the master branch.

[nonameplum]

@ra1028 Yes, the issue is fixed in the example app but I'm not sure how this can be fixed with cocoapods. Any thoughts?

CocoaPods/CocoaPods#9650

[bofeizhu]

@nonameplum @ra1028 I think we probably have to rename Carbon to something else to fix the CocoaPods issue. You can see my comment above.

[nonameplum]

@bofeizhu You are correct. After the framework rename problem is solved.

[ra1028]

@bofeizhu @nonameplum

I created a sample project and tried to install Carbon with CocoaPods and it worked, can you tell me more about the error?

Anyway, changing the framework name is too big a breaking change.
I think it's a bug depends on Xcode11.4.0 or CocoaPods, as there are no problems with Carthage.
I was disappointed in the overly throwaway response of the CocoaPods maintainers.
I think that should be pursued more on the CocoaPods side.

The workaround you can do now is to rewrite the framework name in the CocoaPods post-install script, or use Carthage.

[bofeizhu]

@ra1028 The issue only happens when Carbon is used as a dependency in another pod. To reproduce, you can create a development pod and add Carbon as a dependency in its podspec. Then install the development pod to a project, the error would occur. I agree changing the name is too big at this point. But considering Apple could potentially ban the use of Carbon (their old 32-bit UI framework) entirely by filtering out frameworks by name in the future, it may still worth the hassle now. Maybe some subtle change like CarbonX? CarbonKit?

[Goktug]

Same problem +1

[lnfnunes]

I just discovered this lib and thinking to suggest the adoption in my company's project, wondering if this could be a problem since we use Cocoapods in the main project and on the frameworks (modules) as well!? 💭

[nonameplum]

@lnfnunes If you would like to use this framework in one of your frameworks then you will get this issue.

[lnfnunes]

Hum ok! 😞
Thanks @nonameplum

[Goktug]

@bofeizhu @nonameplum

I created a sample project and tried to install Carbon with CocoaPods and it worked, can you tell me more about the error?

Anyway, changing the framework name is too big a breaking change.
I think it's a bug depends on Xcode11.4.0 or CocoaPods, as there are no problems with Carthage.
I was disappointed in the overly throwaway response of the CocoaPods maintainers.
I think that should be pursued more on the CocoaPods side.

The workaround you can do now is to rewrite the framework name in the CocoaPods post-install script, or use Carthage.

@ra1028 Please, reconsider for renaming pod name. Currently, the pod is release candidate, before releasing a stable version of it, you can change the name. Maybe, it can be causing more problems to be used the Apple library name in the future.

[ra1028]

What hesitates me is that, as mentioned here, it's a failure that only occurs with the limited conditions, and there are many solutions that users can do.
In my opinion, the correct decision is to keep the Carbon side of the equation as it is now, and the user should do workaround only when failing on the edge case.

[bofeizhu]

@ra1028 I think the same error would happen to any Mac-Catalyst projects using CocoaPods. It will not be a limited condition when Catalyst getting popular in the future.

[ra1028]

@bofeizhu

same error would happen to any Mac-Catalyst projects

Have you actually faced this phenomenon?