Ios-cocoapods principles and Podfile.lock issues

Background:

In daily development, we use third-party libraries in our projects and choose to use CocoaPods for management. Podfile. lock should be committed, what does podfile.lock do, how to resolve conflicts, and what is the difference between Pod install and POD Update.

What is a CocoaPods

CocoaPods is a third class library management tool for OS X and iOS. It allows you to add dependencies called Pods to your projects (these libraries must be supported by CocoaPods themselves) and make it easy to manage their versions.

The benefits of CocoaPods

1. It can automatically complete all kinds of configurations for us when introducing third-party libraries, including configuration compilation phase, connector options, and even -fno-objC-Arc configurations in ARC environments.

Using CocoaPods makes it easy to find new third-party libraries that are “standard,” rather than just found online, so that you can find useful ones.

About CocoaPods can refer to this article: www.jianshu.com/p/9e4e36ba8…

This article is intended to introduce CocoaPods to you and the considerations for using it.

CocoaPods integration principle

The idea behind CocoaPods is to put all of the dependent libraries in a separate project called Pods, while making the main project depend on the Pods project, so that the source management task is moved from the main project to the Pods project.

1.The Pods project eventually compiles to a file called libPods.a, which the main project relies on.2.For resource files, CocoaPods provides a bash footstep called Pods-resources.sh, which is executed every time the project is compiled to copy the various resource files from the third-party library into the target directory.3.CocoaPods sets all dependencies and parameters at compile time through a file called Pods.xcconfigCopy the code

libPods.a
Pods-resources.sh
Pods.xcconfig
Copy the code

How does Cocoapods download

S.s ource = {: git = > ‘[email protected]: app/iOS – XXX. Git’, : tag = > ‘1.0.0’}

Git => ‘[email protected]:app/ ios-xxx. git’
Locate the commit with the corresponding tag according to :tag => ‘1.0.0’ (locate the last commit if Pod dependent library version is not indicated);
In this commit, retrieve the file with the suffix. Podspec (you can name the file whatever you want) and verify that s.name matches the file in the Podfile.
If inconsistent, install will report an error: [!] Unable to find a specification for ‘React’. After the verification is successful, the system finds the code file to import according to s.source_files in Podspec, and finds the corresponding configuration file or resource file based on other data.
Then download it to your local project.

Note: These principles are the same for shared libraries. The common libraries simply upload podSpec files to Cocoapods. When importing a new podspec, use the name React to cocoapods to match it to the new podSpec, then use s.source to find the repository and the new podspec. The following steps are identical.Copy the code

Version Control Principles

When pod Install is executed, Cocoapods generates a podfile.lock file. The greatest use of the podfile.lock file is in multiplayer development. If you do not specify the Pods version pod ‘React’ in your podfile, the default is to get the latest version of the current React dependency library.

When someone on the team executes the pod install command, the resulting podfile.lock file records the latest podfile.lock dependencies, and someone else on the team checks the project containing the podfile.lock file. When pod install is executed, the version of the Pods dependency library is the same as the original version. Without the podfile.lock file, all subsequent users running pod install would get the latest version of React, which could result in a team using different versions of the dependency libraries, which could be a disaster for teamwork. In this case, if the team wants to use the latest version of the React dependency library, there are two options:

1. Change the podfile to point to the latest version of the React dependency library

2. Run the pod update command. Because the podfile.lock file is so important for teamwork, it should be added to version control.

Whether or not to submit podfile.lock

The podfile.lock file is submitted.

When our app is componentized, an app will contain various versions of components, and the main project will become a shell, relying on various components with Podfile. Then our app completes a version iteration and goes online, at which time we need the corresponding component versions of the main project. The components of the corresponding version depend on the components of other versions, which would be very cumbersome to manually manage by spec, and if we were to write all the components in our podfile, we would go back every time (we are currently working on version 2.0 and want to go back to version 1.0). You need to record the versions of all the components in the previous version of your app, and then write the corresponding component version number in your Podfile. If there are too many components, you need to go back several times, which can be painful. What’s the easiest way to go back to the previous version of the game one minute at a time? This is when you need to rely on the podfile.lock file for version management.

Podfile.lock is annotated with the exact version of the project’s current dependent libraries. This includes the libraries that the project uses for direct annotations in Podfile, as well as other libraries that those libraries depend on. If your partner synchronizes your podfile. lock file and executes pod Install, it will install the dependency library of the specified version of podfile. lock. For this reason, CocoaPods officially strongly recommends putting Podfile.lock under version control.

So if we use the podfile. lock file for version management, all we need to do is put podfile. lock under version control in the main project (that’s the shell). In addition, the Podfile in the main project must not specify the version number, and then mark the corresponding version number tag in GitLab every time the APP is blocked. Every time we want to go back to the previous version, we only need to switch to the current tag. Then execute pod Install (do not execute pod upodate, because the library version in podfile. lock will be updated after pod upodate is executed) and that’s it.

Podfile. lock conflict resolution

diff: /.. /Podfile.lock: No such file or directory

diff: Manifest.lock: No such file or directory

error: The sandbox is not **in** sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.`
Copy the code

During normal development, after executing pod Install, a project prompts you that the podfile. lock file has been modified and needs to be committed. But another colleague (whose COMPUTER has a different POD version than yours) pulled down the code, ran the project, found the error, fixed the problem by executing Pod Install, and then submitted the podfile.lock file. When you update your code and you find this problem, it’s an endless loop. We have to submit the podfile. lock file, so the solution to this problem is to keep the POD version on everyone’s computer the same.

Delete pod sudo gem uninstall -n /usr/local/bin cocoapods -v XXX install pod sudo gem install -n /usr/local/bin cocoapods -v XXXCopy the code

Pod Install vs. Pod Update

Pod Install: Used to download Pods for the first time for a project, and for adding or deleting libraries later. Pod Update: Used to update the library version. It iterates through all libraries for updates and updates the podfile. lock file. Pod Update name: Only the specified library is updated. pod repo update: Pod install updates all the configuration files in the.cocoapods library, check if there is a new version of the framework, if there is, update the local resource configuration file --no-repo-update: download and import the corresponding third-party library from the podfile or podfile.lock, skip checking whether the resource configuration file needs to be updatedCopy the code

Use the sample

Example 1: The project needs to rely on libraries A, B, and C, all of which are 1.0.0. Create A Podfile and execute Pod Install. All three libraries are pulled, and versions A, B, and C in Podfile.lock are locked to 1.0.0.

Example 2: The project needs to add a Pod D, and introduce D in the Podfile, where pod Install should be used. Because you just want to add D and don’t want to update the other three libraries.

Example 3: At this point, let’s say other team members join the project, clone the project repository, and then execute ‘Pod Install’. Because podfile.lock is committed, I can make sure that the new member is using the same library version as mine. Even if pod A has A ‘1.1.0’ version to use, because pod A is locked in podfile. lock at version 1.0.0.

Example 4: Check for version updates. If you want to update POD A to 1.1.0 and pod B has A new version but you don’t want to update Pod B, use Pod Update A. The pod B version information in podfile. lock will also be updated.

Note: Using A fixed version of the Podfile, such as pod ‘A’, ‘~> 1.1.0’, ensures that all members of the project are using the same version? The answer is no, when executing A pod update, you can only ensure that ‘A’ is fixed, but if ‘A’ still relies on pod A1, the latest version of POD A1 is 1.0.0, and the latest version of pod A1 is 1.1.0. This will result in version A1 being ‘1.1.0’. That’s why make sure that every member of the team uses podfile. lock as the only way to use the same version on different computers, and that pod Install and POD Update are used appropriately.

Logical relationship between version numbers

'> 0.1'-- The version number is greater than or equal to0.1'> =0.1"- version0.1And the version number is greater than0.1the'< 0.1'-- The version number is less than0.1'< =0.1'-- version 0.1 and version less than 0.1Copy the code

Optimal matching of version numbers

'~ >0.12.'- release 0.1.2 and version number between 0.1.2-0.2, not including 0.2 and higher' ~ > 0.1 '- version0.1And the version number0.1-1.0Between, excluding1.0And later versions' ~>0'-- version 0 and higher, same as noneCopy the code

conclusion

In this article, we introduce whether to commit git with podfile.lock, what podfile.lock does, and how to resolve conflicts. Pod Install is different from POD Update.

Reference article: