4

Because CocoaPods 0.36 are availbable to anyone and they are now coming with Swift and Frameworks support I have one question that is bothering me today...

I create Podfile in my project directory, fill it with:

source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '8.0'

pod 'AFNetworking'
pod 'SwiftyJSON'

And run pod install as usual... You know this story. But when I open my .xcworkspace and go to any ViewController and import SwiftyJSON it just works but when I try to do the same thing with AFNetworking I get No such module 'AFNetworking'. Of course, I can create a Bridging-Header and import it with the Objective-C way but when I read this blog post I can see:

To use this subspec in Swift, without a generated umbrella header, you would need to create a bridging header and use an import like #import <AFNetworking/AFNetworking+UIKit.h. With the generated umbrella header, you just need to import AFNetworking, if you have the subspec included in your Podfile.

Correct me if I'm wrong but I suppose that manual Bridging-Header is no longer needed if we add libraries with CocoaPods, right? So, why this isn't working?

cojoj
  • 6,405
  • 4
  • 30
  • 52

1 Answers1

14

As I thought... This example which I provided in OP is incorrect... Well, basically it's correct because it's working like it should. Let me show you a counter example.

I have a Swift project but I want to use only Objective-C pods (AFNetworking, SSPullToRefresh etc.). Now we have some troubles because when you provide those Objective-C pods in Podfile they'll be added to Pods target as a static libraries. You probably now that CocoaPods are now switching to Frameworks (If you want to know the difference please read this question). Back to topic... There are two possible solutions to this conflict sitation:

  1. You manually create YourProject-Bridging-Header.h and #import those libraries... This is the old way used even before Swift integration.
  2. You include this magic use_frameworks! method call inside your Podfile. By doing this you force CocoaPods to create frameworks instead of static libraries.

Now, let me explain why you'd prefer the second solution... As OP states, CocoaPods now automatically create Umbrella Headers (learn about them). It's the convenient way for you to skip manual creation of bridging header.

I've found a solution here so without this post I would probably still be struggling with this problem. Cheers to the author!

Community
  • 1
  • 1
cojoj
  • 6,405
  • 4
  • 30
  • 52
  • From your reading of that document, did you see a means of using the cocoapods auto generated umbrella file as your preferred means for use in *Obj-c* projects? Ie. configure cocoapods to generate the bridging header as `AFNetworking.h` instead of `Pods-iOS Example-AFNetworking-umbrella.h`, so that it would always track the set of public headers - a "single point of truth"? From my reading it is only intended for visibility by Swift code. – Chris Conover Jan 15 '15 at 20:08
  • The umbrella header is precisely created for Swift. So, there is no need to use it with Objective-C projects... Why would you? I was only struggling with mixed projects where the main language I write is Swift and some of Pods can be Objective-C libraries. – cojoj Jan 16 '15 at 06:26
  • The umbrella file is a concept that relates to frameworks, and fameworks are / were new to Obj-c as well. The umbrella file is just the grand summary of all public headers in the framework, and is the `MyFramework.h` in `#import `. Under the hood, cocoapods generates a new and uniquely named umbrella file and registers it in the modulemap to make it available via `@import MyFramework`. The naming and convention of this is the subject of debate in https://github.com/CocoaPods/CocoaPods/issues/3092. It is how both Swfit and Obj-c code find Obj-c symbols. – Chris Conover Feb 11 '15 at 00:29