Everything you need to know about Cocoapods | Swift | Xcode | iOS

hey guys welcome to my channel i code i am pillow and today we are going to talk about cocoa pods i understand that you would be familiar with cocoa pods you would be having experience using the pods and you might be comfortable with it and because of that you might know some of the stuff already but today in this video i will be deep diving into the details and because of that something new might come up so you can consider watching the video till end let's see that what we will be looking today so we will see that what is cocoa pods because people generally confuse the two things spots and cocoapods so we will see that what it is how it can be installed because we know that sudo gem install cocoapods is something but why do we use sudo what is gem install so we'll understand that then we'll see that how are pods installed what happens when we run the command pod install how can we identify that what pods are outdated because i have seen developers doing google about the parts that if there any new version available of that part so no need of that there's already a command pod outdated we'll look for it then we'll see that how to update the existing parts because pod install and pod updates are two different things and they are often confused so we'll see that what is the difference between these two and then what is pod repo update because at times you get the error and pod repo update fix that for us but we must know that actually what this command is doing so we'll see it part repo update then what is the log file what is the manifest file what is checksum and everything else so let's get started so cocoa pods is a dependency manager for swift and objective celebrities it is having thousands of libraries and millions of apps are using them of course cartridge and swift package manager are doing the same job but cocoa pods is one of the most widely used ways for managing the dependencies lm of fire google sign in rx swift kingfisher you can just name any dependency and you will find it on cocoa pods so it is one of the most widely used ways and now let's see that how installing of the cocoa pods happen so we know that the command sudo jam installed cocoa pods is used but why are we using sudo for it so using sudo command we can run some of the commands as some other user which is by default the root but then comes the point that why do we need to use sudo here in this place we are using sudo here because we want to access the ruby that is installed in the mac os and why do we want to access the ruby that is because cocoapods library is built using ruby and then what is this gem install so cocoapods libraries are generally referred as gems and to install them we use the rubygems package manager rubygems is a package manager that is used for distributing the ruby libraries and because coco pods is one of the ruby libraries so using the command pseudo gem install cocoa pods we are asking that package manager to install the cocoapods library in our system now let's see that how are pods installed so after installing the cocoa pods when we do pod in it and we get a pod file we write some parts in that and then we run pod install command to install those pods which we have written in our pod file what happens when we run the command pod install so this command is used whenever some change happens in our pod file whenever we add some dependency we remove it from pod file or we update the version of any particular dependency we use the command pod installed to download that particular dependency from the cocoapods trunk and every time the pod install command is run and the dependency is downloaded its entry is done in podfile.log podfile.log is a file that keeps the track of our install dependencies and more importantly it keeps a track of the versions of those pods which are installed now this file is of great use and we will see it in few minutes but for now let's understand that whenever a pod is installed its entry is done in the podfile.log which has the number and the version of the installed pod so when we run pod install it resolve the dependencies for only those points which are not having the entries in the podfile.clock now here two things can happen first for the pods which are having their entries in the podfile.log the exact same version will be downloaded without checking that if any newer version is available or not and for the pods which are not listed in the pod file that is we are downloading them for the first time it first searches for the version mentioned in the pod file and if you have not mentioned any version against the pod in the pod file then the latest version is downloaded and then its entry is done in the pod file.log now comes the part of identifying the outdated ports because the maintainers of the pods keep on publishing the newer versions of the pods with bug fixes with new features and so the version that is installed in our local machine it gets outdated now to update it we must first know that whether the version that is installed in our machine has been outdated or not and to do so that's the command pod outdated now when we run pod outdated the cocoapods will list all the pods for which a newer version a higher version is available or not and no need to worry it will not automatically update that particular part rather it just tells that the newer version is available then if we select to update that particular port the newer version will get downloaded otherwise it will not so it is just to identify that whether the new version is available or not the pods mentioned in the green color will be immediately updated to the latest version when we're in pod update for them those who are mentioned in the blue color they will be updated but not to the latest version because we have explicitly mentioned some version in the pod file and those who are in red will not be updated because of the version that is mentioned in the pod file now let's see that how update works so pod update command will try to update the pod the particular part whose name we have mentioned with the command pod update and if you do not mention the name of the pod then it will try this for all the parts that we are having so it will update the part without considering the version that has been mentioned in the podfile.log unless we have explicitly mentioned a version in our pod file and this will be done for all the pods if we do not mention any particular port name with the command pod update now it's important to understand that whenever we want to install a new port we must go for running the command pod install and not pod update most of the times developers confuse this with the thought that quad install should be done for the first time and part update for any time after that well that is not the case pod install should be done when you want to install a new port and pod update should be done when you want to update any existing pod now it is very important to understand that podfile.log should be always pushed to your source control even if it is your policy to not to push the pods folder well that's the good practice actually but if you are following that practice to not to push the ports folder even then you must push the podfile.log because that is something that is keeping a sync between the versions that are being used by different developers it ensures that developer b is using the exact same version of the pod that is being used by developer a if we do not push the podfile.log to our source control then we break this entire logic so it's very important to push the file dot clock now let's understand this install versus update through an example so on day one some developer let's say a he created a pod file and mentioned pod a b and c in it and run pod install now let's assume that at this point in time we are having the versions 1.0.0 for all the three parts next day he installs a new port for d using the command pod installed now because he has used the command pod install the a b and c they will remain on the same version that is 1.2.0 regardless of the fact that there is a new version available for the port b so at this point of time 1.1.2 is available for part b but he will still get 1.0.0 because he ran the command pod install and not pod update now on day three a new developer joins the team she closed the project and she runs the command pod stall now because spot file dot lock was pushed to the source control she will get the pod a b c d and she will get the version 1.0.0 for all four of them by this time maintainer of part c published a new version of c that is 1.2.0 but she still got the same version that is 1.2.0 and that is because the podfile.log was pushed to the source control and now both the developers are on the same page next day first developer tries the command pod outdated because he wanted to know that if there are any newer versions available for the parts that they are using in their project and he comes to know that b and c are having new versions that is one point one point one one two respectively then he decides to update the part b so he run the command pod update b now because he specifically mentioned the pod with the pod update command so only b will be updated and c will still remain on the same version that is 1.0.0 now pod file.lock will be updated with this new version of b and whenever his teammates will take the pull and they will run port install they will be on the same version as he is on now let's try and understand a very important concept that having the exact same version in the pod file does not guarantee that all the developers all the teammates will be using the same version of that particular part some people argue that there's no need of pushing the podfile.log to the source control because they have already pushed the pod file and pod file is having the explicit versions mentioned against each part and so all the developers will be having the same version now there is a catch in this let's see that exact versions mentioned in the pod file will not guarantee the same version of the pod and this is because the parts that you are using might have some internal dependency on some other part let's say that part a is having a dependency on part a1 now you have mentioned some version say 1.0.0 for a part a which is internally using a pod a1 which is on the version say 2.2.0 now you run the command port install and you get the version 1.2.0 for pod a now a month later a developer joins your team and he closed the project he does the command pod install but by this time the maintainer of the pod a1 on which a is having the internal dependency a new version has been published for pod a1 that is 2.1.0 pod a is still on the same version that is 1.0.0 which will be installed on this developer's machine the new developer but he will get 2.1.0 for the internal dependency that is part a1 now the previous developer is also on the same version for the pod a that is 1.2.0 the new developer is also on the same version that is 1.1.0 but both of them are having the different versions so it is very important to push the podfile.log to the source control so that all the teammates use the same version now let's understand that what is repo update so if you are familiar with the pods i am pretty much sure that you would have encountered some error which would have been fixed by this command pod repo update so what this command actually does when we run this command pod repo update it updates the local clone of the specs repo now what's spec repo that we will see it in a minute but for now let's understand that if you put the name with the command then the spec wrapper for that particular part will be updated and if you do not put the name then the spec wrapper for all the parts will be updated now let's look that what is this spec repo so if we go on this github repo that is cooper specs let's see that what do we get so this repository has this directory that is specs and inside specs we are having all these sub directories that is 0 1 2 3 and each of them is having the directory for the dependencies and that is having the specifications of that particular pod so if i go here you can see that all these libraries let's say let's say google mobile ads so if we go in that we'll see that it is having the specification file for this particular port now when i say that it updates the local repo does that mean that we are also having the same structure on our machine yes we do so if you go in the users directory there's this hidden folder that is inside that we are having this this directory repose and trunk and there we find this directory specs now this is the clone of the directory that we just saw on the github and it is having the specs for the parts that i am using in in any of my projects so whenever i will run the command part refer update this particular repo will get updated and then those issues will be fixed so now comes the point that how are issues fixed by this command it is simple if i am trying to update any of the pods for which the specs rep is not updated i will get the error as soon as i run the command pod repo update and name of the pod the specs wrapper for that particular port will be updated and then i can install the updated version or should i say that i can update that particular port now let's understand manifest.log i'm not sure that if you ever came across this file or not but this is the file which ensures that you are having the exact same version of the pods which are mentioned in your podfile.log so this is a copy of podfile.log which is generated whenever we run the command pod installed you would have seen this error that the sandbox is not in sync with the podfile.clock now this error is because the manifest.log file is not in sync with portfol.log because pods are not always under version control this file ensures that we are having the versions that are mentioned in the portfolio so imagine that you updated one of the pods the log file also got updated you push the code you are having your log file under version control your teammate takes the pull he also gets the updated lock file and without running the pod install he tries to run the project the build will fail and the failure will be because of the manifest.lock because the manifest.log at his machine is not in the sync with the updated podfile.log that means that he is having some other versions of the pods as compared to the versions mentioned in the podfile.clock so that is the role of manifest.log if you would have tried opening the podfile.log or if you would have received some merged conflicts in the log file you would have seen that there's this thing checksum at the bottom of the file let's see that what it is so checksum is a concept used to ensure that the files are in sync basically a file or should i see a block of data it is encrypted using some cryptographic algorithms like mt5 sha and a sequence of numbers and letters is generated that sequence is known as checksum now what is the role of checksum in regards of cocoapods so many times you cannot guarantee that you are having the same version of the podspec file as that of your teammate so to resolve this conflict cocoapods make a checksum of the json representation of your podspec file and put it into the podfile.log now if that checksum do not match then you will get the error and then you will resolve it using pod update or pod install whichever applicable so that's pretty much for this video i hope that you found it useful a new video comes out every sunday so you might consider subscribing to my channel let's write better code together happy coding stay safe

Channel: iCode

Views: 1,846

Keywords: cocoapods, cocoa, pods, swift, ios, icode, dependency manager, xcode, spm, carthrage, Podfile, checksum, manifest, alamofire, rxswift, iOS app development, objective c, swift ui, swift package manager

Id: QLm_3Ny_Fkg

Length: 15min 29sec (929 seconds)

Published: Sat Jun 26 2021