I'd like to remove a Pod called EvernoteSDK from my project.
I remove the pod by execute these steps:
Remove 'EvernoteSDK' from Podfile
Run pod install
Result:
The EvernoteSDK has been removed. But when I check the diff, It deletes some object/property in some xcconfig file that I think it should be not related to the removed Pod. And this change is occurred in all installed Pod of my project. The diff result is shown in the image below:
Issue Image
My environment:
xCode 12
I tried it by using Cocoapods 1.9.3
Why is it happened? And how to remove a pod without affect other Pod file?
Because this is my first time to face this issue when removing a Pod.
Thank you.
It's up to version of Cocoapods. That difference is probably some new config from Cocoapods, so everything should be alright.
I am new in IOS development and git. I am having a problem after merging my local repo to the dev repo. After merging when I build the project I get an error in the Xcode that says, "The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation."
Build Error
I searched about this and tried the usual solution reinstalling the pods. But executing
pod install
I get another error in terminal that says
Terminal Error
At this point I tried deleting the files associated with the "FTPopOverMenu" pod and reinstalling with pod install. The error doesn't go away. Also, I tried solving it in this way - Error:“The sandbox is not in sync with the Podfile.lock…” after installing RestKit with cocoapods
But both error in the Xcode and in the terminal still remains. I'm new to IOS and Git. I really don't understand what is really happening here.
As per my guess you are working on an old project means which is already developed in Xcode 8 series and now you are working with latest Xcode and you have updated the code accordingly.
So just do the below steps:
"pod deintegrate"
"pod install"
"pod update" (if it is necessary so do it else if you have all latest pod so don't use it.)
It will remove all old cocoapods traces.
OR Alternate way to do it (Temp Work Around)
Remove that cocoa pod temporary, after all your work finish add to your project and give a try cause in my case it is the only work around i have that worked.
In my case pod repos were outdated, solved with pod repo update
if #Ravi Panchal's answer can't solve your problem, it may be your pod repo is out dated
Solution:
pod install --repo-update
First, check your Podfile.lock and make sure no conflict with the spec constraints.
I encounter this issue with strange pod dependency, and solve it by
1. remove Podfile.lock
2. pod install again
It just work like magic. I think it is a bug that cocoapods cannot solve this kind of constraints in Podfile.lock. Remove the old Podfile.lock can make it apply the new rule easily.
please check your podfile and update the platform to the appropriate version number
platform :ios, '11.0'
In my case it worked after I changed iOS version from 8.0 to 9.0 in Target (not Project) settings >> General >> Deployment Info
In .podfile
changed the iOS version
platform :ios, '13.0' // Warning change by your desired
It worked
I had the same issue with FIRMessaging from cocoapods. I solved the issue by doing like following steps
Remove FTPopOverMenu from your podfile which can find in your project folder.
Open terminal and run pod install. You can see in terminal that FTPopOverMenu will be removing from your pods.
Now, again open your podfile and write this pod 'FTPopOverMenu'. Run pod install in terminal.
The error will go away from terminal.
if you are facing this error in Flutter CocoaPods could not find compatible versions for pod
increase your minimum deployments
cd ios and then rm -rf Pods/ Podfile.lock ; pod install
flutter build ios
I fixed by a change to dynamic pod version.
And delete file Podfile.lock
Please check the line below in your Podfile. Please make sure it is commented. it works for me.
platform :ios, '9.0'
I have an answer regarding this in the thread already. But this time my scenario was different. My co-worker accidentally updated the cocoa version from the stable to a beta version, while I was using the lower stable version. I wasn't interested using the beta version, so I didn't update.
As deleting podfile.lock is dangerous which leads to removing the Cocoapods traces, I just opened podfile.lock in editors like Sublime Text, and downgraded the pod which is causing the problem.
Look at the iOS Deployment Target, make it 11.0 and then do
pod install
and it will be fixed
I had to do some local changes to some frameworks I am using. However, I installed them with cocoapods. Is there any way to keep those changes when I do pod install again for new dependencies ?
Thanks for the ask question.
I am sorry to say this is not possible because when you have install or Update your pod then replace all file from new file.
pod outdated:
When you run pod outdated, CocoaPods will list all pods which have newer versions than the ones listed in the Podfile.lock (the versions currently installed for each pod). This means that if you run pod update PODNAME on those pods, they will be updated — as long as the new version still matches the restrictions like pod 'MyPod', '~>x.y' set in your Podfile.
pod update:
When you run pod update PODNAME, CocoaPods will try to find an updated version of the pod PODNAME, without taking into account the version listed in Podfile.lock. It will update the pod to the latest version possible (as long as it matches the version restrictions in your Podfile).
If you run pod update with no pod name, CocoaPods will update every pod listed in your Podfile to the latest version possible.
You can also find reference from here.
You have to create a folk on git, of that libraries in which you are doing changes localy, and use that commit url instead of library name and version in pod file.
Whenever you are going to update lib, you will get your code.
This is solve your problem. :)
I think a question need not be described. Usually when I do pod install it updates for me all my libraries. How can I add one new and just add this new one without update other?
>pod install --no-repo-update
This installs new pods without updating existing pods.
It's also just faster if you have a many of pods and want a fast install of a new pod.
This isn't the expected behavior of pod install. The only way I can see this happening is if you're not using the Podfile.lock as intended. When you specify something in your Podfile that you have never installed before, for example:
pod 'MyAwesomeLibrary', '~> 1.0.1'
The newest version matching your specification is determined (explained here) and the resolved version is stored in the Podfile.lock. In this case that could mean that you actually download 1.0.4 etc.
This means when you go to add another library, for example:
pod 'AnotherAwesomeLibrary', '~> 2.0.1'
The same thing will happen for the new one. But, because of the information previously stored in your Podfile.lock, CocoaPods will just verify that the version specified there is installed. It will not update that library. If you actually want to update it you'll need to run pod update
pod install --no-repo-update
thats it
I have some doubt on CocoaPods
I think the 1st rule is that keep Podfile and ignore pods folder entirely. But I am so confused about this after I have used some time
Since I insist on #1, somebody says *.lock should be kept in repo. Do I need do this?
Pods generates some xconfig files, it seem I can't add HEADER_SEARCH_PATH in it ?
if YES, it breaks my rule #1 again. Please see this question the-target-overrides-the-other-ldflags-build-setting-defined-in-pods-pods
some buddies modify codes managed by CocoaPods such as AFNetworking rather than from custom repo. I told him NEVER do this because it will recover to origin version after pod update/install but after pod update/install his code didn't change. that's WHY?
My opinion is DON'T MODIFY EVERTHING IN PODS PROJECT EXCEPT PODFILE
You should always check in your Podfile and Podfile.lock.
Checking in your Pods directory is debatable. If you would like to be able to clone the project and run it without requiring users to have CocoaPods you should check this in. I personally do not check this directory in, instead you just have to run pod install after cloning the project for the first time.
If you want to alter the xcconfig files with changes such as HEADER_SEARCH_PATH you should check this in so those settings don't get overwritten unintentionally. Really the podspec should handle all of these settings so you probably shouldn't be changing much in there.
If you're planning on altering the code included by a Pod you should either check in your Pods folder or fork the repo and redirect it to in your Podfile. Documentation on that here. This way you can specify that CocoaPods uses the given spec but uses your fork instead.
EDIT The Podfile.lock (similar to the Gemfile.lock) stores information on the actual version included during the install. Consider this:
You require a spec like pod 'foo', '~> 1.0.0 in your Podfile.
You run pod install and it installs the newest version of foo matching the semantic versioning conventions (specified by ~>)
You don't check in your Podfile.lock
Another developer clones the repo, the newest version of foo is now 1.0.3.
They run pod install. Version 1.0.3 is installed even though they didn't run pod update.
This information is 'locked' in the Podfile.lock so that to do this you have to run pod update which should be very intentional.