Xcode Project Analysis

1. Background

Xcode is an IDE for daily iOS program development, supporting C, C++, Objective-C, Swift, Ruby and other languages. The entry point for daily development is Xcode workspace or Xcode project.

A workspace is an Xcode document that groups projects and other files. A workspace can contain any number of Xcode projects, as well as resource files (JSON, scripts, images, videos, etc.). In addition to organizing the files in each project, the workspace also provides implicit and explicit relationships between the included projects and their targets.

A project is an Xcode project, which actually manages the targets, source code, resource files, frameworks, etc. under the project. A project is just a container and cannot be compiled by itself, so each project should have at least one compilable target, which needs to contain compilable source code.

In daily development, it is inevitable to operate the dependencies in the workspace or project in a non-Xcode environment, so it is particularly important to understand the relationship between workspace, project, source code and resource files, because only when you know where it came from can you know how to do it.

2. Understand the overall picture of workspace

The relationship between workspace and project can be simply seen from the above figure:

• A workspace can contain multiple projects
• A project contains multiple targets
• Configuration refers to the Debug/Release and other project configurations in Xcode
• Scheme configures target compilation parameters
• Each target generates a corresponding product each time it is compiled: app or framework

3. Explore workspace

Create a new empty workspace and look at its hierarchy tree directly:

You can see that the workspace mainly consists of three levels:

• xcworkspacedata, the workspace configuration file, is actually an XML file.
• xcshareddata: Shared configuration, including scheme, script and other information.
• xcuserdata: The current configuration, including local scheme, script, breakpoint information, etc.

Take the quotation project as an example to view the contents of contents.xcworkspacedata in detail:

As the name suggests, FileRef marks the path relationship of each file in the workspace. This relationship determines the display level of the project in Xcode.

The location keywords include the following:

• self: the project with the same name in the current folder
• group: xcodeproj file in the specified directory
• Container: xcodeproj files with different names in the current directory of workspace
• absolute: Files under the absolute path

4. Explore projects

From the exploration of the workspace, we can see that the workspace is indeed just a workspace that organizes project and other files. It does not have the ability to compile and integrate source code and resources. Only by further exploring the project file can we see how the source code and resource files are integrated.

As can be seen from the above figure, xcodeproj contains three major levels. xcuserdata contains commonly used schemes and configuration files, and also contains an xcodeworkspace, which is to ensure the compatibility of Xcode and maintain the unity of Xcode's file management logic.

xcodeproj contains all the files needed for development, and manages all the source code, resource files, configuration files, etc. of the current project. The focus is on the pbxproj file, which is closely related to our normal code compilation. It manages the reference dependencies between targets and files, and the file conflicts generated when merging codes.

4.1 In-depth pbxproj

The full spelling of pbxproj is Project Builder Xcode Project. It is actually a kind of plist file we are familiar with, but it does not have the superior readability like the plist files we commonly use. It has been preserved by Xcode for historical reasons.

pbxproj defines the reference relationships between target, script, files, configuration, etc. The Xcode project layout we see is actually a visualization of pbxproj.

Let’s take a look at the internal layout of pbxproj:

As you can see, the outermost layer contains these properties:

• archiveVersion Current file version
• Classes Placeholder
• objectVersion The minimum version of Xcode required by the current file
• objects A dictionary with each object's uuid as key, storing object attributes
• rootObject The root object of the current file (isa = PBXProject)

What is actually stored in objects is the dependency relationship between each file. We call each file an Xcode object. This Xcode object can not only be a source code file, but also a group, framework, app, target, scheme, etc.

From the rootObject = D9658FA7290BA51D00A72187 in the figure above, let's take a quick look at its internal structure as an Xcode object:

It can be seen that the more important information is isa, mainGroup, configration, and target. The other information also includes all the information we have seen and can be configured in Xcode.

This is just the information in PBXProject, all information can be found on the official website. All types of configuration are listed below:

• PBXProject: Project configuration, information required to compile the project
• PBXNativeTarget: Target configuration
• PBXTargetDependency: Target dependency configuration
• PBXContainerItemProxy: Deployed Elements
• XCConfigurationList: Configuration configuration in Xcode
• XCBuildConfiguration: Xcode Build Settings configuration
• PBXVariantGroup: storyboard file configuration
• PBXBuildFile: various file configurations
• PBXFileReference: various file reference configurations
• PBXGroup: Group in Xcode
• PBXSourcesBuildPhase: compile source files that need to be compiled
• PBXFrameworksBuildPhase: framework that needs to be compiled
• PBXResourcesBuildPhase: resource files other than source code

The relationship between them is roughly as follows:

Understanding the relationship between various files can lay the foundation for us to dynamically add, delete, move files, modify build settings, schemes, and other operations through scripts in the future.

5. Explore the scheme

Scheme is not a necessary condition for compiling the target. The absence of scheme does not affect Xcode's compilation operation. However, without scheme, we cannot pass parameter conditions, insert compilation scripts, and configure personalized compilation configurations during compilation, so scheme is a necessary option for Xcode compilation.

Opening a scheme source file, we can see the following layout:

As you can see, the outermost layer contains build, test, launch, profile, analyze, and archive, which correspond exactly to the corresponding commands in Xcode, which once again verifies that Xcode is the visual presentation of pbxproj.

Enter BuildAction to see the pre-compiled scripts and various environment variable configurations we added in Xcode. Some of these configurations are essential parameters in the compilation process, and some are necessary configurations for our convenience in managing compilation products. Flexible use of these configurations can allow Xcode to better serve us.

6. Find the target

Target is used to specify the product to be built, i.e. framework or app. Target only contains some of the specified code and resource files in the current project. Each target can only build a specific build product. In order to enrich the build products, a project can have multiple targets.

The target uses Build Settings and Build Phases to perform personalized configuration. By default, these configurations can be inherited by the project, and other configurations can also be overwritten manually or through configuration files.

Targets can depend on each other. If they are in the same workspace, Xcode will trigger implicit dependencies by default. Of course, if you configure dependencies manually, they will become explicit dependencies. Explicit dependencies have higher priority than implicit dependencies.

7. Summary and Outlook

According to the above introduction, everyone must have a certain understanding of Xcode project configuration. After understanding these, what can we do? In fact, there are many ways to play:

• According to different compilation schemes and compilation instructions, the compilation products are extracted and distributed to different personnel.
• Depending on the target, different environment test packages are set for each compilation without changing the source code.
• If any warning information is detected during the compilation process, it should be reported to the developer in a timely manner.
• Find invalid code and files during compilation.
• Use the dynamic configuration of cocoapods to directly introduce binary components during installation to increase compilation speed.
• Output the compilation log of the specified framework to a file for easy comparison and review.

After understanding these basic configurations, you will have more means to solve repetitive or difficult problems in the engineering of projects in the future, and there will be more new ways of playing that can be discovered in the work process.

About the author: Wang Yifei

• Dealer Business Department, Dealer Technology Department
• Joined Autohome in 2014 and currently works in the Dealer Business Unit - Dealer Technology Department, responsible for the research and development of the car quotation app and M site business.