Cocoapods: pod lib lint fails for Swift-only vendored frameworks

[yanniks]

• [x] I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

Executed pod lib lint on a Podspec that only contains a reference to a vendored framework, no source files. swift_version is specified.

What did you expect to happen?

A dummy project with Swift files should be created, linting should succeed. Since I specified a swift_version I expected that the tests run against a Swift project.

What happened instead?

The created dummy project contains an Objective-C main.m file. The build fails since Xcode doesn't link to Swift libraries on Objective-C only projects.

Errors:

- NOTE  | [iOS] xcodebuild:  ld: warning: Could not find auto-linked library 'swiftFoundation'
    - NOTE  | [iOS] xcodebuild:  ld: warning: Could not find auto-linked library 'swiftMetal'
    - NOTE  | [iOS] xcodebuild:  ld: warning: Could not find auto-linked library 'swiftDarwin'
    - NOTE  | [iOS] xcodebuild:  ld: warning: Could not find auto-linked library 'swiftUIKit'
    - NOTE  | [iOS] xcodebuild:  ld: warning: Could not find auto-linked library 'swiftObjectiveC'
    - NOTE  | [iOS] xcodebuild:  ld: warning: Could not find auto-linked library 'swiftCoreFoundation'
    - NOTE  | [iOS] xcodebuild:  ld: warning: 
    - NOTE  | [iOS] xcodebuild:  ld: warning: Could not find auto-linked library 'swiftCoreImage'
    - NOTE  | [iOS] xcodebuild:  ld: warning: Could not find auto-linked library 'swiftQuartzCore'
    - NOTE  | [iOS] xcodebuild:  ld: warning: Could not find auto-linked library 'swiftCoreGraphics'
    - NOTE  | [iOS] xcodebuild:  ld: warning: Could not find auto-linked library 'swiftCore'

The issue is resolved as soon as the project contains one Swift file.

CocoaPods Environment

Stack

   CocoaPods : 1.6.1
        Ruby : ruby 2.3.7p456 (2018-03-28 revision 63024) [universal.x86_64-darwin18]
    RubyGems : 2.5.2.3
        Host : Mac OS X 10.14.4 (18E226)
       Xcode : 10.2 (10E125)
         Git : git version 2.21.0
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib
Repositories : Corporate - oururl
               master - https://github.com/CocoaPods/Specs.git @ d3011e488a245518137d5608fe6c35a40355caa5

Installation Source

Executable Path: /usr/local/bin/pod

Plugins

cocoapods-deintegrate : 1.0.2
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.3.1
cocoapods-try         : 1.1.0

Project that demonstrates the issue

I figured out that the problem only occurs on static frameworks (Mach-O Type => Static Library). Therefore, I created this repository with the precompiled framework and the Podspec and this one for the example framework - for that, the only thing I did was adding an example Swift file and changing the framework type to static. I've built a fat library to make it compatible to both x86_64 and arm, but the problem also occurs when just copying the compiled framework out of Xcode into the Podspec folder.

[dnkoutso]

Do you have a quick sample you can upload? Most likely a bug.

[yanniks]

Hi @dnkoutso , thanks for the quick reply. I figured out that the problem only occurs on static frameworks (Mach-O Type => Static Library). Therefore, I created this repository with the precompiled framework and the Podspec and this one for the example framework - for that, the only thing I did was adding an example Swift file and changing the framework type to static. I've built a fat library to make it compatible to both x86_64 and arm, but the problem also occurs when just copying the compiled framework out of Xcode into the Podspec folder.

[megastep]

I believe this is related to a new behavior in Swift 5 / Xcode 10.2, where the standard Swift dylibs are now expected to be system-wide available on devices running iOS 12.2 and above. This may depend on which version of iOS you target.

It was previously possible to work around this without adding a dummy Swift file, but I haven't found a way to do it any other way with Xcode 10.2.

[yanniks]

Hi @megastep , thanks for your reply. In that case, I would expect the build to be successful when the SDKROOT is set to iphonesimulator12.2 / s.platform is set to :ios, "12.2", which it isn't unfortunately. I guess the easiest way would be to update this definition and add a check whether a Swift version is specified in the Podspec, I just don't know if this is desired by the core developers. https://github.com/CocoaPods/CocoaPods/blob/bb984b7aef0a3b0f993e55ee725a2104ccd0e010/lib/cocoapods/target/pod_target.rb#L253

[megastep]

Believe me, Swift 5 broke a lot of things and I'm at the point that I'm not even sure if we can use CocoaPods anymore with certain frameworks. I'm probably gonna be submitting bug reports of my own here...

[yanniks]

@dnkoutso were you able to reproduce the bug?

[dnkoutso]

@paulb777 should we be creating a main.swift or so file if the pod uses swift?

[dnkoutso]

@yanniks yes I can repro. This is a case in which your pre-built framework contains Swift and CocoaPods does not detect that.

[dnkoutso]

Workaround is to include a .swift file in your pod.

[dnkoutso]

I guess the easiest way would be to update this definition and add a check whether a Swift version is specified in the Podspec, I just don't know if this is desired by the core developers.

We can probably rely on that if the pod contains no sources.

[dnkoutso]

@yanniks why was the original report for static frameworks only? I believe i was able to repro for dynamic too.

[yanniks]

@dnkoutso when I was investigating this issue for the sample, I was only able to reproduce it with static frameworks. But in that case, of cause I can re-edit the title to be generic again. :-)

[dnkoutso]

Given there is a workaround available here we believe we need to slightly extend the DSL in order for my PR to land properly.

Right now the swift_versions DSL is only applied at the root but we want to expand it so it can be applied at each specification (subspecs, test specs and app specs).

The workaround provided here should be sufficient to overcome this issue.

[dnkoutso]

We've talked about this further offline and it seems the workaround mentioned here might be the preferred solution. Your app will need to link Swift somehow in order for this to work.

If there are no hard objections I am going to close this and my accompanied PR.

[stale[bot]]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem :+1:

[acecilia]

Hi @dnkoutso:

We can probably rely on that if the pod contains no sources.

How can I workaround this issue if I am trying to distribute a static swift framework that does not contain sources?
When adding a swift file to it I am experiencing the issue explained in https://github.com/CocoaPods/CocoaPods/issues/8957.

Seems to me that at the moment there is no way to distribute a swift static framework using cocoapods. Any help will be very much appreciated.

[dnkoutso]

Seems like it is an issue that we should perhaps resolve with #8957

[acecilia]

Not so sure about that.

The problem from what I understood is that pod lib lint creates an objective-c xcode project even when the vendored_frameworks contains swift frameworks, so the swift libraries are not linked.

So, the question is more about: how to indicate to pod lib lint that it has to generate a swift xcode project?

1. So far, the only solution is to add a dummy swift source file to the pod. But this results now in https://github.com/CocoaPods/CocoaPods/issues/8957.
2. Why not modify cocoapods, so pod lib lint generates a swift xcode project also when the swift_version parameter is present in the podspec? I see you opened https://github.com/CocoaPods/CocoaPods/pull/8762 implementing this, and then declined it.

Then, what is the proper solution? Add extra information in the DSL? Or why not include and option, so it is possible to push without lint https://github.com/CocoaPods/CocoaPods/issues/5801?

At the moment seems completely impossible for me to release my swift static frameworks using cocoapods, because one of these options will get on the way:

1. Lint will fail (if I do not add a dummy swift file).
2. Consuming the pod will fail (if I add a dummy swift file).
3. I can not push to my local spec repo without lint.

[acecilia]

Also, consider that, if the framework generation is done with carthage and the pod push is part of an automated flow, adding a dummy swift file may not be possible.

[acecilia]

I think this issue also does not show up if one of the dependencies in the podspec contains a swift file.

Another way I found to work around this issue is to add tests to the podspec, having those tests depend on a swift pod, without adding any source files, and execute pod lib lint with the option --skip-tests. For example, in your podspec add:

# Adding tests with a swift dependency is a workaround in order to make pod lib lint work
# See: https://github.com/CocoaPods/CocoaPods/issues/8649
spec.test_spec 'Tests' do |spec|
  spec.dependency 'Result', '~> 5.0'
end  

The main benefit of adding the swift dependency into the tests is that it will not be downloaded when consuming the pod.

[sirghi]

Hi. Are we in a position to check the swift_version in the posdpec for this yet?

I have such a situation with 2 subspecs with vendored frameworks, one with a dependency and another without, the second giving this problem.

[dnkoutso]

We hit this issue internally and re-read a lot of the content here. This is a valid concern and right now it is impossible to validate Swift only frameworks.

I am re-opening as we will revive my fix with an additional check for 1.10 release.

[dnkoutso]

Since 1.10 was in RC I am pushing this to 1.11.

[dnkoutso]

Fixed with https://github.com/CocoaPods/CocoaPods/pull/10108 for 1.11.

[Niko-r]

Hello all,
I'm just writing this message because I am facing this pod validation issue for a Swift static framework, on CocoaPods 1.10.0.

So I just want to @yanniks for having created this issue, and thank you @dnkoutso for having looked into this and provided follow-up 👍

(we don't always see emojis reactions, so that's why I wanted to give you a thank message)