In my project I've around 20-30 PODS and all of them are in OBJECTIVE-C.
In some of the pods I've changed some pieces of code due to requirement.
Now I want to add a pod which is only written in swift. Is it possible to use swift for only that specific pod ? I don't want to use "use_framework" as it will force all other pods to use static frameworks.
Currently use_framework! is either all or none. There is currently an open issue to change that.
Swift static library support will be added in CocoaPods 1.5.0 so that is likely to be the soonest route to a solution for you, but still a ways off.
With the release of cocoapods 1.5.0. Not it's possible to use only a single swift pods. From official docs
you can add use_modular_headers! to enable the stricter search paths and
module map generation for all of your pods,
or you can add :modular_headers => true to a single pod declaration
to enable for only that pod.
By this we can improve store submission time. Here is the official doc page Cocoapods 1.5.0.
Related
Started with an Objective-C and Swift mixed project...
Gradually I have converted all of the code over to Swift. Quite happy about that.
I've now turned my attention to all Cocoapod dependencies, and all the obvious ones have been either removed or swapped for Swift equivalents...
However, I am using Google Firebase Cocoapods (Objective-C) and cannot find a Swift alternative for it.
(I'm using Firebase for app analytics and help with push notifications)
Am I missing a trick here? Is there a good alternative for Firebase that is 100% Swift?
I know some may suggest I just keep Firebase in Obj-C, but my thinking is if I can 100% convert my project over to Swift I will be future-proofing it for a good few years.
Firebase doesn’t have a pure Swift SDK. I don’t think Google cares enough about iOS dependancies.
Also, technically if you’re looking to change proof iOS code, ObjC is “better” because unlike Swift it has no versioning.
But! I can’t recommend anyone to write a project in ObjC just because it might require less code maintenance.
I had the same problems when working in iOS 14 with Firebase pods. I ended up figuring out that the issue was only coming from the general 'Firebase' pod.
Basically, DON'T use:
pod 'Firebase'
And use the specific pods instead:
pod 'Firebase/Auth'
pod 'FirebaseCore'
pod 'Firebase/Firestore'
pod 'FirebaseFirestoreSwift'
pod 'Firebase/Storage'
pod 'Firebase/Analytics'
pod 'Firebase/DynamicLinks'
When you import frameworks to a file, import the specific pod. (ie. "import FirebaseCore" and not "import Firebase"). I would assume Google will eventually update the general pod to be compatible.
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. [...]
I have used use_frameworks! in CocoaPods Podfile many times. I just wonder why do we use it? I couldn't get the straight forward answer of it.
Example:
platform :ios, '8.0'
use_frameworks!
target "CityWhether" do
pod 'Alamofire'
pod 'SwiftyJSON'
end
use_frameworks! tells CocoaPods that you want to use Frameworks instead of Static Libraries. Since Swift does not support Static Libraries you have to use frameworks.
In another answer, I explained the differences between Static Libraries and Frameworks:
Cocoa Touch Frameworks
They are always open-source and will be built just like your app. (So
Xcode will sometimes compile it, when you run your app and always
after you cleaned the project.) Frameworks only support iOS 8 and
newer, but you can use Swift and Objective-C in the framework.
Cocoa Touch Static Libraries
As the name says, they are static. So they are already compiled, when
you import them to your project. You can share them with others
without showing them your code. Note that Static Libraries currently
don't support Swift. You will have to use Objective-C within the
library. The app itself can still be written in Swift.
Sources: My other answer | AddThis.com Blog
use_frameworks! tells cocoa pods to use dynamic libraries, and was very prevalent at one point due in particular to swift not supporting static libraries, meaning there was no choice - however you often don't need use_frameworks! anymore.
As of Xcode 9 beta 4, and CocoaPods 1.5.0, swift static libraries are now supported. The main advantage is faster app startup times, particularly if you have a lot of pods - iOS 10 and 11 are not the fastest when you have many dylibs.
CocoaPods 1.5.0 was released in early April 2018, so you may need to upgrade to get it: sudo gem install cocoapods.
I've found several pods that don't work correctly with static libraries yet though, so your mileage may vary.
use_frameworks! declares that you want to use dynamic frameworks, instead of static libraries.
With Xcode 9.0 and CocoaPods 1.5.0 released, you could use static libraries with swift if you do not use use_frameworks!.
One problem with use_frameworks! is that all your framework in Pods/Products are frameworks.
Here is a related article: Basic overview of static and dynamic frameworks on ios
Cocoapods use_frameworks
Cocoapods[About] use_frameworks! is responsible for the type of binary:
if use_frameworks! is present - dynamic framework
if use_frameworks! is not present - static library
use_frameworks! has a reflection in Mach-O Type[About] in a corresponding target of Pods project.
Timeline:
CocoaPods 0.36 introduced use_frameworks! which you had to use for Swift pod
CocoaPods 1.5.0 and Xcode 9 allowed you to have a choice
[Vocabulary]
Adding
use_frameworks!
in the Podfile means that we want the listed frameworks to be dynamically installed instead as static frameworks.
So my situation specifically uses the Objection dependency injection library. However, I believe this could be an issue for other libraries as well.
Platform
iOS 8.0 Xcode 6.1.1. Cocoapods 0.35. Objective-C.
Set up:
I have 4 projects. 3 universal frameworks and a test app (I'm creating an api). The test app does not utilize cocoapods (though some other app might).
All three of my frameworks need to use injection. I created a pod file that looks like
workspace 'workspace.xcworkspace'
platform :ios, '8.0'
xcodeproj 'path/to/proj/one'
xcodeproj 'path/to/proj/two'
xcodeproj 'path/to/proj/three'
target :Project1 do
pod 'Objection', '1.4'
end
target :Project2 do
pod 'Objection', '1.4'
end
target :Project3 do
pod 'Objection', '1.4'
pod 'SDWebImage', '~>3.7.1'
end
Problem
When I use this set up singletons don't work in Objection. However, they only don't work if they (the singleton class) is defined in project 1 and then I call [JSObjection createInjector]; in project 2 (the projects don't make a difference, it is that create is called in a different project to the definition).
Current theory
After battling with this for a while I believe it is due to the warning along the lines of:
Objection is defined in Project 1, Project 2 and Project 3.
Which one will be used undefined.
So when the class registers itself with the injection system (e.g through objection_register_singleton(ClassX)). It is using the JSObjection definition from its project, which might not be the one being used for a class that injects it (e.g. objection_requires_sel(#selector(myClassXObject))).
Question
I want to be able to use the iOS frameworks setup as, from what I understand, it is better overall than static libs. However, I also want to be able to use Cocoapods (and have any app, that uses my api, use Cocoapods).
How do I either a) share one definition across multiple frameworks or b) setup a framework as a Cocoapod (I've seen that this is being developed).
I would love to be able to keep the frameworks linked through the xcode workspace so when one is built the frameworks it depends on are also built. Though having said that, my api will probably become a Cocoapod at some point anyway.
Thanks in advance (and for reading to here)
Indigo
Im using a couple of libraries I found on GitHub, and I was wondering is there a way to know when a third party library used in an app has been updated? For example, a bug fix.
Must we continuously visit the users repository to find out for our selfs, or does using a dependency manager like Cocoa Pods have this functionality?
Thanks in advance.
Cocoa pods allows you to manage third party library, one feature it has it is pod outdated which checks for new releases of library's and also check if a project has new commits
more info on cocoa pods, see link
example 1 (library with releases only):
say you have AFNetwoking in your project using cocoapods with the following syntax: pod "AFNetworking" if you wanted to just check for updates do pod outdated, or to update the library if there are releases you would do pod update
example 2(library with most recent commits):
there times were you want to get most recent commits regardless of if it stability. On cocoapods you can do pod 'AFNetworking', :git => 'https://github.com/AFNetworking/AFNetworking.git'. this gets the most recent commit on git
CocoaPods handles this. Just type pod install every once in a while. It will fetch all available updates for you... I've been using CocoaPods for a long time without problems... You can even create private pods or development pods if you need to.