Situation during iOS SDK development

iOS SDK development is to provide an implemented, encapsulated, and directly usable module for a certain application scenario, field, or requirement.

It mainly consists of two parts: a list of header files used to declare types or constants, and a binary file for specific implementation.

Therefore, the main problems in SDK development focus on:

1. Whether the header file can be indexed by the used project

2. Whether the binary file can be indexed The used project was searched

This article does not write the specific steps of making the SDK, but only discusses some situations when making the SDK.

About header file settings in SDK development:

For all classes, structures, enumerations, constants, etc. provided to the outside world, the header files that define them must be in the Build of the project. Phases->Headers->public below. And these header files need to be included in the header file with the same name as the SDK project (this is not necessary, but it will be more standardized. When others use the SDK, they only need to introduce the header file with the same name as the SDK)

Set whether the library file is generated dynamically or statically:

Project Name-gt; Target Name-gt; Build Settings-gt; search for "Mach"-gt in the search box; modify "Mach-O Type" is dynamic or static, then dynamic or static library files can be generated accordingly.

First explain the project names that appear in the following pictures:

SDKDemo: the SDK library file produced and provided to the outside world (the same name as the SDK project name)

SDKApp: An App project that references the SDK library file (this article refers to SDKDemo)

SDKStatic: When creating a new project, select iOS-gt; Framework & Library-gt; Cocoa Touch Static Library. Used to generate. a file project

SDKFramework: ? It is a Framework library file (may be dynamic or static), used to simulate .framework files that are dependent on the SDK

The following points Here are several situations to discuss the considerations for SDK development:

1. Generate dynamic SDK library files.

When creating a project, a dynamic library is generated by compiling according to the default configuration.

When introducing a dynamic library into the App project, you need to add the imported dynamic library under

App project: Project Name-gt; Target Name-gt; General-gt; Embedded Binaries .

Otherwise, the following type of error will be reported during runtime:

After the embedded dynamic library is compiled, there will be an additional Frameworks directory in the generated App file (you can right-click the .App file to view the package content), which is all added under Embedded Binaries. Dynamic library

2. Package as static library

SDK project: Project Name-gt; Target Name-gt; Build Settings-gt; search for "Mach"-gt in the search box; Modify "Mach-O Type" to a static library

It is very simple to introduce a static library into an App project. Just introduce it directly. No additional configuration is required:

tips:

The command format when merging the real machine and simulator versions is:

lipo -create?Path of the simulator version?Path of the real machine version -output storage path of the merged version

1. When merging, the order of the two parameters of the simulator version and the real machine version received by lipo -create does not matter. The results of the merged version when viewing the architecture information through commands are completely consistent. The simulator architecture information is displayed at the front, and the real machine architecture information is at the back.

2. Whether the merged version replaces the target file in the real machine version of the Framework or the simulator version of the Framework, after the replaced Framework is introduced into the App project, it will be used on the real machine and the simulator. It can run on

First create the SDKStatic project and generate an .a file.

This project simply inherits UIButton and overrides the initWithFrame method. The title and background color are generated by default for each MyButton object:

The generated .a file is as follows, you can see that it contains the MyButton.o file:

Introduced in the SDK project. a file. Let’s look at the generated SDK library file in two situations:

1. The SDK library file is made into a dynamic library (see the beginning of the setting method)

The content of the .a file is integrated into In the SDK dynamic library file, when introducing it into the App project, you only need to introduce the SDK dynamic library

2. The SDK library file is made into a static library (see the beginning for the setting method)

Information in the package:

The content of the .a file is also integrated into the SDK static library file, which is easier to understand. When introducing it into the App project, you only need to introduce the SDK static library

To summarize:

When making the SDK library, if there are dependent .a files, the final generated SDK The library file will merge the contents of the .a file, regardless of whether the SDK library file is dynamic or static.

The following SDKFramework is a Framework library file (may be dynamic or static)

The content added by the SDKFramework project is the same as the SDKStatic project. It also customizes MyButton, and generates a title and background color by default (copy the file to the project):

The SDKDemo project customizes MyView, and the MyView object generated by default adds a MyButton button and background color:

1. If the .framework file is a dynamic library

a. The SDK is packaged as a static library, as follows:

The static SDK package and the dynamic SDKFramework.framework file are independent of each other. When introducing a static SDK package, you must also import SDKFramework.framework, otherwise it will not compile because the static package has symbols imported into the dynamic library.

b. The SDK is packaged as a dynamic library, as follows:

The two are independent of each other. The dynamic SDK package will record the dependent dynamic .framework rpath. When the App is running, dyld will load the corresponding .framework dependency file based on this information. If the App cannot be found, it will crash at startup...

2. If the .framework file is a static library

a. First, take a look at the SDK packaged as a dynamic library:

After practice, the dependent static libraries will be integrated into the dynamic SDK package itself. When introducing it into the App, you only need to import the SDK package. We import SDKDemo into SDKApp, and you can see the following effect when running:

b. Let’s look at the SDK packaged as a static library:

According to the information in the screenshot above, import the SDK package into the App , you must also import the dependent .framework. Otherwise, there will be an error that the symbol cannot be found as shown in the figure below during compilation:

Append the imported dependent .framework, compile and run again. OK! ! !

Summary:

1. The dependent .framework is a dynamic library

The SDK library file produced is either dynamic or static. and the dependent .framework file itself are independent of each other, and symbol integration will not occur

2. The dependent .framework is a static library

If the SDK library file produced is Dynamic, the dependent .framework static library content will be integrated into the SDK library file

If the SDK library file produced is static, they are independent of each other

Here again Discussion of several scoring situations:

1. Use_frameworks is not used in Podfile! ? The pods library generates .a files

a. If the SDK is made into a static library:

? The SDK static library will not integrate symbols from the third-party libraries in Pods. When finally imported into the App project, the SDK static library and the third-party library files in Pods need to be imported together

b. If the SDK is made into Dynamic library:

? The symbols in the Pods library will be merged and integrated into the SDK library. When importing the project, you only need to import the SDK package.

2. Use use_frameworks in Podfile ! ?The pods library generates .framework files. The Pods_projectname.framework file is a static library, and the managed third-party library generates a framework dynamic library

a. If the SDK is made into a dynamic library:

The SDK will include When introducing the rpath of the third-party library and the SDK package into the App, the third-party library must also be introduced, otherwise dyld cannot load the specified library and cause the App to crash when it starts

b. If the SDK is made into a static library:

Symbols defined in libraries in Pods will be ignored in the static SDK (that is, they are independent of each other). If the static SDK references symbols defined in the dynamic pods library, just import the dynamic library in the pods into the App project and add it to the embedded binaries. The same can be compiled and run.

In fact, it doesn’t matter how to compile or what the situation is in the SDK project. It is important to understand the nature of the library file and how it works? At what stage does it work? Then learn to check the error information during compilation and runtime, and use commands such as otool, nm, lipo, ar, file, etc. to check some information about the library file, and finally track and locate the problem.

Forgive me for not posting many pictures in the end, because the process is similar to the previous one. My hands are tired from writing too. If you still have any questions, you can comment below and I will try my best to reply as soon as possible.