Android App Development
iOS App Development
Cross Platform App Development
Hire on-demand project developers and turn your idea into working reality.
Big thanks to Webkul and his team for helping get Opencart 188.8.131.52 release ready!
Owner and Founder. Opencart
Cocoa Pods manages library dependencies for your Xcode project and the dependencies for your project are specified in a single text file called Podfile. A dependency manager makes it easy to add, remove, update, and manage the 3rd-party dependencies which your application is using. Cocoa Pods is built with RUBY and it will be installable with the default Ruby available on macOS.
Run the below mention command in your terminal and enter the password of your system.
Now, if you want to see the progress of cocoa pod installation in your terminal then run below mention command.
The [–verbose] options logs progress as the process runs, allowing you to watch the process instead of seeing a seemingly “frozen” screen.
The Podfile is a specification that describes the dependencies of the target of one or more Xcode project. The file should simply be named Podfile.
It is used to create a Podfile inside your project.
The default Podfile looks like this:
Now, delete the # and space before the platform, then delete the other lines starting with #. Your Podfile should now look like this:
The 1st line of the above code tells cocoa pod that your project target is iOS 11.0 and the 3rd line tells Cocoa Pod to use framework instead of static libraries.
While Swift & CocoaPods both support static linking, not all libraries you include do. iOS 8 introduced dynamic frameworks, which allow you to bundle code, images, and other assets together. Before iOS 8, cocoa pods were created as “fat” static libraries. ‘Fat” means they contained code instruction set like i386 for the simulator, arm7 for devices, etc. However, swift doesn’t allow static libraries to contain resources such as images or assets.
This is to be used every time you edit your Podfile to add a new pod to it (or remove one from it). Every time the pod install command is run & it downloads and installs new pods, it wries the version that it has installed, for each pod in the Podfile.lock file. When you run this command, it only resolves dependencies for pods that are not already listed in the Podfile.lock
When you run this command, Cocoa Pods will list all pods, that have a newer version that the ones listed in Podfile.lock and that could be updated(as long as it matches the restrictions like pod ‘MyPod’, ‘~>x.y’ set in your Podfile).
When you run pod update somePodName, cocoa Pds will try to find an updated version of the pod somePodName, 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 restriction in your Podfile).
If you run pod update without ay Pod name, CocoaPod will update every pod listed in your Podfile to the latest version possible.
There are move commands available than the above mentioned. The above mention commands are essentials commands which you will very often if you are working with Cocoa Pods. If you want to explore them then click here.
If you want to work with the latest version of a pod, that omits the version requirements from a pod file. Eg:
If you want to freeze to a specific version of a pod, in this case, you can specify the version number. Eg.
This file is generated after the first run of pod install, and track the version of each Pod that was installed. It is like a snapshot of exactly what CocoaPods has installed in your iOS projects. So if you are using the source control in your project then you must commit the Podfile.lock in your git. And for commit Pod directory in your source control is totally depends upon you. Let’s look benefit from doing both in your projects:
Since, Cocoa Pod 0.18, it is possible to inhibit warning (turn them off) in Xcode for each specific pod.
You can also inhibit warning for all pods at once by adding inhibit_all_warnings in your Podfile.
Semantic Versioning is just a convention. It divides a pod version into 3 parts and each part tells about the type of change in the version. A pod version will look something like this 1.2.3 where 1 represents Major Release, 2 represent Minor Release and 3 represent Patch no. Let’s look into the details of these 3 numbering conversations:
As a general rule, anything an author makes any kind of bug fix, to their library that doesn’t break backward compatibility, they increment this number.
Library authors will increment this number when they add a new feature.
Library authors will increment this when they make changes to their code that break backward compatibility. For example, Changing method signature
A specification describes a version of the Pod library. It includes details about where the source should be fetched from, what files to use, the build setting to apply & other general metadata such as its name, version, and description.
A stub specification file can be generated by the pod spec create command.
Below is an example of how a PodSpec file looks like. The below PodSpec file is of Alamofire which is a 3rd party library used for handling network requests.
Click here to see all available Pod Spec Commands
If you want to learn more about the PodSepc file do check out this link and for more in-depth analysis do check out this link.
CocoaPods plugin allows us to quickly try the demo project of a pod.
Pod try is a low commitment way of trying out any demo project associated with Cocoapod.
If you run pod try on a 3rd party library. CoocoaPods will go out to that library set of project files and download them to a temporary directory on your computer. Once there, it will scan them for anything that looks like on the Xcode project or workspace, preferably in a directory named something like demo or example. Now if it finds one pod try will open that project in Xcode so you can see how it work.
If it finds more than one Xcode project, it might ask you which one to open.
Thank you for reading this article.
Your email address will not be published. Required fields are marked*
Save my name email and website in this browser for the next time I comment.
Be the first to comment.
We've bought a Shopware Extension which is a hybrid App, which we can now offer in the Google Play Store and the IOS App Store. I'am still impressed how fast and how sharp the support team leads us through every process of the App-Store clarification. Very fast and useful response.
Founder, Das Apartment Living
Enquiry or Requirement
If you have more details or questions, you can reply to the received confirmation email.