Xcode 4.0.1 allows us to more easily create and use third party libraries in iOS projects. I think the process is still more complicated than it needs to be. Xcode’s documentation suggests that it should automatically detect implicit dependencies and index classes across workspaces but I have not found this to be the case. Here I’ll cover the steps I have found for creating and sharing code between projects and with other developers.

1. Background
2. Using a Static Library
3. Creating a Static Library
4. Future Improvements

Background

Workspaces:

Xcode 4 introduced the concept of workspaces as containers for multiple projects. There are a couple of key behaviors of workspaces which we want to build on when choosing how to share code across projects.

• By default, all the Xcode projects in a workspace are built in the same directory, referred to as the workspace build directory.
• Xcode examines the files in the build directory to discover implicit dependencies.
• Each project in a workspace continues to have its own independent identity.

Schemes:

Within a workspace or within a project which is a member of a workspace we have schemes. Schemes replace the Active Target, Build Configuration, and Executable settings from Xcode 3 and define which targets to build, the order in which to build them, and what action to take when a build is complete. We’ll want our shared code to easily fit into the scheme of any projects which use it. The Xcode 4 Transition Guide covers this new structure in more detail.

Targets:

Within a scheme we have one or more build targets which define a set of source files to build, the settings used to build those files, and any dependencies on the build products of other targets which must be completed first. Ultimately we would like a consumer of our code to be able to state that their project’s build target depends on our shared code and have Xcode build this shared code and make it available to the active build target. We can achieve that by providing a project containing the code to be shared and a static library build target which packages it into a build product other developers can add as a build target dependency.

Using a static library

1. Creating a workspace
2. Adding projects to a workspace
3. Adding build target dependencies
4. Adding the static library’s headers
5. Configuring the project’s scheme
6. Fixing indexing

Creating a workspace

We can create a new empty workspace from Xcode’s file menu or open an existing project and select “Save As Workspace…” to create a new workspace containing our project. This will create a “.xcworkspace” package in the file system.

An empty Xcode 4 workspace

Adding projects to a workspace

Once we have a workspace we can right-click in the workspace’s navigator to create a new project or add an existing “.xcodeproj” package.

Adding a new project to a workspace

Adding an existing project to a workspace

We want to end up with a single workspace containing our app’s project and the projects for any static libraries we are going to depend on. It is worth noting that these projects are all siblings in the workspace, our static libraries are not added as references within our app’s project.

Adding build target dependencies

With all of the projects we need available in our workspace we can select our app’s build target and add a static library to the “Link Binary With Libraries” build phase.

Libraries and frameworks available to add to the "Link Binary With Libraries" build phase

A static library added to the "Link Binary With Libraries" build phase

Adding the static library’s headers

We also need to make sure that our app’s build target can locate the public headers used in this static library. Open the “Build Settings” tab and locate the “User Header Search Paths” setting. Set this to “$(BUILT_PRODUCTS_DIR)” (or “$(BUILT_PRODUCTS_DIR)/static_library_name” if we want to be more specific but then we’ll have to update this setting every time we add another library) and check the “Recursive” check box. Now our built target will search our workspace’s shared build directory to locate linkable header files.

Setting the User Header Search Paths

User Header Search Paths set

The “User Header Search Paths” setting defines the headers available as quoted imports (eg “#import “MyLibraryClass.h”) while the “Header Search Paths” setting defines those headers available as bracketed imports (eg “#import ). I’ve found that Xcode will only autocomplete header names in the quoted form so I always add libraries to the user header search path even though, from my project’s perspective, they might be more appropriate as system level (angle bracketed) libraries.

When using a static library which includes categories we will also have to add the “-ObjC” flag to the “Other Linker Flags” build setting. This will force the linker to load all objective-c classes and categories from the library. If the library contains only categories “-all_load” or “-force_load” may be needed as well. See Technical Q&A QA1490 for a more detailed explanation of these settings.

Configuring the project’s scheme

At this point Xcode should have detected this implicit dependency between our app’s project and the static library’s project and have automatically configured our schemes correctly. Unfortunately I haven’t found this to be the case in practice. Instead we will have to edit our current scheme and add the static library’s build target before our app’s build target.

Setting the scheme's target build order

Fixing indexing

At this point we should be able to include headers from dependent static libraries, use the included classes, and still successfully build our app. Unfortunately Xcode will not show any classes from these linked static libraries in code completion despite the workspace documentation stating that “indexing is done across the entire workspace, extending the scope of content-aware features such as code completion and refactoring.”
As a workaround we can drag the public headers from the static library’s project into our app’s project, adding them as references. These headers do not need to be included in any of our build targets, simply having references to the headers in our project will allow their classes to appear in code completion.

Creating a Static Library

If we plan on releasing some of our own code for reuse as a static library there are several things we should do to make sure that the process described above is as easy and simple as possible for our library’s users.

1. Namespace classes appropriately
2. Create a build target
3. Expose public headers
4. Set the installation directory
5. Set the public header path
6. Exclude user specific files from VCS

Namespace classes appropriately

Use an appropriate prefix for classes, protocols, functions, and constants in the library to prevent collisions with names in the library’s user’s project.

Create a build target

Provide a static library build target in the project for our users to link against. Xcode provides templates for creating projects with static libraries or adding static library build targets to existing projects.

Expose public headers

Determine which header files should be visible to users of the library. Provide a clearly named group containing these headers so that our library’s users can easily locate them as part of the workaround described in “Fixing Indexing” above. This also helps us clarify what the public interface our library provides is and what classes are implementation details which are likely to change as the library evolves.

For each public header file make sure it is set as “public” in the “Target Membership” section of the inspector pane. Only public headers are going to be available for our users to import.

Making a header file public

Set installation directory

Our static library build target is going to be a member of a user’s workspace and subject to that workspace’s installation rules. Our static library build product could therefore be installed in a location set by Xcode’s preferences, in the derived data path, or in a path specified by our build target. Since we can’t control the user’s settings we should make sure our library is well behaved in all cases. I set the “Installation Directory” build setting to “$(BUILT_PRODUCTS_DIR)” so that the static library build product can be found in a known location and set the “Skip Install” build setting to “Yes” to avoid accidentally installing iOS libraries into “/usr/local/lib”.

Setting the installation directory

Set the public header path

We need to specify a location to copy our static library’s public headers to so that they can be included in our users’ header search paths. Setting the “Public Headers Folder Path” to “$(TARGET_NAME)” will create a folder named after our static library build target in the workspace’s shared build directory and be indexed by the “User Header Search Paths” setting described above.

Setting the public headers path for the static library

Exclude user specific files from VCS

Our workspace and project include a number of files which contain data relevant only to our user account; window positions, open files, and so on. There’s no need to check these into source control, at least not in our release branch, so let’s set some reasonable ignore rules in git or whatever VCS we are using. Github provides a convenient set of .gitignore files

Future Improvements

Problem: What’s the best way to share code across iPhone projects?

If you want to reuse/share code across different iPhone applications, you only have two options (that I’m aware of):

1. Copy all of the source code from the “shared” library into your own project
2. Keep the shared library code in a separate Xcode project and use it to build static libraries (e.g., libSomeLibrary.a, also referred to as “archive files”) that can be referenced by your project and used via static linking.

The first option, copying the files, should be avoided when possible since it’s inherently redundant and contrary to the goal of keeping “common code” modular and atomic. It’s a much better idea to put the code in a static library since, as mentioned in the introduction, dynamic linking to custom libraries/frameworks isn’t allowed by Apple when it comes to iPhone apps. If you’re not sure how to put your code in a static library, I’d suggest taking a look at this tutorial on the Stormy Productions blog.

当拷贝文件本身就是冗余的，且和保持“通用代码“模块化和原子化的目标相悖，第一种方案就应该避免采用。

So we’ve established that the second option is preferable, but there’s a catch: you’ll need to build and distribute multiple versions of the static library–one for each runtime environment and build configuration. For example, you would need to build both “release” and “debug” versions of the library for the Simulator, as well as other pairs for the iPhone or iPod device itself. How can we avoid manually pre-building and managing separate .a files?

Solution: Static libraries that are built on-demand via Xcode cross-project references

The trick to avoid pre-building static libraries for each environment is to use an Xcode “cross-project reference” so that those libraries are built dynamically (i.e., when you build your own app) using your app’s current build configuration. This allows you to both reuse shared source code and avoid the headache of managing multiple versions of the library. Here’s how it works at a high level:

在build app的时候动态生成静态库。

1. The shared code lives in its own Xcode project that, when built, results in one or more static libraries.
2. You create an Xcode environment variable with a path to the directory that contains the static library’s *.xcodeproj file.
3. All iPhone apps that need the static library will use the aforementioned environment variable to reference the library’s Xcode project, including any static library in that project and the related header files.
4. Each time you build your project for a specific configuration/runtime environment, the shared project library will also be built for that config/environment–if it hasn’t already–and linked with your executable.

In addition to solving the main problem (reusing code and avoiding management of multiple library versions), there are a couple of nice benefits to this strategy. First, if you make changes to the shared library source code, those changes will immediately be included the next time you build your own project (via the cross-project reference). Second, you can modify the Xcode environment variable to point to different versions of any project. For example, you might have separate directories for “somelibrary-1.0″ and “somelibrary-2.0″; as you’ll see in the detailed solution instructions, it’s easy to modify the environment variable and switch your project to a different version of “somelibrary.”

Other Solutions

zerg-xcode

Victor Costan has developed a slick command-line tool called “zerg-xcode” which helps you copy the source code from one Xcode project (i.e., a static library project) into another Xcode project. In addition to physically copying the files, it inserts the targets from the “library” project into your “app” project. If the library project changes, you simply run zerg-xcode again with the approriate commands to sync the files and targets. Some people may find this tool very useful; my personal preference, however, is to avoid making any copies of the source code files and stick to Xcode’s built-in “cross-project reference” mechanism.

“Fat” Universal Binary

Another approach is to “bundle” two versions of a static library into a single file, referred to as a “fat” universal binary (see this post on the Latenitesoft blog for an example). More specifically, one version of the library would be for the i386 architecture (i.e., the Simulator) and the second for the ARM architecture (i.e., the phone). This may be a perfectly fine solution for you if you really only need two versions, or if the source code for the library is kept private. That said, you’re still left with the task of maintaining pre-built versions of the libraries (plus the extra work of bundling them into the single file). In addition, I’m not sure that you can bundle more than two versions of the library into the binary (e.g., iPhone “release” and Simulator “release”, but not iPhone “debug” and Simulator “debug”).

1. 下载.cer文件到别的机器。就是在IDP上的那个。
2. 从发送申请文件（certificate Request，后缀名为certSigningRequest）的机器上把证书对应的private key（.p12文件）导出，密码自己定，要记住，后面导入的时候要用。
3. 在你需要的机器上安装证书（.cer），导入私钥文件(.p12)。安装对应App的provisioning profile。
4. Over，你可以用其他机器开发了。

注：必须得从申请机器上导出private key.到其他机器上

一、成员介绍
1.    Certification(证书)
证书是对电脑开发资格的认证，每个开发者帐号有一套，分为两种：
1)    Developer Certification(开发证书)
安装在电脑上提供权限：开发人员通过设备进行真机测试。
可以生成副本供多台电脑安装；
2)      Distribution Certification(发布证书)
安装在电脑上提供发布iOS程序的权限：开发人员可以制做测试版和发布版的程序。
不可生成副本，仅有配置该证书的电脑才可使用；（副本制做介绍在下面Keychain中介绍）

2.    Provisioning Profile(授权文件)
授权文件是对设备如iPod Touch、iPad、iPhone的授权，文件内记录的是设备的UDID和程序的App Id，即使被授权的设备可以安装或调试Bundle identifier与授权文件中记录的App Id对应的程序。
开发者帐号在创建授权文件时候会选择App Id，（开发者帐号下App Id中添加，单选）和UDID（开发者帐号下Devices中添加最多100个，多选）。
授权文件分为两种，对应相应的证书使用：
1)    Developer Provisioning Profile(开发授权文件)
在装有开发证书或副本的电脑上使用，开发人员选择该授权文件通过电脑将程序安装到授权文件记录的设备中，即可进行真机测试。
注意：确保电脑有权限真机调试，即安装了开发证书或副本；在开发工具中程序的Bundle identifier和选中使用的授权文件的App Id要一致；连接调试的设备的UDID在选中的授权文件中有记录。
2)    Distribution Provisioning Profile(发布授权文件)
在装有发布证书的电脑上（即配置证书的电脑，只有一台）制做测试版和发布版的程序。
发布版就是发布到App Store上的程序文件，开发者帐号创建授权文件时选择store选项，选择App Id，无需选择UDID；
测试版就是在发布之前交给测试人员可同步到设备上的程序文件，开发者帐号创建授权文件时选择AdHoc，选择App Id和UDID；只有选中的UDID对应的设备才可能安装上通过该授权文件制做的程序。
3.    Keychain(开发密钥)
安 装证书成功的情况下证书下都会生成Keychain，上面提到的证书副本就是通过配置证书的电脑导出Keychain（就是.p12文件）安装到其他机子 上，让其他机子得到证书对应的权限。Developer Certification就可以制做副本Keychain分发到其他电脑上安装，使其可以进行真机测试。
注意：Distribution Certification只有配置证书的电脑才可使用，因此即使导出导出Keychain安装到其他电脑上，其他电脑也不可能具有证书的权限。