How do I use CocoaPods correctly - ios

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.

Related

Override 3rd party package Pod values

I need to modify a flutter package which is made with swift.
So I forked the package, openend Xcode and started editing in Pods/Pods.
Basically I just have to change 2 variables in Constants.
But when I refernce my fork in my flutter packages the changes I made aren't there.
Can anyone help me with this? I am sure there is a way to modify the code.
Also run
flutter clean, removed Podfile.lock and Pods folder, run flutter pub get and pod install.
Thanks for any help!
Every modification in Pods is just temporary, when you install pods again, that change disappears, because it installs remote pods again.
You have to fork PusherSwift cocoapod and make changes there. And of course use your version in Podfile.
Update 1:
fork https://github.com/pusher/pusher-websocket-swift, because what I understand you want to modify file inside. (Constants.swift)
put pod 'PusherSwift', :git => 'urlToYourRepo.git', :branch => 'yourBranch' to podfile

What is a development pod?

I am new to CocoaPod and IOS in general, I am trying to use a framework I built locally in my podfile as follows:
# Pods for Example
pod 'OsonWidget', :path => "../OsonWidget/"
when I run a pod install and open the .xcworkspace of the project, the framework gets saved under Pods/Development pods. So my question is what is Development pods
Normally in Podfile you point to the repo with its git name and your intended version.
You’re not doing that. Instead you are pointing to the pod by the :path identifier in the Podfile.
Other than the two ways mentioned above, there are other ways to point to a repo.
Obviously you are locally pointing to a pod, ie the pod was not fetched from the actual repo, implying that you own the pod and you’re developing the pod, you want to make changes to it and immediately see how the changes work for you in your Example app. Hence it’s named ‘development pods’.
Any change you make will be reflected into the Example project. Though if you add a new file, then you need to run pod install again so the projectfile gets updated.
This is slightly different from other dependency managers where the term 'development' is used for dependencies that are necessary for testing, benchmarking, and other developer tasks. Example with Ruby Gems, you have add_development_dependency vs. add_runtime_dependency
With CocoaPods the decision to use something as development vs. deployment is per file i.e. whether or not a pod/framework imports a file.
This all means you could have a file in your test target i.e. only import the pod in your test target and never include it in production e.g. the KIF pods. But mainly if you import a pod in your production code, then you'd need to import it again in files you have under you unit test target.
I did some digging on cocoapods.org, and found this snippet:
Development Pods are different from normal CocoaPods in that they are symlinked files, so making edits to them will change the original files, so you can work on your library from inside Xcode. Your demo & tests will need to include references to headers using the #import <MyLib/XYZ.h> format.
https://guides.cocoapods.org/making/using-pod-lib-create

iOS Practice for using cocoapod and source control

Currently, in our company, we just commit all pods (like AFNetworking, Realm, etc) to svn/git. From time to time, when other developer install pod, update pod, there are conflict.
We also use this so that we don't touch other pods.
pod install --no-repo-update
Can I know what is the good practice for using third party pods? Do I need to commit those pods?
Or just do pod install again after our codes are checked out ? I just want to avoid code conflict for using pods.
You can refer to http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control
Whether you check in or not, the Pods directory, the Podfile and Podfile.lock should always be kept under version control. It is recommended to keep it under version control and don't add it to your .gitignore
We also faced the same problem.As a solution, in commit we write only pod file with required pod list . Whenever other person take update, his podfile is updated and then from console he update his project pods.
As pod is same for all so you dont need to commit the pods. for more specific you can you can give pod with version.
Khant usually it's not a good practice to upload your dependencies to your repositories mostly because your will be saving space and time. it's ok to push your Podfile but all the code of your dependencies should be omitted and installed locally for each developer. And each time a new dependency is added or update you will just need to run the pod update command. to do that you can add to your .gitignore file on a new line just Pods/.
Either way if you are working on a big scale application you should on swift you should follow the best practices and use a correctly .gitignore setup like this one example and also if you want to know some pros and cons on avoiding Cocoapods dependencies you can check this official documentation
In my opinion, we don't push all pods to svn or git. You can commit only Podfile and may want to freeze to a specific version of a Pod, in which case you can specify that version number.
pod 'Objection', '0.9'
And when other members install pods, it will be same.

Manually installing pod files

I'm trying to work with a git repo who's dependencies are configured through CocoaPods. However, my internet connection is rubbish (I'm on holidays) and keeps cutting and interrupting pod install. I managed to install 2 of the 6 dependencies through pod (took all day) and realised I actually have the zips of these frameworks already on my computer. So I added for example LayerKit to my pods directory in the project folder. Then when I run pod install again, it hasn't noticed that I already added the file... Any idea how I can fix this or a better way I can work around this. I really have no idea how pod works, I usually just run pod install and it all works miraculously.
You probably want to create a folder under your project's main folder and place all of them in there.
Once that is done, update your target in your Podfile to look like this:
pod 'NameOfPod', :path => 'Relative/Path/To/Podspec'
That allows you to access the pods locally on your system. The path needs to point to the Podspec file for the pod. Also, make sure you do not alter the directory structure in the pods, as this will likely break them.

CocoaPods how to install one new library without update other

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

Resources