Part 1. Detailed instructions for creating your CocoaPod

One cannot fail to mention previously published articles on this topic - an introduction to Cocoapods and a brief summary on creating your own “pod”.
The last article cited gave the impetus in the right direction, but lacked the knowledge to fully understand the information provided. The purpose of this article is to describe in as much detail as possible the process of creating and using your own CocoaPod, and hereinafter for brevity - “pod”. Well, to organize your knowledge in this area.

Introduction

After reviewing the first article mentioned, we already have CocoaPods installed and ready for battle on our Mac, an understanding of what it is and what it is for. Why do you need your own "pod" should also be clear.

On the project page, the general principle of building your own “pod” is described insignificantly . The directory structure recommended by the authors for the development of “pod” is as follows:

.
├── Classes
    └── ios
    └── osx
├── Resources
├── Project
    └── Podfile
├── LICENSE
├── Readme.markdown
└── NAME.podspec

What is what:

• Classes - a directory in the subdirectories of which are the sources of your "pod" 'for iOS and / or OS X
• Resources - images, videos, other binaries, Core Data models, etc.
• Project - a project using your "pod", as a rule - a project which shows examples of using your "pod", and it is highly desirable with unit tests
• Podfile - in this file, as it should already be known, the dependencies of the project on various "pods" are indicated, in this case, on our
• Omit files that speak for themselves by their name
• NAME.podspec - specification of the created "pod" 'a

Create a “pod” project

So, let's begin. Just in case, the sample project lies on GitHub .
Create your GitHub repository with a name like MyCustomPod .
Let's create our “pod” project, for this we enter the following in the terminal:

$ mkdir ~/Documents/PodSample
$ cd ~/Documents/PodSample
$ git init
$ git remote add origin https://github.com/username/MyCustomPod.git
$ touch LICENSE
$ git add LICENSE && git commit -m "License file"
$ git push -u origin master
$ mkdir Classes

A brief description of what is happening.
We create a local git repository, bind it to GitHub, create and commit a file where the licensing scheme for the project will be described, and send the changes to GutHub. We create the Classes directory in which the source code of the "pod" itself will lie. Subdirectories same Classes / ios and Classes / osx create will not, because we focus so far only on one platform - iOS.

Create a “spec”

And again to the theory. Each “pod” has its own specification - “spec”, which describes its metadata: name, version, license, dependencies on the platform version, frameworks used, other “pods”, source repository, use of ARC, etc. All this is written to the NAME.podspec file .
The .podspec file is created by the developer “pod” and placed in a special repository of “spec” s. There is a main repository where all the “pods” that are available by default “live”, such as, for example, the notorious AFNetworking . Your useful “pod” may also appear there. There is also the opportunity to create and use your own “specs” repository, access to which is regulated by you personally.
But back to the beginning. To create your .podspec in the terminal, enter the following command:

$ pod spec create MyLibrary

As a result, in the current directory we get a “spec” template in the form of a file MyLibrary.podspec , which details what each parameter is needed for. A more detailed description of the file format is indicated on the project wiki page .

Everyone knows that the best training is always based on the military principle “from simple to complex”, and we will not shy away from the canons.
To begin, let us set a nominal set of parameters:

Pod::Spec.new do |s|
  s.name                  = "MyLibrary"
  s.version               = "0.0.1"
  s.summary               = "Example of creating own pod."
  s.homepage              = "https://github.com/username/MyCustomPod"
  s.license               = { :type => 'MIT', :file => 'LICENSE' }
  s.author                = { "Username" => "username@mail.domain" }
  s.platform              = :ios, '7.0'
  s.source                = { :git => "https://github.com/username/MyCustomPod.git", :tag => s.version.to_s }
  s.source_files          = 'Classes/*.{h,m}'
  s.public_header_files   = 'Classes/*.h'
  s.framework             = 'Foundation'
  s.requires_arc          = true
end

Let's go over the lines that require an accurate understanding of what is happening:

• version - the current version of our "pod"
• license - in a world where copywriters have been operating for half a century, it is highly advisable to indicate the type of license of your work
• author - as well as the author of this work
• platform - here we indicate that our "pod" was created only for the iOS platform of the minimum version 7.0 , alternatively you can use the deployment_target parameter :

    s.ios.deployment_target = '7.0'
  

• source - indicate the place where the project of our “pod” is located, it is easy to notice that in this case the project is published on GitHub and each version of the project is marked with a corresponding tag, where the tag name matches the version number (a little lower it will be more clear what’s what )
• source_files - list the source files of our “pod”, relative to the project root directory
• public_header_files - pod header files that should be accessible using our pod application
• framework - here you specify the framework that will automatically be connected to the "Pods" project when you install your "pod"
• requires_arc - inform that ARC is used

If you need to specify several authors or frameworks, we convert the parameter name to the plural, for example, authors and list the values ​​separated by commas.
If the project will be used for OS X, then you need to create the Classes / ios and Classes / osx subdirectories , correct the parameter values:

  s.source_files          = 'Classes/**/*.{h,m}'
  s.public_header_files   = 'Classes/**/*.h'

Delete the line with the platform parameter and add the following parameters:

  s.ios.deployment_target = '7.0'
  s.osx.deployment_target = '10.8'

Lint "spec"

The linking process consists of checking the syntax of the .podspec file, the presence of the necessary parameters, the relevance of the parameter values, and attempting to compile our “pod”. There is a so-called “quick” link, where the syntax of the .podspec file and the presence of the required parameters are simply checked , while the “pod” repository and attempts to compile it are not downloaded.
We write the resulting MyLibrary.specpod and first carry out a “quick” link using the --quick switch :

$ pod spec lint ~/Documents/PodSample/MyLibrary.podspec --quick

Ideally, something like:

$ pod spec lint ~/Documents/PodSample/MyLibrary.podspec --quick
 -> MyLibrary (0.0.1)
Analyzed 1 podspec.
MyLibrary.podspec passed validation.

In case of errors, each error is commented quite clearly and the correction does not cause problems.

Next, commit our changes to git:

$ git add MyLibrary.podspec && git commit -m "Completed podspec file"

In order for the complete linking to succeed, we will create a couple of empty files (otherwise we will see an error - " ERROR | [iOS] The` source_files` pattern did not match any file. "):

$ touch Classes/AKClass.m
$ touch Classes/AKClass.h
$ git add Classes/AKClass.* && git commit -m "Empty files for successful lint"

Put down the tag with the current version number and publish our “pod” on GitHub:

$ git tag "0.0.1" && git push origin master --tags

Linting:

$ pod spec lint ~/Documents/PodSample/MyLibrary.podspec

If everything is correctly observed a similar picture:

$ pod spec lint ~/Documents/PodSample/MyLibrary.podspec
 -> MyLibrary (0.0.1)
Analyzed 1 podspec.
MyLibrary.podspec passed validation.

Hurrah! Our "pod" project is configured and does not contain errors.
To be continued.

Planned:
Part 2. Divide our "pod" into modules. We use someone else's “pod” to develop our own.
Part 3. Publication of his "pod" 'a. Shared repository and personal.