Missing required module 'CocoaLumberjack' in iOS 8 app / framework - ios

I'm having a problem with integrating a cocoa pod (CocoaLumberjack in this case) into an iOS app and my own frameworks.
The Podfile looks like this:
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, "8.0"
target "CommonModule" do
use_frameworks!
# CocoaLumberjack wasn't officially released with Swift support yet
# pod 'CocoaLumberjack'
pod 'CocoaLumberjack', :git => 'git#github.com:CocoaLumberjack/CocoaLumberjack.git', :commit => '6882fb5f03696247e394e8e75551c0fa8a035328'
xcodeproj 'CommonModule/CommonModule.xcodeproj'
end
I have a hierarchy of modules (dynamic frameworks) like this:
CommonModule
ModelsModule (has a dependency CommonModule)
And finally, the main app:
MySwiftApp (dependency both ModelsModule and CommonModule)
Now, CocoaLumberjack is used in several files in CommonModule and works as expected. However, every time I do import CommonModule in any file in ModelsModule, I get the following compile error:
~/Developer/ModelsModule/ModelsModule/SomeFile.swift:2:8: error: missing required module 'CocoaLumberjack'
import CommonModule
^
Any idea how to solve this issue?
UPDATE: Some people Recommend to use Carthage. I would like to avoid that, if possible.

You'll also need to ensure that CommonModule.framework and CocoaLumberjack.framework (and any other frameworks) are listed in the Embedded Binaries section of your application target.
All the new iOS 8-style dynamic frameworks must be embedded within your app—even those that you aren't using directly, but that are dependencies of your dependencies—so you might end up seeing references to items you don't recognize.
Incidentally, there is a new Swift-based logging engine called CleanroomLogger that might make things easier if you're having trouble interacting with CocoaLumberjack from Swift.

I am assuming that CommonModule is swift and that your also using CocoaPods 0.36 as I see your calling use_frameworks!. I'm also assuming that you're using the Obj-C version of CocoaLumberjack, and trying to use it with Swift. That use_frameworks! flag tells CocoaPods to generate frameworks of the pods for linking in your Xcode project. So you need to say at the top of your class
import CocoaLumberjack
instead of using the Swift-Bridging-Header
Here is the blog post on cocoapods.org where they talk about the how to author a pod for the new use_frameworks! flag. Scroll down to the part Common Header Pitfalls
It could also be that your podspec creates a dependency to use CocoaLumberjack, and when linked to your project CocoaLumberjack and CommonModules, but Common Module is not referencing it correctly in the library. To get past that you need to refer to it as a framework when you import it into your Objective-C library
#import <CocoaLumberjack/CocoaLumberjack.h>

Related

Using React Native iOS dependency in Objective-c

I currently have the following dependency in a ReactNative project's package.json:
"vital-health-react-native": "file:../packages/vital-health-react-native"
This package has a .podspec with the following dependency:
s.dependency "VitalHealthKit", "~> 0.7.7"
Because I am dealing with HealthKit and background delivery, I need to be able to call a method from this dependency inside the AppDelegate.mm.
I have tried everything to import VitalHealthKit in the .mm and even in the .h, but the dependency is never found. The spec for VitalHealthKit can be found here.
What am I missing?
I’ve not done sub-dependency imports myself but I think one would need to add the pod to the app project’s Podfile like so
pod 'VitalHealthKitRN', path: "#{path_to_packages} /packages/vital-health-react-native/VitalHealthRN.podspec"
Having done that, if one still can’t import VitalHealthKit in the app, it might be necessary to reference VitalHealthKit native pod in the Podfile directly, either in a usual way (that might create a conflict of dependency versions with the RN pod) or using a local relative path, similar to the above. Might also have to use_frameworks! if you don’t already to avoid double-linking vital health kit. Hope this helps.

Is there any downside to setting DEFINES_MODULE = YES in my podspec?

Some Cocoapods, e.g. YLTableView, don't set 'DEFINES_MODULE' => 'YES' as part of their pod_target_xcconfig. This means that, for example, import YLTableView doesn't work in Swift unless you set :modular_headers => true in your Podfile like so:
pod 'YLTableView', '~> 2.2.0', :modular_headers => true
If I'm writing a podspec, is there any reason I shouldn't include DEFINES_MODULE in my config like so?
ss.pod_target_xcconfig = { "DEFINES_MODULE" => "YES" }
It seems to me that this doesn't have any negative effect, and it enables Swift users to consume my library more easily.
There is one known issue (with workarounds): https://github.com/CocoaPods/CocoaPods/issues/7584. It may cause issues for users importing your Objective-C lib headers directly in their Precompiled Headers (*.pch). You may workaround it by including an empty swift file in your lib source files. Chances are there will be a clean fix in a future version of CocoaPods.
Otherwise, there is no real downside. It enables stricter search paths for imports at build time, which means:
either it builds, and it works like before (and as bonus you can now find it with #import in ObjC or import in Swift)
either it doesn't build anymore, and consequently you can't publish the podspec anymore
From the blog post regarding CocoaPods 1.5.0 release:
[...] CocoaPods allowed any pod to import any other pod with un-namespaced quote imports.
For example, pod B could have code that had a #import "A.h" statement, and CocoaPods will create build settings that will allow such an import to succeed. Imports such as these, however, will not work if you try to add module maps to these pods. We tried to automatically generate module maps for static libraries many years ago, and it broke some pods, so we had to revert.
In this release, you will be able to opt into stricter header search paths (and module map generation for Objective-C pods). As a pod author, you can add 'DEFINES_MODULE' => 'YES' to your pod_target_xcconfig. [...]

No such module 'TTTabBarItem' using CocoaPods

I'm trying to extend TTTabBar. When I had the lib in my project, it worked fine but I wanted to keep it as a pod (for maintenance and version management) and extend it as needed.
Since then, I can't import it without errors. Other similar answers (and there is a lot!) didn't help.
My Podfile:
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '8.0'
use_frameworks!
target 'Octoly' do
pod 'RealmSwift', '~> 0.98'
pod 'Mixpanel', '~> 2.9'
pod 'SwiftHTTP', '~> 1.0'
pod 'TTTabBar', '~> 1.1'
end
Here is the code where I try to import it and you also can see that I opened the workspace and TTTabBar is installed:
I have tried lots of things:
Clean / Rebuild
Remove pods and reinstall
Close / Reopen XCode
Add the frameworks to my building settings
Combinations of the previous steps
Here is the Binaries linked where I added TTTabBar:
It is good to know that it works fine for RealmSwift and import TTTabBar works but then it doesn't know what TTTabBarItem is in class TabBarItem: TTTabBarItem {}.
Notice that I've started iOS development 2 days ago so there might be obvious things that I am missing.
You are facing those issues because you are not supposed to import TTTabBarItem (the class you intend to use), but the whole library, in your case import TTTabBar. I think the linker is clever enough to only include the referenced files you use in your code.
So again, use import TTTabBar instead.
More importantly, the developer of the library made a fundamental mistake:
If you take a look at the source files, you can see this:
class TTTabBar: UIViewController { // rest of the code... }
He specified no public access modifier, which basically means that you cannot access it outside of the internal target of the library (you can basically only reference it within the source project/target itself, which is useless to any developer integrating this library).
You have an option though:
Due to the size of the library, you can just go ahead and copy the files into your project (any modifications you would add would always be overwritten if you just used the pod on subsequent pod install calls, so your initial intent to modify the library also doesn't seem to be a viable option).
The problem is actually in the TTTabBar module itself. The TTTabBar and TTTabBarItem classes and its method are not declared as public. So you don't get those classes in your app. The creator of that module should have made those classes and functions public
The solution is to change the local copy if your TTTabBar* files to include public access specifier in the classes and some of its methods and build your project.
E.g.
public class TTTabBar: UIViewController and public class TTTabBarItem: UIButton
You also have to mark 3 other methods as public as well.
In TTTabBar file viewDidLoad
in TTTabBarItem drawRect and init?

Xcode can't see objects added via Cocoapods

I have a podfile defined with the following pods.
platform :ios, '8.0'
use_frameworks!
target 'LifeStream' do
pod 'SSKeychain'
pod 'LiveSDK'
pod 'Alamofire', :git => 'https://github.com/Alamofire/Alamofire.git', :branch => 'swift-2.0'
end
I installed the pods and opened up my workspace. I have found that any usage of Alamofire works fine, due to the Swift 2 version of it importing the project as a framework.
When I try to use SSKeychain classes however, I receive a
Use of unresolved identifier 'SSKeychain`
Same applies with any class I try to use in the LiveSDK.
I have a bridge header in my projects root directory, and the project is configured to use it.
#ifndef Header_h
#define Header_h
#import "SSKeychain/SSKeychain.h"
#import "LiveSDK/LiveConnectClient.h"
#endif /* Header_h */
if I change the #import from
#import "SSKeychain/SSKeychain.h"
to
#import "SSKeychain.h"
Xcode fails to compile because it can't find the file. So I assume that the bridge header is working, as the way my bridge header is built now does not generate any compiler errors caused by not finding the headers.
Bridge Header
Framework Search Paths
I have also added my project root directory to the framework search path.
Linked Frameworks
Lastly I have linked all of the frameworks to the project as well.
Am I missing something with my setup? I have not been able to get Cocoapods to work on my project for nearly a week now. I even created a brand new project thinking that mine was just messed up; which didn't change a thing. I don't know what to do from here in order to resolve this.
Edit
After doing some additional research, I found a blog post showing that you have to include your Pods directory in the User Header Search
A commenter also mentioned that if you are using the newer Cocoapods Frameworks support for Swift, then it will need to include the Frameworks/** search path. I've included both Pods/** and Frameworks/** but still have the same issue.
After some further reading, it's beginning to sound like this is a limitation of Cocoapods. From what I understand, you can't use libraries and frameworks together at the same time in a project.
Once you use use_frameworks! in your Podfile, Objective-C Pods like SSKeychain also get build as frameworks.
The actual problem is that only module imports work in the bridging header when using frameworks. Also, you might want to get rid of the bridging header entirely, as it is unnecessary when using frameworks, they can be imported directly in Swift.
To clarify what you should do to make it work:
Be sure to have use_frameworks! in your Podfile
It doesn't matter if you have a Bridging header or not. Leave it untouched
In your SWIFT file just use import Podname
That's it, you're good to go. Of course it may happen that you need to clean your project or maybe delete the derived data folder. Build and you can use it.
If you're not using any swift pods,
Try removing the use_frameworks! on your Podfile.
Run pod install on terminal.
Clean & Build !
I spent almost half an hour fixing it, I tried adding those paths on Search Paths or re-adding the bridging-header but the error was the same.
Therefore, in my case, bridging header file was not the problem, its on the Podfile .
I hope it helps!

Using Cocoapods in Cocoa Touch Framework?

I'm developing a framework that requires use of AFNetworking. So I started by creating a new and shiny Cocoa Touch Framework and as usual I created a pod file with the following stuff in it:
source 'https://github.com/CocoaPods/Specs.git'
pod 'AFNetworking', '~> 2.5'
Obviously on a normal project this would create the workspace and everything would be super smooth... But since I picked Cocoa Touch Framework I am not able to import AFNetowrking.h into my ProjectName.h. The error I'm getting is:
Include of non-modular header inside framework module...
So I actually looked this up! It seemed that all I need to do is to go to my build settings and set Allow Non-modular Includes In Framework Modules to yes and my problem will be solved... but that didn't help either.
Another thing I tried doing was to also set the target membership of AFNetworking.h header file to public. But that didn't resolve the issue and I'm still getting the same error.
I'd appreciate if anyone can give me a step by step mini guide on how to do this?
It is worth mentioning that I'd like to be able to use the AFNetworking library in swift as well.
When importing a module using cocoapods in your source code you must import it like
#import <AFNetworking.h>
rather than
#import "AFNetworking.h"
Here's my pod file:
source 'https://github.com/CocoaPods/Specs.git'
pod 'AFNetworking', '~> 2.5'
use_frameworks!
You need to make sure you install the beta version of CocoaPod (0.36). The only issue with this is that you will be able to run it on iOS 7 but it will not pass the validation on apple application submission (keep that in mind).

Resources