Developers often face typical tasks that appear in new projects. The base of auxiliary code gradually accumulates, which is collected in libraries and transferred from project to project. And the more projects, the harder it becomes to support such libraries.

Most likely you have a favorite set of categories over NSFoundation / UIKit for convenience or something to work with the network or with push notifications. It would be logical to arrange this code in the library, store it in one place and connect it with the help of a package manager, for example cocoapods. Cocoapods greatly facilitate the integration of dependencies into a project. He does everything for you, creates the necessary targets and integrates their project. Such ease and simplicity leads to the fact that there are often pods, which consist only of source codes and an example of integration. This approach is recommended officially . And, in fact, this is enough for integration through cocoapods, but not enough for development and support. For this, an xcode project is best suited for building a library.

Xcode project

We will call our Utilities test library and create an Xcode project for it. The advantages of this approach are obvious:

• You can configure the necessary build parameters ( -Wall / -Weverything , iOS7 + / iOS8 +, etc.) and work on errors during debugging (and not during integration)
• you can add unit tests
• In addition to integration through cocoapods, there is the possibility of integration through Carthage, manually or by git submodules.

Static Library vs Framework

When creating a project, you need to choose what we will build: a library (static library) or a framework (dynamic framework). Their main difference is that the framework is not compatible with iOS7, and the library is not supported by swift.

In our case, iOS7 support is not needed, so the framework will do:

File structure

After creating the project, it is necessary to change the structure of the files in the project so that the library is compatible with package managers. The most commonly used package manager is, of course, Cocoapods. The rest are used less, but it is also easier to maintain them, since there is no need to upload updated podspec into the storage every time after the update.

Socoapods

To support cocoapods you need:

1. add podspec file
2. add LICENSE file

The team can help you with this.

 pod spec create 

In addition, if you do not want to make the library public, you need to create a private package repository . And add the podspec file to podspec :

 pod repo add myrepostorage https://github.com/user/podspecs pod repo push myrepostorage Utilities.podspec 

Example podspec file:

 Pod::Spec.new do |s| s.name = "Utilities" s.version = "0.0.1" s.summary = "My test library" s.homepage = "https://github.com/user/utilities" s.authors = "author name" s.license = "MIT" s.platform = :ios, "8.0" s.source = { :git => "https://github.com/user/utilities.git", :tag => "#{s.version}" } s.source_files = "Sources/**/*" end 

Swift Package Manager

To support Swift PM you need:

1. put the sources in the Sources folder
2. add Package.swift file

Package.swift example:

 import PackageDescription let package = Package( name: "Utilities" ) 

Carthage

To support carthage, you need to:

1. xcodeproj project xcodeproj was in the root folder
2. the schema in the project was marked as shared
   

In addition, it does not hurt:

1. add description in README.md for github
2. put unit tests in the Tests folder
3. put support files in the Supporting Files folder

The result should be the following structure:

The Supporting Files folder contains the Defaults.xcconfig file, which applies the compilation settings to the project. It is convenient to put it in all such libraries, so as not to tune everything by hand. We want to make strict settings so that the code is better, for example:

 CLANG_WARN_ENUM_CONVERSION = YES CLANG_WARN_INT_CONVERSION = YES CLANG_WARN_CONSTANT_CONVERSION = YES CLANG_WARN_BOOL_CONVERSION = YES; CLANG_WARN_ASSIGN_ENUM = YES CLANG_WARN_DEPRECATED_OBJC_IMPLEMENTATIONS = YES CLANG_WARN_IMPLICIT_SIGN_CONVERSION = YES CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF = YES CLANG_ANALYZER_SECURITY_INSECUREAPI_RAND = YES GCC_WARN_CHECK_SWITCH_STATEMENTS = YES GCC_WARN_64_TO_32_BIT_CONVERSION = YES GCC_WARN_ABOUT_MISSING_NEWLINE = YES GCC_WARN_SHADOW = YES GCC_WARN_SIGN_COMPARE = YES GCC_TREAT_WARNINGS_AS_ERRORS = YES WARNING_CFLAGS = -Weverything -Wno-objc-missing-property-synthesis -Wno-gnu -Wno-float-equal -Wno-nullable-to-nonnull-conversion -Wno-auto-import -Wno-direct-ivar-access 

Dependencies

If the library has a dependency, for example, on AFNetworking , then this dependency can be integrated as usual with usual methods. For example, using cocoapods or carthage, you can connect it to our library. You also need to remember to specify this dependency in the appropriate configuration files for package managers. For cocoapods, this is a Podfile , and for carhage, this is a Cartfile .

Total

The result is a library that is easy to maintain and integrate with any package manager.