Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please support static libraries for Swift #6899

Closed
atomicbird opened this issue Jul 25, 2017 · 44 comments

Comments

@atomicbird
Copy link

commented Jul 25, 2017

The release notes for Xcode 9 beta 4 note that

The new build system supports static library targets which contain Swift code. Debugging applications which use Swift static libraries may require having a complete set of build artifacts (in their original location) available. (33297067)

Also a tweet from Daniel Dunbar of Apple's dev tools team notes that this also applies to the old build system.

To date CocoaPods has (by necessity) required use_frameworks! for Pods written in Swift. This is no longer necessary. Since using a lot of frameworks can slow down app launch times, it would be really nice to see a future version of CocoaPods build with static libraries for Swift Pods.

@endocrimes

This comment has been minimized.

Copy link
Member

commented Jul 25, 2017

#6811 and CocoaPods/Core#386 add support for this and will hopefully land in CocoaPods 1.4.0

@atomicbird

This comment has been minimized.

Copy link
Author

commented Jul 25, 2017

Thanks, I guess I didn't search hard enough before posting.

@orta

This comment has been minimized.

Copy link
Member

commented Jul 25, 2017

Closing as a dupe 👍

@orta orta closed this Jul 25, 2017

@dnkoutso

This comment has been minimized.

Copy link
Contributor

commented Jul 25, 2017

Are those PRs actually the same? Static framework != static library, unless we expect the PRs will be updated to support static libraries.

@orta

This comment has been minimized.

Copy link
Member

commented Jul 25, 2017

Ah yeah, good point, 👍

@orta orta reopened this Jul 25, 2017

@keith keith referenced this issue Jul 25, 2017

@dnkoutso dnkoutso added this to the 1.4.0 milestone Jul 25, 2017

@segiddins

This comment has been minimized.

Copy link
Member

commented Jul 25, 2017

@dnkoutso

This comment has been minimized.

Copy link
Contributor

commented Jul 25, 2017

Most likely............do we want to do a check for the current xcode version used?

@segiddins

This comment has been minimized.

Copy link
Member

commented Jul 25, 2017

You mean check the project attribute's last upgrade check?

@dnkoutso

This comment has been minimized.

Copy link
Contributor

commented Jul 25, 2017

Yeah anyway to be able to check the current version since this is support in Xcode9b4 currently, would we want to disable this check for Xcode 8 today?

@keith

This comment has been minimized.

Copy link
Member

commented Jul 26, 2017

It appears that currently just deleting that check is not enough. It looks like the first issue here is on the Swift side of things we need to set the SWIFT_INCLUDE_PATHS to point to the "$PODS_CONFIGURATION_BUILD_DIR/Foo" directory, which contains the Foo.swiftmodule which is inferred when the binary is inside a .framework (see here)

@keith

This comment has been minimized.

Copy link
Member

commented Jul 26, 2017

The next problem I've noticed with our project is that, since we have the same pods for multiple platforms such as Foo-iOS and Foo-watchOS, the PRODUCT_MODULE_NAME, which in this case defines the Foo_iOS.swiftmodule directory mentioned above, needs to match with the import from other modules. So in this case instead of being set to $(PRODUCT_NAME:c99extidentifier), it needs to be explicitly set to Foo

@keith

This comment has been minimized.

Copy link
Member

commented Jul 26, 2017

The next problem in our project is when you have a Swift pod depending on an Objective-C pod, since no umbrella header and modulemap are generated by CP for the Objective-C pod, your swift code cannot import it. To work around this you must create a module.modulemap in the same directory as your libFoo.a and it must contain a path to an umbrella header (which the library may or may not provide for you)

@keith

This comment has been minimized.

Copy link
Member

commented Jul 26, 2017

Something others might find off-putting when going through this process (although I consider it a feature) is that with dynamic frameworks, because of the umbrella headers that are generated by CocoaPods, for iOS, anything depending on a framework from CocoaPods implicitly has UIKit imported globally. This means you could have a file in your project that imports one of your pods, without importing UIKit (or Foundation) and still use types from those frameworks. This means when converting to static libraries, since this is no longer particularly the case, code that is unintentionally missing those imports may not compile until you add them.

@paulb777

This comment has been minimized.

Copy link
Member

commented Jul 26, 2017

I consider the implicit UIKit import a CocoaPods bug (see closed #6816), since it makes CocoaPods code less portable. There should at least be an option to disable it.

However, with PR #6772, the static frameworks that wrap static libraries work just like dynamic frameworks, including the UIKit import.

@piercifani

This comment has been minimized.

Copy link

commented Aug 2, 2017

No pressure here, but is there any ETA on the 1.4.0 version which is where this issue would land?
Ideally with iOS 11 launch?

@endocrimes

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

@keith So the dani_static_swift branch on CocoaPods should theoretically build with Swift static libs now. If you could give it a try on the Lyft project and let me know where it breaks, that would be great. The handling of headers is pretty hacky right now, but I'll fix that up in time.

@endocrimes endocrimes referenced this issue Aug 18, 2017
7 of 7 tasks complete
@b-ray

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2017

So #6811 brought support for static frameworks (in podspecs), and the PR #6966 adds support for static swift libraries.

I tried the latter approach in a fairly big iOS project, but failed to build the project correctly.
I then tried to build what I’d call “Static Swift Frameworks” (the nomenclature of this topic still confuses me), so basically I built the project with use_frameworks!, but I made a few modifications in CocoaPods code, so that the frameworks are actually built as static frameworks (by setting the build setting MACH_O_TYPE to staticlib and updating the generated build phases of the main target), and the project built successfully.

As this was rather easy to implement and solved a really big problem for us (we’ve recently hit a hard limit of dynamic frameworks), and it required zero modifications to our source-code, I’m curious if a PR implementing this feature would be accepted? My concern is that this would probably require a new setting similar to the use_frameworks! setting, and only works with Xcode 9.

@mwoollard

This comment has been minimized.

Copy link

commented Oct 14, 2017

So this feature is to be able to publish pod with swift source code as a static framework? What about integrating source swift pods statically? For the latter I have experimented with post_install script to effectively do this (by removing the dynamic linking and including the the object files created building the dynamic framework into the link phase - but would great if this was a feature. Have a reasonably complex setup ideally would like to be able to result in a single binary - can elaborate and happy to help / test as this moves forward. Mark

@endocrimes

This comment has been minimized.

Copy link
Member

commented Oct 14, 2017

@mwoollard This feature (and open PR) is for integrating Swift libraries as source static libraries - Support for Swift Static Frameworks landed in 1.4.0.beta.1.

@paulb777

This comment has been minimized.

Copy link
Member

commented Oct 14, 2017

@mwoollard Some Swift-specific capabilities for static frameworks missed beta.1, but are in now in master branch. See a simple example in https://github.com/mukeshthawani/TestStaticFramework, along with corresponding issue #7117 and PR in #7135.

Let me know if you find anything missing.

@notedit

This comment has been minimized.

Copy link

commented Nov 17, 2017

any progress?

@kacper1703

This comment has been minimized.

Copy link

commented Jan 22, 2018

It's been 84 years...

@dnkoutso

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2018

This is the primary feature of 1.5.0 since now 1.4.0 shipped.

Being snarky won't accelerate feature development. If anyone wants to see this feature faster implemented then please attempt to spend the time to do so. You can find the first PR here #6966.

If you cannot wait then just switch to another system that supports it.

@kacper1703

This comment has been minimized.

Copy link

commented Jan 22, 2018

I meant no disrespect, I like using CP very much, it's just been a long time since last activity related to this. Looking forward to this update :)

@Coeur

This comment has been minimized.

Copy link
Contributor

commented Mar 28, 2018

This is the primary feature of 1.5.0 since now 1.4.0 shipped.

@dnkoutso Can you clarify in your blog that it WASN'T actually released with 1.4.0?
http://blog.cocoapods.org/CocoaPods-1.4.0/

@kacper1703

This comment has been minimized.

Copy link

commented Mar 28, 2018

That's weird because after updating to 1.4.0 (from 1.3.1) my project build time has reduced from ~5min to ~40s 😵 Is that placebo?

@msalman

This comment has been minimized.

Copy link

commented Mar 30, 2018

Hey guys, as now cocoapod 1.5 beta is released so I am assuming I can have my project using both objective c libraries and as well as some swift libraries via pod, but I am not been able to find any example pod file for doing that. Can someone share a sample pod file to achieve this.

@Coeur

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2018

@msalman: simply remove use_frameworks! from the Podfile. https://stackoverflow.com/a/49347198/1033581

@Sega-Zero

This comment has been minimized.

Copy link

commented Mar 31, 2018

Is it possible to mark some of pods as dynamic frameworks?

@alper

This comment has been minimized.

Copy link

commented Jun 22, 2018

I removed use_frameworks! but ran into a No such module. What is the cause of that?

@macbellingrath

This comment has been minimized.

Copy link

commented Jul 18, 2018

@alper did you resolve your issue? If so, how did you do so?

@alper

This comment has been minimized.

Copy link

commented Jul 18, 2018

@macbellingrath I just gave up for now and will try again some time in the near future.

@Coeur

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2018

@alper, @macbellingrath, for ObjC pods, you need to add :modular_headers => true. Example:

pod 'SSZipArchive', :modular_headers => true

It's explained in http://blog.cocoapods.org/CocoaPods-1.5.0/

@alper

This comment has been minimized.

Copy link

commented Aug 27, 2018

Still breaks for me on SAMKeychain and FirebaseCore.

@paulb777

This comment has been minimized.

Copy link
Member

commented Aug 27, 2018

@Coeur No reported FirebaseCore integration issues at https://github.com/firebase/firebase-ios-sdk/issues. As far as I can tell the same is true on StackOverflow.

@Coeur

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2018

@paulb777

This comment has been minimized.

Copy link
Member

commented Aug 27, 2018

@Coeur Do you really consider it a Firebase issue when someone locks their Podfile to an old version and want to add a new component that requires a newer version of that dependency? There's nothing new about problems like that and it's an example of CocoaPods doing the right thing and catching a bad configuration as early as possible. If anything, CocoaPods should output more information about how to diagnose and fix the issue.

@Coeur

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2018

@paulb777 looking more closely, you're right about it. My apologies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.