IOS package dependency management tools

IOS package dependency management tool (part 1) : CocoaPods

IOS package dependency management tool (ii) : CocoaPods principle and knowledge

IOS package dependency management tool (3) : create your own Pod library

IOS Package dependency Management tool (4) : Swift Package Manager (SPM) Introduction

IOS Package dependency Management tool (5) : Swift Package Manager (SPM) Customization

IOS package dependency management tools (6) : CocoaPods VS SPM Summary

Last time we learned about CocoaPods and how to install it. In this article we will learn more about CocoaPods

1. Pod install is different from update

1.1, Pod install:

If the version is specified, check whether the saved version in podfile.lock is the same as the newly specified version. If the same version is specified, skip the update. If no version is specified, skip the update. If not, download the library and save the version in your podfile.lock file.

Each time the pod install command runs and a new Pod is downloaded and installed, it writes the installed version of each pod to podfile. lock. This file keeps track of each installed version and locks those versions. When pod Install is run it resolves only those dependencies listed in Podfile.lock.

For pods listed in podfile. lock, it simply downloads the specified version and does not check to see if a new version is available.

For pods not listed in podfile.lock, he searches for the version that matches the content in the Podfile (for example, pod ‘MyPod’, ‘~>1.2’).

1.2, POD Update:

This command ignores the records in podfile. lock and goes directly to the constrained version (or the latest version if not constrained) of the dependent library in the Podfile file. This is usually used when you want to update your Pods to a new version. When pod Update PODNAME is run, CocoaPods will try to find the more recent version of PODNAME, regardless of the version listed in podfile.lock. It updates the POD to the latest possible version (as long as it matches the version limit in the Podfile).

If you run a POD update without a pod name, CocoaPods will update each pod listed in your Podfile to the latest version.

1.3 Pod Install Usage Scenarios:

  1. New creation project, first introduction of pod library
  2. Modified the Podfile file to add or remove the pod library on which it depends.
  3. When a new member of the team gets the POD library after pulling the project.
  4. When different developers on the team need to synchronize their pod library dependencies (when someone changes the dependency, removes or adds a POD.

If someone executes a POD update, the trace version in their podfile. lock file has changed, while someone else can update to the version in their podfile. lock file with pod install.

If the Podfile and podfile. lock records conflict, the version specified in the Podfile file is lower than the one recorded in podfile. lock. The Podfile file will prevail and the podfile.lock file will be updated upon success.)

1.4 Pod Update Usage Scenarios:

  1. This is usually used when you want to update your Pods to a new version.

Podfile Specifies the logical operator when the version number is specified

Besides no version, or a specific one, it is also possible touse logical operators: '> 0.1' Any higher version than 0.1' >= 0.1' version 0.1 and Any higher version 0.1, Include 0.1' < 0.1' Any version lower than 0.1' <= 0.1' version 0.1 and Any lower version 0.1, In addition to the logic Operators CocoaPods has an OptimisicOperator ~>: '~> 0.1.2' Version 0.1.2 and the versions up to 0.2, not including 0.2 and higher 0.2, 0.1.2 '~> 0.1' Version 0.1 and the versions up to 1.0, not including 1.0 and higher 1.0, '~> 0' Version 0 and higher, this is basically the same as not having itCopy the code

Podfile syntax

1. Source * Specifies the location of specs to add your own podSpecs. * If you don't have a custom podSpec, you don't need to add this item because the official source of CocoaPods is used by default. Once another source is specified, the official source must be specified, as shown in the example above. 2. Platform :iOS, '8.0' * specifies the platform on which the open source library should be compiled and the lowest version of the platform. * If the platform version is not specified, the official documentation states that the default values for each platform are iOS: 4.3, OS X: 10.6, tvOS: 9.0, watchOS: 2.0. 3. use_frameworks! * Swift project CocoaPods defaults to use_frameworks! * OC project CocoaPods defaults to #use_frameworks! 4. inhibit_all_warnings! This feature can also be defined in sub-targets if you want to block warnings from a pod, for example: 'pod 'JYCarousel', :inhibit_warnings => true' 5. Xcode workspace specifies that contains all projects. If there is only one project in the Podfile directory, the project name will be used as the workspace name. 7. Project * Is not specified by default, and when not specified, If you specify project, as shown in the example above, then CocoaPodsTest will only link 8. Inherit! :search_paths * specifies explicitly all the pods that inherit from the parent layer. Default is inherited 9. Pod 'AFNetworking' --> Do not explicitly specify the dependency library version, Said every time to obtain the latest version of the pod 'AFNetworking', '2.0' - > only use version 2.0 pod 'AFNetworking', '> 2.0 - > use is higher than the 2.0 version of pod' AFNetworking ', '>= 2.0' --> use pod 'AFNetworking' with a version greater than or equal to 2.0, '< 2.0' --> use POD 'AFNetworking' with a version less than 2.0, '<= 2.0' --> use pod 'AFNetworking' less than or equal to 2.0, '~> 0.1.2' --> use POD 'AFNetworking' greater than or equal to 0.1.2 but less than 0.2, '~> 0.1' --> pod 'AFNetworking', '~> 0' --> 0Copy the code

4, Podfile. Lock

  • The podfile. lock file is automatically generated when we create a new Podfile file, and contains versions of the dependencies we have installed.
  • When we first run Podfile, if we don’t specify a version for the dependent library, Cocoapods installs the latest version and records the version of our Pods in the podfile.lock file. This file keeps track of installed versions of each POD and locks those versions. When pod Install is executed, only the dependent libraries that are not recorded in podfile. lock will be processed and the version that matches the one described in the Podfile will be searched. For dependent libraries already recorded in podfile. lock, the version recorded in the podfile. lock file is downloaded without checking for updates. Of course, if you have constrained the version of your Pods, the installation will follow the version you specified and the podfile. lock record will also be updated.

Podfile. Inside the lock

PODS: -navigation (1.1.0) DEPENDENCIES: -navigation (~> 1.1.0) SPEC REPOS: Trunk: -navigation SPEC CHECKSUMS: navigation: 678 fab65091a9290e40e2832a55e7ab731aad201 PODFILE CHECKSUM: 7 a5a6c829f4d2252e3e3d116ab9757a3b270ed8a COCOAPODS: 1.9.3Copy the code

Note:

Instead of adding this file to OS, podfile. lock should be added to version control. Because podfile. lock locks the current version of each dependent library, podfile. lock will only be changed during POD Update if the version does not change after multiple pod installs. In this way, when many people collaborate, they can avoid the inconsistency of third-party library versions caused by third-party library upgrades.

5. Cocoapods principle

Put all dependencies 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:

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

6. Principle of download

S.s ource = {: git = > '[email protected]: ios - thirdpartservice/xxxreact git', : tag = > '1.0.0'}Copy the code

When importing a private library using Cocoapods:

  • According to: git = > ‘[email protected]: ios – thirdpartservice/xxxreact git’ find corresponding git repository
  • 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)
  • Then retrieve the podSpec file in this commit (you can name the file whatever you want)
    • After finding the podspec file, verify that s.name is the same as in the Podfile:
      • If inconsistent, install will report an error: [!] Unable to find a specification for ‘React’.
      • After the verification is complete, you can find the code file to import according to s.source_files in Podspec, and locate the corresponding configuration file or resource file based on other data.
  • Finally, download it to your local project

The principles are the same for shared libraries:

  • The common libraries simply upload podSpec files to Cocoapods
  • Use the name React to cocoapods at import time to match the corresponding PodSpec
  • Then follow s.source to find the repository and the corresponding version
  • The new PodSpec is then matched

The following steps are exactly the same.

7. Integration principle

When all the dependencies are downloaded, Cocoapods puts them into another project called Pods, and then makes the main project depend on the Pods project.

In this way, source control is moved from the home directory to the Pods project. The Pods project will eventually compile into a file called libPods.a, which the main project relies on.

For resource files:

Cocoapods provides a bash script called Pods-resources.sh, which is executed every time the project is compiled to copy the various resource files from the Pods-dependent libraries into the target directory. Cocoapods also sets all dependencies and parameters at compile time through a file called Pods.xcconfig.

8. Version control Principle

When pod Install is executed, Cocoapods generates a podfile.lock file. The greatest use of this 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 podfile.lock file records the latest version of the Podfile. lock library, 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:

  • Change the podfile to point to the latest version of the React dependency library
  • Run the pod update command.

Because the podfile.lock file is so important for teamwork, it should be added to version control

9. Third party library using another third party library

For example: mjExtension. Framework and sdWebImage. Framework, how to use a class from the SDWebImage library in a class of MJExtension?

  1. Locate MJExtension in pod and import sdWebImage. Framework in Build Phases.
  2. In pod’s MjExtension. Framework, go to Build Settings to configure Debug and Release for Framework Search Paths. Add PODS_CONFIGURATION_BUILD_DIR/SDWebImage “;
  3. Add to pod’s mjextend.xcconfig: FRAMEWORK_SEARCH_PATHS = “PODS_CONFIGURATION_BUILD_DIR/SDWebImage”

10. Specify the REPO mirror

Pod repo remove master pod repo add master https://gitee.com/mirrors/CocoaPods-Specs (gitee mirror) pod repo update pod repo Remove the master pod repo add master (tsinghua mirror) https://mirrors.tuna.tsinghua.edu.cn/git/CocoaPods/Specs.git pod repo update source 'https://gitee.com/mirrors/CocoaPods-Specs.git' source 'https://mirrors.tuna.tsinghua.edu.cn/git/CocoaPods/Specs.git'Copy the code

11. Remove the CocoaPods from the project

  1. Delete the Podfile, Podfile.lock, and Pods folders in the project folder
  2. Delete the.xcworkspace file
  3. Open the XCodeProj file and delete the Pods folder in the project along with the Pods.xcconfig reference and the libPods.a static library
  4. Open the Build Phases option and remove the Check Pods manifest. lock, Copy Pods Resources, and Embeded Pods Frameworks options

Complete the above steps to remove CocoaPods from the project, and the project can compile and run.