Xcode creates multiple taget for a project to facilitate testing and release multiple versions.

Background: in many cases, we need to create multiple targets in one project. That is to say, we want to create two applications with the same code, which can be placed on a simulator or on a real machine, or, we usually have more than N developers. During the test, we installed the one written by test a here. When we need to test the code written by Test B, we need to install it in B. If there is only one target, a will be overwritten.

Sometimes, we need to determine whether it is a problem or B's Code. At this time, we need to build a project to compile multiple versions, the following describes how to compile multiple versions in a project, but there is little gossip. The following is the official start: we will create a default application to demonstrate the practice: the created application is as follows: we can see that there is only one target above: testtarget. To facilitate the demonstration, we add a multi-language to it so that its name on the simulator is Chinese. We have infoplist in the project. add the following statement to strings: cfbundledisplayname = "test official version". In this way, after the simulator is installed, the result is displayed. The previous task can be completed. add a new target, because here we create a target that is basically the same as the original one, so we can choose to copy it to create a new target. When you choose to copy it, there will be two more files, in the following example, a scheme 2 related to the target will be added to scheme. the name above is too ugly. Let's change the name., You will find that re-selecting the info plist file TestTarget2-info.plist file with our modified name (the file name should preferably contain info. plist. This is an agreement to facilitate searching for this file later.) We need to change the scheme and the name of the generated product to the build settings of testtargettest2, search for the product name and change the product name to the name we need. (Note that this name is only the name of the generated app, not necessarily the last name displayed, the last displayed name depends on whether the user is in infoplist. cfbundledisplayname = "Test 1";) 3. switch to the scheme testtarget2 and run it. In the simulator, you will find that there are two test 1 in the simulator. Some students do not generate two icons here. This should be the bun of the two targets. Dle identifier is set to the same. If the same, the generated target will overwrite the previous 4. the above two targets have been generated and run successfully on the simulator. The problem arises. How do we know which target is? The two names are the same. Don't worry, this problem is well solved due to the sharing of an infoplist. stirngs file. Therefore, two targets are displayed as test 1 on the simulator. If you know the problem, we will solve it. Obviously, we should create another infoplist for testtargettest2. stirngs, because we only need to display different names and do not need to change anything else, we can directly copy the infoplist of all languages under the project directory. copy the strings file to create a new folder. all strings must be copied, because there are multiple languages, and the language folder must also exist.) because we have only one language We only have one en in targettest2. in the lproj folder, set infoplist in the targettest2 folder. after adding the newly added file to the project in strings, add the original infoplist. remove targettest2 from target of stirngs. For example, remove INFOP under targettest2. modify the content in stirngs to test 2 5. select the scheme testtarget and run it. Test 1 is displayed on the simulator. Change Scheme to testtarget2 and run it, test 2 is generated on the simulator. Switch scheme. Everything is correct. 6 is displayed on the simulator. as an appendix, it is also important that many of our targets share code, resources, and so on. Sometimes we need to identify which target is in the Code, for example, the second target we generate is a restricted version. We need to prompt users (for example, a free version with limited functions). How can we differentiate it in code? There are three methods: the first method, using cfbundleidentifier to determine

1. Nsstring * bundleidentifier = [[nsbundlemainbundle] infodictionary] objectforkey: @ "cfbundleidentifier"]; // do any additional setup after loading the view, typically from a nib.
   If ([bundleidentifierisinclutostring: @ "yohunl. testtarget2"]) {
   // Process the code
   Nslog (@ "TestTarget2-Info.plist ");
   }
   Else {
   // Process the code
   Nslog (@ "TestTarget-Info.plist ");
   }
   The second method is to define a compiler macro for differentiation. When testtarget2 is enabled,
   
   

Note that the above-D is required. Generally, we can use uppercase letters for such definition Macros in the code.

# Ifdef TARGET2
// Processing code of TARGET2
Nslog (@ "TARGET2 ");
# Else
Nslog (@ "target1 ");
# Endif

The third method does not need to add-D to the pre-compiled macro in the code.

# Ifdef testtarget2
// Processing code of TARGET2
Nslog (@ "testtarget2 ");
# Else

Nslog (@ "target1 ");

# Endif the above three methods can be Appendix 2: Reference http://finbarrbrady.com/2010/03/building-for-multiple-targets-in-xcode/ English http://www.reigndesign.com/blog/building-flockwork-creating-targets-for-free-and-full-versions-in-a-single-xcode-project/ English http://www.omegasoftweb.com/omega/blog.cfm? English http://blog.csdn.net/ysysbaobei/article/details/10951991 Chinese

I believe many people have noticed the concept of target in xcode. this is reflected in many places. For example, after opening a project, there is a targets item in the list on the left, and in the top menu of the Project interface, there are also multiple projects that involve the target, so what is the target?

Apple said: "targets that define the products to build. A target organizes the files and instructions needed to build a product into a sequence of build actions that can be taken."

In a simple understanding, we can think that a target corresponds to a new product (based on the same Code). But all of them have a piece of code. What should we do with a new product? Is this interesting?

In fact, this is not just a waste. Although the Code is the same, compilation settings (such as compilation conditions) and the resource files contained can be very different. therefore, even if the same code is generated, the product may be very different.

Let's take a few typical applications with multiple targets, such as the full version and Lite version; for example, the 20-off, 30-off, and 50-off versions of the same game; or, for example, changing resources and names for the same game can be sold as new games (feed, what are you teaching ...).

 

The above copy.

 

We will not discuss how to make such a project, but choose whether to do it or not.

 

When working on the topic recently, we maintain two different versions of code, which are equivalent to two projects in the full version and Lite version.

 

Now our processing is put in two different directories. The previous two projects are composed of different frameworks. After the upgrade, many basic functions are the same, however, it is maintained in two different places. I was thinking about why the same code should be put under two directories. At that time, I found that the bug was fixed in only one place, but it still didn't exist here. The same function is implemented, but two different codes and frameworks are used.

 

In my ideal situation, we only have one project. This project should be a complete project, which contains multiple targets. compile it once or output the target of different versions separately.

 

However, during this upgrade, I joined the iPhone and iPad code, but then I hesitated when I tested it myself. The version was made. iphone4.0 was running well. It went to iPad, collapsed, and went to iPhone. So there are a lot of repeated codes in the code.

If (isipad)

Xxx

Else

Xxx

 

I began to hesitate. Now we only put the iPhone and iPad together. If we put two different versions of the target together, it may be even worse. Compiled in 3.0. The iPhone 3, iPhone 4, and iPhone 4.0 for iPad testing are also compiled. Every change should be tested. How careful should we maintain it, like performing thin ice. And the code is getting corrupted.

 

In the face of complicated and frequently changing boring and small demands, putting eggs in a basket may not be a good choice. On the contrary, I think it may be the right option to not bring these two projects together.

 

I prefer to merge them for maintenance. Because every time there is a small adaptation, if you forget to modify both places, there will be one hidden bug after another, and it should eventually be full of holes.

 

I have heard that s60 software is compatible with one version for several devices. That is to say, it is a nightmare for me to maintain the same lot of sub-code.

 

However, this is the case for software. The sum of the points must be clearly defined.