Part 1. Detailed instructions for creating your CocoaPod

Not to mention the previously published articles on this topic - an introduction to Cocoapods and a brief summary on creating your own “pod” 'a.
The last mentioned article gave an impetus in the right direction, but lacked the knowledge to fully understand the information provided. The purpose of this article is to describe in detail the process of creating and using your own CocoaPod, then for brevity - “pod” Well, streamline their knowledge in this area.

Introduction

After reading the first article, we already have CocoaPods installed and ready for battle on our Mac, understanding what it is and what it is for. For what you need your own «pod» as it should be clear.

On the project page, the general principle of constructing your own “pod” 'a is described in low detail . The authors recommended directory structure for the development of "pod" 'as follows:

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

What is what:

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

Create a "pod" project

So, let's begin. Just in case the example project lies on GitHub .
Create your repository on GitHub with the name, for example, 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.
Create a local git repository, bind it to GitHub, create and commit a file where the project licensing scheme will be described and send the changes to GutHub. Create a directory Classes which will contain the source code of the pod itself. Subdirectories of the same Classes / ios and Classes / osx will not be created, because We are focusing 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 recorded in the file NAME.podspec .
The .podspec file is created by the developer “pod” 'a and is placed in a special repository “spec”' s. There is a main repository where all the pods available by default “live” like, for example, the well-known AFNetworking . Your useful “pod” may also appear there. It is also possible to create and use your personal “specs” repository, access to which is regulated by you personally.
But back to the beginning. To create your own .podspec , enter the following command in the terminal:

 $ pod spec create MyLibrary 

As a result, in the current directory we get the “spec” template as a file MyLibrary.podspec , which describes in detail what each parameter is for. A more detailed description of the file format is provided on the project’s 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 canons.
First, let's set the 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 run through the lines that require an accurate understanding of what is happening:

• version - the current version of our "pod" '
• license - in a world where coprasty has been operating for half a year, it is highly desirable to indicate the type of license of your creativity
• author - as well as the author of this work
• platform - here we indicate that our “pod” is created only for the iOS platform of minimum version 7.0 , alternatively, the deployment_target parameter can be used:

    s.ios.deployment_target = '7.0' 

• source - we indicate the place where our “pod” project 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 the corresponding tag, where the tag name is the same as the version number (a little lower it will be clear what )
• source_files - we list the source files of our “pod” 'a, relative to the project root directory
• public_header_files - header files “pod” 'a, which should be accessible using our “pod” application
• framework - here the framework is specified, which will automatically be connected to the “Pods” project when you install your “pod” 'a
• requires_arc - we report that ARC is used

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

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

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

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

Lint "spec"

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

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

Ideally, something like this should appear:

 $ 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 quite clearly commented and the correction does not cause problems.

Next we commit our git changes:

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

In order for the full link to successfully 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 a tag with the current version number and publish our “pod” in GitHub:

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

Lintuy:

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

If everything is correct, we observe a similar picture:

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

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

Scheduled:
Part 2. We divide our "pod" into modules. Use someone else's "pod" to develop your own.
Part 3. Publishing your "pod" 'a. Shared repository and personal.