Since I'm building using FireStore and few other Firebase library, the build time has doubled down. I'm wondering if there is a way to avoid compiling it every time I clean & build my project.
Don't clean & build, just build. ;)
Disclaimer: Before doing releases, a clean build is preferred, of course.
UPDATE with better answer: Use cocoapods-binary plugin.
https://guides.cocoapods.org/plugins/pre-compiling-dependencies.html
One solution for this is to not give Xcode the chance to re-compile code. CocoaPods Binary will pre-compile your Pods during pod install, and then add the binary assets (e.g. .framework files) into the generated Xcode projects instead of the source code.
Like this.
plugin 'cocoapods-binary'
use_frameworks!
target "MyApp" do
pod "NeededPod", :binary => true
end
For anyone stumbling on this post, we finally found a way to optimize Firestore build time while still using cocoapods.
We are using THIS REPO
It's a precompiled Firestore iOS SDK xcframework files extracted from the Firebase iOS SDK repository release downloads, tagged by Firebase iOS SDK version and presented as a consumable podspec.
Why
Currently the Firestore iOS SDK depends on some 500k lines of mostly C++, which when compiling as part of your Xcode build takes a long time - even more so in CI environments.
Related
I have an existing project which uses Cocoapods, but I would like to switch to SPM; unfortunately I still have dependencies which aren't available in SPM.
Now I would like to move as many dependencies as possible over to SPM and keep the others in Cocoapods as long as necessary - is this possible? Having both, Cocoapods and SPM?
I just tried CocoaPods with SPM on my iOS project and it works fine.
I'm adding Firebase and other Google libs using CocoaPods and the rest using Swift Package Manager.
When adding SPM dependency, put checkmark on your project(s) and not on the Pods project.
Xcode 11.5,
CocoaPods 1.9.3.
After trying it out I found you can actually have a SPM + Cocoapods to play nice. You install your SPM library on the .xcodeproj while you develop on the .xcworkspace. It all works (at least so far for me lol).
If you are using CI, or you launch manually from xcodebuild command some tweaks with the -clonedSourcePackagesDirPath flag
I have had used swift package manager at the beginning and added 4 packages in my project. When I had to integrate admob sdk. I added cocoapod to my project.
but after open the .xcworkspace file. the packages status are display as Missing. I have to add them from SPM one by one. after all 4 packages were added again. the project can be built and executed again.
Considering all the pros and cons, I found it suitable to use CocoaPods as SPM is still at a very nascent stage and not all libraries support it.
Please go through the blog written by Darshan Patel by https://blog.kiprosh.com/preferable-dependency-manager-swift-package-manager-spm-or-cocoapods/ for more details.
I use the Crashlytics framework for crash collecting in iOS Apps.
When you use the framework, a "Build Phase" is added to your target that runs /Fabric/Fabric.framework/run <big-hex-blob> <another-even-biger-hex-blob>.
I'd love to know that these actually do – I'm not entirely happy with having external vendors' tools monkey about with my build, I'm old school like that.
Mike from Crashlytics and Fabric here.
The run script build phase is used, along with your <APIkey> and <BuildSecret>, to automatically handle the uploading of dSYMs so that you, and other developers, never need to manually upload one.
Similarly, the /Crashlytics.framework/submit command is used for distributions through Beta, our beta distribution service.
So I have a project with lots of code, and some of it part of open source projects hosted on GitHub, I'm thinking of removing that code and use CocoaPods to import and manage that code for me.
My question is, will that help with the project building time? does Xcode build the complete workspace every time I build my project?
When specifically does Xcode build the pods?
Pods will be recompiled:
When you do a pod install/update
When you do to a clean build
Most of the time, pods are not recompiled.
You can speedup clean build pods using:
https://github.com/leavez/cocoapods-binary
I've had similar problems and developed my own utility 🏈 Rugby.
You can use it like that:
pod install && rugby
And all your pods will be moved to cache. It's an easy enough and fast solution.
At the second time, 🏈 Rugby will compile only changed pods.
Feel free to contact me if you have any issues.
I have recently been working with Cocoapods on my own projects, and would like to incorporate a couple of pods into a project at work. The problem is that our code consists of close to 20 projects stored inside a large workspace, sorted into folders. The structure of the projects is
Workspace
Apps (Folder)
Project 1
Project 2
etc...
Modules
More Projects
etc
Base Components
Even More Projects
etc
I am unsure how to write a podfile that would link a pod (RETableView in this case) against an app without disturbing the existing structure of the workspace? Is this even possible? If it isn't possible to incorporate cocoapods without changing the existing workspace, is it possible to set up cocoapods to compile pods as standalone libraries that I could incorporate into our project?
With CocoaPods 1.x you can use :integrate_targets => false in your Podfile like this:
install! :integrate_targets => false
You can find the documentation for this here
Previously (for older CocoaPods versions):
After creating your Podfile use pod install --no-integrate documented here. This will create the Pods project that you can then include in your workspace. Please make sure everything in your project is checked into your version control system first just in case anything goes wrong.
I've setup cocoapods for my project and I've been doing development for quite some time without any issues. Recently I added a new Configuration for it called "Beta", duplicating the "Release" configuration. At the same time, I added a Scheme that would build targets using this configuration.
This new scheme would build everything without issues, but linking would fail with the (quite known it seems) message:
ld: library not found for -lPods
I know that issues that makes this error message come up have been discussed widely around the web, with different causes and conditions:
library not found for -lPods
https://github.com/CocoaPods/CocoaPods/issues/155
None of these fixes seem to apply here. What I can see by looking into the workspace folder, is that Cocoapods build products are put in Build/Products/Release-iphonesimulator instead of in Build/Products/Beta-iphonesimulator, even though the app itself is built rightly so into the latter. Moving all the *.a files into Build/Products/Beta-iphonesimulator makes running in the simulator work properly, but the next build is still put in the wrong location.
Edit
After some further investigations, the environment variable $BUILT_PRODUCTS_DIR is set correctly in the build phase for the app itself, but not when building cocoapods products.
What causes this and how can I fix this?
Ruled out issues
pod install has been run, multiple times
I'm working in the workspace, not in the project
The cocoapods configuration file in the new configuration is properly set
Build locations in the preferences seem fine
For the record, the issue has been solved. So, as I said, I use cocoapods, but my current setup is that a single podfile, and workspace is used for 3 projects that share some common libraries. As explained in this issue, cocoapods will only consider one project out of all those that are specified in the podfile, and it turns the one project (out of three) that it was using, didn't have the beta configuration, so it didn't feel the need to prepare for it. So when it was time to build the project with the beta configuration, cocoapods would be built for the release configuration, and put in some folder specific to release, so the beta project wouldn't be able to find it.
Fixing was a matter of creating the beta configuration for all projects present in the workspace, forcing cocoapods to prepare accordingly. Then, Xcode would be able to wire up everything appropriately.