CocoaPods is a “package management tool” for macOS and iOS application development. CocoaPods makes it easy to manage third-party libraries and publish your own.

CocoaPods aims to solve two problems: first, it simplifies much of the configuration involved in importing third-party code, allowing you to automatically configure compilation options; Second, it is very convenient to find suitable third-party libraries, so as to shorten the development cycle of software and improve the quality of software.

Here’s what you’ll learn from reading this article

  • How do I install CocoaPods
  • How do I use CocoaPods to search for libraries of interest
  • Use CocoaPods to manage your third-party library dependencies
  • Be familiar with the general workings of CocoaPods
  • Learn about the CocoaPods file system
  • Familiar with CocoaPods cache mechanism
  • Start making a private library
  • Publish private libraries to private sources
  • Related issues and solutions

A profound

Install CocoaPods

You may need to go “scientific online” to get it installed. Sometimes you may encounter permissions issues or versioning inconsistencies between team members. Using bundles to manage CocoaPods is an option. Learn about bundles (Bundler.io).

Install via RubyGems: Terminal type the command sudo gem install cocoapods.

Initialize the project

1. Create a file namedPodsDemo 的 iOSengineering

The directory structure is as follows:

. ├ ─ ─ PodsDemo │ ├ ─ ─ AppDelegate. H │ ├ ─ ─ AppDelegate. M │ ├ ─ ─ Assets. Xcassets │ │ ├ ─ ─ AccentColor. Colorset │ │ │ └ ─ ─ Contents. Json │ │ ├ ─ ─ AppIcon. Appiconset │ │ │ └ ─ ─ Contents. The json │ │ └ ─ ─ Contents. The json │ ├ ─ ─ Base. Lproj │ │ ├ ─ ─ LaunchScreen. The storyboard │ │ └ ─ ─ Main. The storyboard │ ├ ─ ─ the Info. The plist │ ├ ─ ─ SceneDelegate. H │ ├ ─ ─ SceneDelegate. M │ ├ ─ ─ ├─ ├─ class.htm ├─ class.txt ├─ class.txt ├─ class.txt ├─ class.txt │ ├ ─ ─ contents. Xcworkspacedata │ ├ ─ ─ xcshareddata │ │ └ ─ ─ IDEWorkspaceChecks. Plist │ └ ─ ─ xcuserdata │ └ ─ ─ The username. Xcuserdatad │ └ ─ ─ UserInterfaceState. Xcuserstate └ ─ ─ xcuserdata └ ─ ─ the username. Xcuserdatad └ ─ ─ xcschemes └ ─ ─ xcschememanagement.plistCopy the code

2. Initialize pod

When the POD is initialized, a Podfile is created in the root directory according to projectname.xcodeProj.

Command: pod init.

Directory structure:

├─ Podfile // New │ ├─ ├.h │ ├─ │ ├.m │ ├── │ ├.m │ ├─ │ ├.m │ ├.m │ ├─ AccentColor. Colorset │ │ │ └ ─ ─ Contents. The json │ │ ├ ─ ─ AppIcon. Appiconset │ │ │ └ ─ ─ Contents. The json │ │ └ ─ ─ Contents. The json │ ├ ─ ─ Base. Lproj │ │ ├ ─ ─ LaunchScreen. The storyboard │ │ └ ─ ─ Main. The storyboard │ ├ ─ ─ the Info. The plist │ ├ ─ ─ SceneDelegate. H │ ├ ─ ─ SceneDelegate. M │ ├ ─ ─ ViewController. H │ ├ ─ ─ ViewController. M │ └ ─ ─ main. M └ ─ ─ PodsDemo. Xcodeproj ├ ─ ─ project. Pbxproj ├ ─ ─ project. Xcworkspace │ ├ ─ ─ contents. Xcworkspacedata │ ├ ─ ─ xcshareddata │ │ └ ─ ─ IDEWorkspaceChecks. Plist │ └ ─ ─ Xcuserdata │ └ ─ ─ username. Xcuserdatad │ └ ─ ─ UserInterfaceState. Xcuserstate └ ─ ─ xcuserdata └ ─ ─ username. Xcuserdatad └ ─ ─ Xcschemes └ ─ ─ xcschememanagement plistCopy the code

3. Install dependencies

Analyze dependencies, install dependencies, and create the necessary files.

Command: pod install.

Directory structure:

│ ├─ Local Podspecs │ ├─ Manifest.Lock │ ├─ New Podspecs │ ├─ New Podspecs │ ├─ New Podspecs │ ├─ New Podspecs │ ├─ New Podspecs │ ├─ New Podspecs │ ├─ New Podspecs │ ├─ New Podspecs │ ├─ ├─ project.xcodeProj │ ├─ xcuserdata │ ├─ xcuserdata │ ├─ xcuserdata │ ├─ xcuserdata │ ├─ The Pods - PodsDemo. Xcscheme │ │ └ ─ ─ xcschememanagement. Plist │ └ ─ ─ Target Support Files │ └ ─ ─ the Pods - PodsDemo │ ├ ─ ─ The Pods - PodsDemo - Info. Plist │ ├ ─ ─ the Pods - PodsDemo - acknowledgements. Markdown │ ├ ─ ─ the Pods - PodsDemo - acknowledgements. Plist │ ├ ─ ─ Pods-dummy. m │ ├─ Pods-PodsDemo- Umbrella. H │ ├─ Pods-PodsDemo.debug. Xcconfig │ ├─ Pods-PodsDemo └ ─ ─ the Pods - PodsDemo. Release. Xcconfig ├ ─ ─ PodsDemo │ ├ ─ ─ AppDelegate. H │ ├ ─ ─ AppDelegate. M │ ├ ─ ─ Assets. Xcassets │ │ ├ ─ ─ AccentColor. Colorset │ │ │ └ ─ ─ Contents. The json │ │ ├ ─ ─ AppIcon. Appiconset │ │ │ └ ─ ─ Contents. The json │ │ └ ─ ─ Contents. The json │ ├ ─ ─ Base. Lproj │ │ ├ ─ ─ LaunchScreen. The storyboard │ │ └ ─ ─ Main. The storyboard │ ├ ─ ─ the Info. The plist │ ├ ─ ─ SceneDelegate. H │ ├ ─ ─ SceneDelegate. M │ ├ ─ ─ ViewController. H │ ├ ─ ─ ViewController. M │ └ ─ ─ main. M ├ ─ ─ PodsDemo. Xcodeproj │ ├ ─ ─ project. Pbxproj │ ├ ─ ─ project. Xcworkspace │ │ ├ ─ ─ contents. Xcworkspacedata │ │ ├ ─ ─ xcshareddata │ │ │ └ ─ ─ IDEWorkspaceChecks. Plist │ │ └ ─ ─ xcuserdata │ │ └ ─ ─ username. Xcuserdatad │ │ └ ─ ─ UserInterfaceState. Xcuserstate │ └ ─ ─ xcuserdata │ └ ─ ─ Sci-tech ├ ─ sci-tech sci-tech ├ ─ sci-tech sci-tech sci-tech sci-tech sci-tech sci-tech sci-tech sci-tech sci-tech sci-tech contents.xcworkspacedataCopy the code

4. Open the project

Open the podsDemo.xcworkspace file instead of PodsDemo.xcodeProj.

We found the following four files and folders:

  • Podsdemo. xcworkspace: Used to manage the project. It manages all the targets.

  • Podfile: This is the most important file that CocoaPods users have access to, and we need to configure it directly so that CocoaPods understands our intent to rely on third-party libraries. Simple configuration of the project is also supported here.

  • Podfile. Lock: This is also an important file that is sometimes overlooked by many developers and is strongly recommended for versioning because POD allows semantically constrained versions of tripartite libraries. Submitting the podfile. lock file can prevent mishaps caused by inconsistent library versions between team developers, or between developers and balers.

  • Pods: The pod install command automatically generates a project to manage all dependent libraries, pods.xcodeProj, which you can ignore during normal development. Other dependent third-party libraries will also be placed in this directory.

Update “Source” (Index library)

After the third-party database releases a version, update the source to update the new version. You are advised to update the source frequently.

Update the specified source: POD repo update sourceName.

Update all sources: POD repo Update.

Find a tripartite library that interests you

In the process of rapid business iteration, quickly finding a suitable library can improve productivity and code quality, which is not to encourage something for nothing but to recommend not reinventing the wheel.

1, Pod Search Alamofire: find the library whose name you know.

-> Alamofire (5.4.3)
   Elegant HTTP Networking in Swift
   pod 'Alamofire'.'~ > 5.4.3'- Homepage: https://github.com/Alamofire/Alamofire - Source: https://github.com/Alamofire/Alamofire.git - Versions: 5.4.3, 5.4.2 5.4.1, 5.4.0 5.3.0, 5.2.2, 5.2.1, 5.2.0, 5.1.0, 5.0.5, 5.0.4, 5.0.3, 5.0.2, 5.0.1, 5.0.0, 5.0.0 - rc. 3, 5.0.0 - rc. 2, 5.0.0 - rc. 1, 5.0.0 - beta. 7, 5.0.0 - beta. 6, 5.0.0 - beta. 5, 5.0.0 - beta. 4, 5.0.0 - beta. 3, 5.0.0 - beta. 2, 4.9.1 5.0.0. Beta. 1, 4.9.0, 4.8.2, 4.8.1, 4.8.0, 4.7.3, 4.7.2, 4.7.1, 4.7.0, 4.6.0, 4.5.1, 4.5.0, 4.4.0, 4.3.0, 4.2.0, 4.1.0, 4.0.1, 4.0.0 3.5.1 track of 3.5.0, 3.4.2, 3.4.1 track, 3.4.0, 3.3.1, 3.3.0, 3.2.1, 3.2.0, 3.1.5, 3.1.4, 3.1.3, 3.1.1 and 3.1.2, 3.1.0, 3.0.1, 3.0.0 3.0.0 - beta. 3, 3.0.0 - beta. 2, 3.0.0 - beta. 1, 2.0.2, 2.0.1, 2.0.0, 2.0.0 - beta. 4, 2.0.0 - beta. 3, 2.0.0 - beta. 2, 2.0.0 - beta. 1, 1.3.1, 1.3.0, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.5, 1.1.4, 1.1.3 [bb - cocoapods - specs repo]...Copy the code

2, POD Search HTTP Networking in Swift

You can also find CocoaPods through cocoapods.org.

Manage your dependencies

The editorPodfileConfigure your dependencies

Podfile

source 'https://github.com/CocoaPods/Specs.git'

platform :ios.'9.0'

target 'PodsDemo' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!
  # Pods for PodsDemo
  pod 'AFNetworking'.'3.2.1'
end
Copy the code

Source: CocoaPods supports adding multiple sources, which is useful when you want to publish your own private libraries. If you are constantly frustrated by the slow pod repo update, You can create an image of CocoaPods’ official source, host it on your GitLab and sync it regularly so that your fellow developers can quickly update it without climbing walls.

Target: Specify which target the following dependencies are for. Podfile allows you to configure different dependencies for different targets in workspace.

Pod: Adds a dependency.

Ruby syntax

You may find this a little strange but natural, and it’s probably a good time to start learning Ruby.

Ruby methods: Source, target, pod these are All Ruby methods, and Ruby syntax allows method calls without parentheses, which is good for this scenario.

Ruby closure:

 target 'PodDemo' do.end

 post_install do |installer|.end
Copy the code

Ruby enumeration: :ios is an enumeration of Ruby.

Podfiles use A Ruby-based DSL syntax that feels comfortable as configuration rather than code.

CocoaPods file system

Knowing CocoaPod’s file system will make it easier for you to handle CocoaPods exceptions, because knowing about them really solves a lot of problems.

The Pods directory

CocoaPods keeps the third party inventory in the./Pods folder. The source code here is not recommended to change, and even if it does, the next pod install change will be overwritten.

The index libraryspecs(source)

An index repository is a git repository that contains.podspec files that you add to your Podfile via source. You can update the index repository with git pull. However, the index library is often updated using the command pod repo update.

Cocoapods /repos/. You can type ls ~/. Cocoapods /repos/ to view your own index library.

Yao:~ username$ ls ~/.cocoapods/repos/
Spec_Lock		bb-cocoapods-specs	cocoapods
bb-bp_repos		trunk
Copy the code

The cache

CocoaPods caches third-party library source code and podspec files, and if a version of a library has been downloaded, the next pod install will copy it directly from the cache to the working directory (even if another project relies on the library instead of re-downloading it). This is why people can’t pull up new code when you change the source code without changing the version number.

The location of the cache here: ~ / Library/Caches/CocoaPods /, can type in the open end ~ / Library/Caches/CocoaPods/view their cache.

Source code cache:

Yao: $ls ~ ~ username/Library/Caches/CocoaPods/Pods/Release/Alamofire/e8a 4.9.1-85 / Source/AFError. Swift ResponseSerialization.swift Alamofire.swift Result.swift DispatchQueue+Alamofire.swift ServerTrustPolicy.swift MultipartFormData.swift SessionDelegate.swift NetworkReachabilityManager.swift SessionManager.swift Notifications.swift TaskDelegate.swift ParameterEncoding.swift Timeline.swift Request.swift Validation.swift Response.swiftCopy the code

Podspec cache:

Yao: $ls ~ ~ username/Library/Caches/CocoaPods/Pods/Specs/Release/Alamofire / 4.9 podspec. Json 5.1. Podspec. JsonCopy the code

What happens after pod Install is executed

You’ve probably already used CocoaPods to look up third-party libraries and import your own projects, but now you’re wondering what Pod Intall does, let’s take a look.

To see what’s going on, it’s really easy to just add –verbose to pod Install.

Terminal type pod Install –verbose to see details.

Yao:PodsDemo username$ pod install --verbose
  Preparing

Analyzing dependencies

Inspecting targets to integrate
  Using `ARCHS` setting to build architectures of target `Pods-PodsDemo`: (``)

Finding Podfile changes

Resolving dependencies of `Podfile`

Comparing resolved specification to the sandbox manifest

Downloading dependencies
  - Running pre install hooks

Generating Pods project
  - Creating Pods project
  - Installing files into Pods project
    - Adding sourcefiles - Adding frameworks - Adding libraries - Adding resources - Linking headers - Installing Pod Targets - Installing Aggregate Targets - Installing Target 'PODs-Podsdemo' iOS 9.0 - Generating info. plist file at 'Pods/Target Support Files/Pods-PodsDemo/Pods-PodsDemo-Info.plist` - Generating module map file at `Pods/Target Support Files/Pods-PodsDemo/Pods-PodsDemo.modulemap` - Generating umbrella header at `Pods/Target Support Files/Pods-PodsDemo/Pods-PodsDemo-umbrella.h` - Generating dummysourceat `Pods/Target Support Files/Pods-PodsDemo/Pods-PodsDemo-dummy.m` - Generating deterministic UUIDs - Stabilizing target  UUIDs - Running post install hooks - Writing Xcode project file to `Pods/Pods.xcodeproj` Cleaning up sandbox directory Integrating client project Integrating target `Pods-PodsDemo` (`PodsDemo.xcodeproj` project) - Running post integrate hooks - Writing Lockfilein `Podfile.lock`
  - Writing Manifest in `Pods/Manifest.lock`
  CDN: trunk Relative path: CocoaPods-version.yml exists! Returning local
  because checking is only perfomed inrepo update -> Pod installation complete! There are 0 dependencies from the Podfile and 0 total pods installed. [!]  The Podfile does not contain any dependencies.Copy the code

As you can see, there’s a lot going on, so let’s walk through it step by step.

Read the Podfile file

When you execute the POD command, CocoaPods reads the contents of the Podfile and executes the contents of the file using the eval method.

CocoaPods downloads the “sources” added by Source into the ~/. CocoaPods directory, which holds podspec files from the third party libraries. The PodSpec file instructs the POD on how to configure the three-party library, which can be interpreted as an instruction manual for the library.

Versioning and conflicts

CocoaPods uses “Semantic Versioning” to constrain Versioning dependencies. Since the conflict resolution system is built between patched releases that are not major changes, it makes it much easier to resolve dependencies. For example, if two different Pods rely on two versions of XXSDK, let’s say one relies on 2.3.1 and the other relies on 2.3.3, then the conflict resolution system can use the latest version 2.3.3 because it is backward compatible with 2.3.1.

Of course, there will always be conflicts that need to be resolved manually. If one library relies on XXSDK 1.2.5 and another on 2.3.1, then only the end user can resolve the conflict by explicitly specifying a version to use.

Loading source files

The next step CocoaPods performs is to load the source code. Each.podspec file contains an index of the source code, usually wrapped around a Git address and git tag (the source code doesn’t have to be hosted on GitHub or GitLab, SVN or other file hosting forms are supported, of course). Them to commit spoils stored in ~ / Library/Caches/CocoaPods. The creation of files in this path is the responsibility of Core Gem.

CocoaPods downloads the source files into the Pods directory according to the Podfile,.PodSpec, and cache file information.

Generate the Pods. Xcodeproj

Each time Pod Install is executed, CocoaPods updates Pods. Xcodeproj using the Xcodeproj gem component if changes are detected. If the file does not exist, it is generated with the default configuration. Otherwise, the existing configuration items will be loaded into the memory.

Analyze CocoaPods further

For further analysis, please read CocoaPods source code (github.com/CocoaPods/C…

Installing third-party Libraries

When CocoaPods adds a third-party library to a project, it adds more than just code. Since each third-party library has a different target, there are several files that need to be added for each library, and each target needs to:

  • One that contains compilation options.xcconfigfile
  • One contains both compiler Settings andCocoaPodsDefault configuration private.xcconfigfile
  • A compilation is requiredprefix.pchfile
  • aSwift,Objective-CMix must-umbrella.hfile
  • A declaration, export module used.modulemapfile
  • Another file required for compilationdummy.m

Once the above content is complete for each pod target, the entire Pods Target is created. If the source contains a resource bundle, the instruction to add the bundle to the program target is added to the Pods-resources.sh file. There is also a file called Pods-environment.h, which contains macros that can be used to check whether a component is from pod.

Write to disk

Until now, much of the work was done in memory. In order for these results to be reused, we need to keep all the results in one file. So the Pods.xcodeProj files are written to disk, and two other very important files, Podfile.lock and manifest.lock, are written to disk.

Podfile.lock

This is one of the most important files CocoaPods creates. It records each installed version of the POD that needs to be installed. If you want to know what version of CocoaPods you have installed, check out this file. It is recommended to add the podfile. lock file to version control to help improve consistency across the team.

Manifest.lock

This is a copy of the podfile.lock file that is created each time the pod Install command is run. If you’ve ever encountered an error where The sandbox is not in sync with The podfile. lock file, This is caused by a discrepancy between the manifest. lock file and the podfile. lock file. Since the directory where Pods are located is not always under version control, this ensures that developers update their Pods before launching the App.

xcproj

If you already have xcPROj installed on your system, it will perform a touch on the Pods.xcodeProj file to convert it to the old ASCII PList file. Why do you do that? Xcode still relies on this format, although it has long been unsupported by other software. Without xcPROj, your Pods.xcodeProj file will be stored as a PList file in XML format, and when you open it with Xcode, it will be overwritten and cause a lot of file changes.

Making a private library

When the project source code is proliferating and the team is growing, componentization may be a topic you can’t get around, but you can’t make your in-house libraries available to everyone in the form of CocoaPods libraries, so you need to make your in-house libraries available only to your team.

Create a “private POD library”

You can create libraries using the following commands provided by CocoaPods.

Create a new library:

1, pod lib create XXX.

2. Select the appropriate option in the interactive dialog box.

3. After completing the above interaction, you will find that a complete set of library templates have been generated in the directory where you executed the command. Now you can start developing the private library functionality.

Like this:

Yao:Desktop username$ pod lib create XXSDK Cloning `https://github.com/CocoaPods/pod-template.git` into `XXSDK`. Configuring XXSDK template. / System/Library/Frameworks/Ruby framework Versions / 2.6 / usr/lib/Ruby/server/universal - darwin20 / rbconfig rb: 229: warning: Insecure world writable dir /Users/username/.cargo/binin PATH, mode 040777
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.

------------------------------

To get you started we need to ask a few questions, this should only take a minute.

If this is your first time we recommend running through with the guide: 
 - https://guides.cocoapods.org/making/using-pod-lib-create.html
 ( hold cmd and double click links to open in a browser. )


What platform do you want to use?? [ iOS / macOS ]
 > iOS

What language do you want to use?? [ Swift / ObjC ]
 > Swift

Would you like to include a demo application with your library? [ Yes / No ]
 > Yes

Which testing frameworks will you use? [ Quick / None ]
 > None

Would you like to do view based testing? [ Yes / No ]
 > No
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint: 	git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main'.'trunk' and
hint: 'development'. The just-created branch can be renamed via this command: hint: hint: git branch -m <name> Running pod install on your new library. / System/Library/Frameworks/Ruby framework Versions / 2.6 / usr/lib/Ruby/server/universal - darwin20 / rbconfig rb: 229: warning: Insecure world writable dir /Users/username/.cargo/bininPATH, Mode 040777 Analyzing Dependencies Downloading Dependencies Installing XXSDK (0.1.0) Generating Pods Project Integrating  client project [!]  Please close any current Xcode sessions and use `XXSDK.xcworkspace`forthis project from now on. Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed. [!]  Your project does not explicitly specify the CocoaPods master specs repo. Since CDN is now used as the default, you may safely remove it from your repos directory via `pod repo remove master`. To suppress this warning please add `warn_for_unused_master_specs_repo =>false` to your Podfile.

 Ace! you're ready to go! We will start you off by opening your project in Xcode open 'XXSDK/Example/XXSDK.xcworkspace' To learn more about the template see `https://github.com/CocoaPods/pod-template.git`. To learn more about creating a new pod, see `https://guides.cocoapods.org/making/making-a-cocoapod`.Copy the code

4. The directory structure is as follows:

Example: The Example project is debugged here during development. XXSDK: private library source code.

  • XXSDK/Assets: Store resources, such as pictures, videos, and JSON files
  • XXSDK/Classes: The code source files are here

Podspec: One of the files you’ll care about most is the library configuration file, where you configure build options, manage source code, resources, and dependencies. It instructs CocoaPods on how to rely on and configure the library, and can even configure the host project, which can be understood as the library’s drawings.

2. Transform an existing module into a library:

1. Organize your code files and resource files in the above format.

2. Create a podspec file: run podspec create XXSDK.

Yao:XXSDK username$ pod spec create XXSDK / System/Library/Frameworks/Ruby framework Versions / 2.6 / usr/lib/Ruby/server/universal - darwin20 / rbconfig rb: 229: warning: Insecure world writable dir /Users/username/.cargo/bin in PATH, mode 040777 Specification created at XXSDK.podspecCopy the code

Create Example project:

  • Enter theExampleThe root directory
  • pod init
  • pod install
  • PodfileDepend on your libraries locally in relative pathspod "XXSDK", :path => ".. /"Here,pathTo point topodspecDirectory where
  • pod installIn the afterExampleProject debug your library

Configuration podspec

When creating class files and adding resource files in the above project, you need pod install to debug the demo project, because the demo project also introduced the library in the form of a third-party library dependency.

Here’s a look at podSpec files:

# # Be sure to run `pod spec lint XXSDK.podspec' to ensure this is a # valid spec and to remove all comments including this before submitting the spec. # # To learn more about Podspec attributes see https://guides.cocoapods.org/syntax/podspec.html # To see working Podspecs in the CocoaPods repo see https://github.com/CocoaPods/Specs/ # Pod: : Spec. New do | Spec | # - Spec Metadata -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - # # # These will help people to find your library, and whilst it # can feel like a chore to fill in it's definitely to your advantage. The # summary should be tweet-length, # spec.name = "XXSDK" spec.version = "0.0.1" spec.summary = "A short description of XXSDK." # This description is used to generate tags and improve search results. # * Think: What does it do? Why did you write it? What is the focus? # * Try to keep it short, snappy and to the point. # * Write the description between the DESC delimiters below. # * Finally, don't worry about the indent, CocoaPods strips it! spec.description = <<-DESC DESC spec.homepage = "http://EXAMPLE/XXSDK" # spec.screenshots = "www.example.com/screenshots_1.gif", "Www.example.com/screenshots_2.gif" # - Spec License -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - # # #  Licensing your code is important. See https://choosealicense.com for more info. # CocoaPods will detect a license file if there is a named LICENSE* # Popular ones are 'MIT', 'BSD' and 'Apache License, Version 2.0'. # spec.license = "MIT (example)" # spec.license = {:type => "MIT", : the file = > "FILE_LICENSE} #" --, the Author Metadata -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - # # # Specify the authors of the library, with email addresses. Email addresses # of the authors are extracted from the SCM log. E.g. $ git log. CocoaPods also # accepts just a name if you'd rather not provide an email address. # # Specify a social_media_url where others can refer to, for example a twitter # profile URL. # spec.author = { "username" => "[email protected]" } # Or just: spec.author = "username" # spec.authors = { "username" => "[email protected]" } # spec.social_media_url = "Https://twitter.com/username" # - Platform Specifics -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - # # # the If  this Pod runs only on iOS or OS X, then specify the platform and # the deployment target. You can optionally include the target after the platform. # # spec.platform = :ios # spec.platform = :ios, "5.0" # When using multiple platforms # spec.ios. Deployment_target = "5.0" # spec.osx.deployment_target = "10.7" # Spec.watchos. deployment_target = "2.0" # spec.tvos.deployment_target = "9.0" # -- Source Location -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - # # # Specify the location from where the source should be retrieved. # Supports git, hg, bzr, svn and HTTP. # spec.source = { :git => "http://EXAMPLE/XXSDK.git", : tag = > "# {spec. Version}} #" -- the Source Code -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - # # # CocoaPods is smart about how it includes source code. For source files # giving a folder will include any swift, h, m, mm, c & cpp files. # For header files it will include any header in the folder. # Not including the public_header_files will  make all headers public. # spec.source_files = "Classes", "Classes / / *. * * {h, m}" spec. Exclude_files = "Classes/Exclude" # spec. Public_header_files = "Classes / / *. * * h" # -- - Resources -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - # # # A list of Resources that included with the Pod. These are copied into the # target bundle with a build phase script. Anything else will be cleaned. # You can preserve files from being cleaned, please don't preserve # non-essential files like tests, examples and documentation. # # spec.resource = "icon.png" # spec.resources = "Resources/*.png" # spec.preserve_paths = "FilesToSave", "MoreFilesToSave # -" Project Linking -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- # # # Link your library with frameworks, or libraries. Libraries do not include # the lib prefix of their name. # # spec.framework = "SomeFramework" # spec.frameworks = "SomeFramework", "AnotherFramework" # spec.library = "iconv" # spec.libraries = "iconv", "Xml2 # -" Project Settings -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - # # # If your library depends on  compiler flags you can set them in the xcconfig hash # where they will only apply to your library. If you depend on other Podspecs # you can include multiple dependencies to ensure it works. # spec.requires_arc = true # spec.xcconfig = {"HEADER_SEARCH_PATHS" => "$(SDKROOT)/usr/include/libxml2"} # spec.dependency "JSONKit", "~> 1.4" endCopy the code

Parameter Meaning:

Configurable properties very much, visit the website (guides.cocoapods.org/syntax/pods…). To learn more

attribute meaning
name The library name
version The version number
authors The author
homepage Web site home page
summary A brief description of the library
source Source File Source
swift_version To support theSwiftVersion, where you typically specify a larger version, such as 4.0, rather than 4.1 or 4.2
source_files The source file to expose for the library
framework Dependent system libraries
weak_frameworks Weakly dependent system libraries – Some libraries should be used when new devices or systems exist, and code level compatibility should be maintained
dependency Dependencies on tripartite libraries or other submodules
info_plist The info_plist configuration overrides the initial value of the dependent project (use with caution)
requires_arc This is where part of the code is configured to manage memory using MRC
pod_target_xcconfig Pod of the target.xcconfigconfiguration
public_header_files Exposed public header files
exclude_files List of file patterns that should be excluded from other file patterns

Private source scheme

CocoaPods allows you to publish private libraries to private sources, in which case you need to maintain your own sources.

Create and maintain your own “sources”

The “source” is the Git repository where the private.podspec file is stored. When pod install, pod gets tripartite library information from the source and can be hosted to GitLab.

All you need to do is create a GitLab private repository as the source.

Add your own source to your Podfile

Add a source using source XXX; For example, the source ‘https://github.com/CocoaPods/Specs.git’.

source 'http://gitlab.XXX/XXX/PrivateSpecs.git'
Copy the code

3. Private library development and maintenance

Source code development, resource management and PodSpec maintenance

Publish private libraries to private sourcesPrivateSpecs

To publish a library to a private source is to copy that version of the podSpec file to a regular folder in the “source” repository, and pod will find your private library when pod install is executed.

The directory structure looks like this:

  1. Create a folder under the Source repository with the same name as the repository
  2. Create a folder named version number in this folder
  3. Copy the podSpec file to a folder with the corresponding version number

You don’t have to do this manually, but CocoaPods provides the tools to do it for you

  • pod lib lint XXSDK.podspecVerification validity
  • pod repo push privateSpecs XXSDK.podspecPublish to private sources

Of course, if you feel that Lint validation is too harsh, you can also use scripts to automate version distribution by following the rules described above.

Solution set

How do I use private libraries?

You need to add a private source to the Podfile header to tell pod where to get your private library.

Podfile header adds a private source

source 'http://gitlab.XXX/XXX/PrivateSpecs.git'
Copy the code

The main project could not find your component

Please check whether the problem “How to use private libraries” is caused.

The new file in the component disappears

Sometimes you might run into a problem like this: you’ve just finished developing a feature and you’re ready to show it off to your boss. Then you hit Pod Install, and when Xcode is compiled, you find an error and the files you just developed are missing.

Pod Install will not be referenced in source_files if you create files in the wrong place.

Solution: Show in Finder, find missing files and put them in the right place.

Where to put images, videos, fonts, JSON files, etc.?

You are advised to use resource_bundle to package resources into bundles. Note that these resources must be loaded from the corresponding bundles when used.

spec.ios.resource_bundle = { 'MapBox' => 'MapView/Map/Resources/*.png' }

How to useresource_bundleSpecified resource file?

In this case, you need to load resources from the specified bundle, and the files are packaged as bundles and placed under the mainbundle. Since bundles may be organized differently from library to library, the directory structure is not fixed. You can unpack the application’s.ipa file to explore this rule.

Private library contains.framework,.aHow to configurepodspec

It is recommended that you understand the podSpec fields first

spec.ios.vendored_frameworks = 'Frameworks/MyFramework.framework'
spec.vendored_frameworks = 'MyFramework.framework'.'TheirFramework.xcframework'

spec.ios.vendored_library = 'Libraries/libProj4.a'
spec.vendored_libraries = 'libProj4.a'.'libJavaScriptCore.a'
Copy the code

Module A that supports iOS 9.0 depends on module B that supports iOS 10

If this is the case, evaluate whether module A can be upgraded to iOS 10 or module B can be upgraded to iOS 9. If not, consider replacing one or the other.

Your library provides core capabilitiescoreSpecific functionsASome lines of business rely only on core capabilities

It may be better to design private libraries in a subspec “submodule” way.

The podSpec file is configured like this

  spec.subspec 'core' do |core|
    core.source_files = 'Classes/core/**/*.{swift,h,m,c,mm}'
  end

  spec.subspec 'A' do |A|
    A.source_files = 'Classes/A/**/*.{swift,h,m,c,mm}'
    A.dependency 'XXSDK/core'
  end
  
  spec.subspec 'B' do |B|
    B.source_files = 'Classes/B/**/*.{swift,h,m,c,mm}'
    B.dependency 'XXSDK/core'
  end
Copy the code

Podfile references this

pod XXSDK/core
or
pod XXSDK/bbf
or
pod XXSDK
Copy the code

Objective-c and Swift are mixed in the module

In the context of Apple’s strong push for Swift, business iteration will naturally be written in Swift, Swift will inevitably call Objective-C, and Objective-C will probably call Swift.

To call Swift in Objective-C: import the bridge file ModuleName- swift. h and compile it to use it.

Swift calls Objective-C: can be called directly.

Urgent fix for tripartite library bug

Feedback to the third party library author is the best way to do this, but sometimes you can’t wait and have to fix it yourself. You know how to fix the bug at the code level, but it doesn’t seem worth maintaining a mirror because you can’t change the source code.

You can modify the tripartite library source file in your Podfile like this:

Podfile file

post_install do |installer|
    find_and_replace("xx.Swift", bugCode, fixCode)
end
Copy the code

Unable to pull the latest code after fixing bug

Pod Install cannot pull the latest tag code after modifying the source code of the library. This may be because you changed the code of a library without changing the version number and re-issued the version.

Even if you tag it again, Pod Install will copy the code directly from the cache to the working directory.

There are two solutions to this problem:

First, modify the version number to release a new version.

If you don’t want to release new versions frequently, you need to:

1. Re-tag.

2. Clear the cache:

Pod cache clean XXSDK or from here ~ / Library/Caches/CocoaPods/find your Library removed manually.Copy the code

3, Pod install.

You want to ignore Pods files that have already been submitted

One day, your boss clones the iOS project and finds that the entire project is 10 GB in size. He asks you what’s in your Pods directory and can you ignore it? When you realize Pods shouldn’t be in version control, you go to.gitignore and add Pods/, and a month later it doesn’t work.

To remove git management, run the following command:

Add Pods/ to the.gitignore file.

Git git git git git git git

cdGit rm -r -- cached.git add. Git commit -m"Ignore Pods files."
Copy the code

ignorePodswarning

Ignore POD warnings by adding inhibit_all_WARNINGS to the appropriate target in your Podfile.

I want to be able to modify and commit component code in the main project as well

Local dependencies allow you to modify the source code directly and commit it. Reference dependencies like this: pod ‘XXSDK’, :path => ‘XXX/XXX/xxsdk.podspec’

Componentized initial maintenance costs are too high

In the initial stage of componentization, multiple modules are often modified simultaneously and need to be coordinated in the main project. Remote methods can not be modified and submitted in the main project depending on these components. Then your componentization process will be a serious drag on business iteration and will be mocked by teammates.

CocoaPods locks the remote tripartite library by default. You should be careful not to add important code to the tripartite library even if you choose to unlock the file, because changes will disappear after Pod Install and cannot be retrieved. Solution: Local dependency combined with Git subModule. Git submodule is introduced to use relative path. Each member of the team uses relative path to reference submodule: pod ‘XXSDK’, :path => ‘Submodules/XXSDK’. Of course, the module should be released as soon as possible after stability and remove the submodule.

summary

CocoaPods makes iOS development easier. You can use CocoaPods to create your own tripartite libraries, distribute your code to CocoaPods as a tripartite library for the iOS ecosystem, and distribute your code to CocoaPods for internal use. Knowing how CocoaPods works will allow you to take advantage of open source tools to increase your productivity and open your mind to better solutions.