Hi Sven Korset.

Summary

The web content discusses the pitfalls of duplicating targets for the same product in different environments within an Xcode project, advocating for the use of configurations to manage environment-specific settings efficiently.

Abstract

The article expresses gratitude to Sven Korset for compiling good practices but critiques the approach of having multiple targets for a single product, emphasizing that it leads to maintainability issues, increased potential for errors, and performance degradation in Xcode. The author argues that a cluttered project with duplicated build files complicates maintenance and escalates the risk of building the wrong target with missing sources. A lengthy .pbxproj file exacerbates these issues by slowing down Xcode and making team collaboration, especially conflict resolution, more challenging. The recommended solution involves leveraging configurations to handle different environments, such as development and production, by utilizing distinct Info.plist files, conditional resource copying via build phase scripts, and selective source file exclusion using EXCLUDED_SOURCE_FILE_NAMES. The author suggests that while duplicating targets may be necessary for cross-platform products, it should be avoided for environment-specific builds.

Opinions

The author believes that having multiple targets for the same product is a bad practice, citing it as worse than having 1000 files in one folder.
It is claimed that maintaining an Xcode project with duplicate build files is difficult and prone to errors, such as forgetting to add sources to all targets.
A lengthy .pbxproj file is seen as a detriment to Xcode's performance and team collaboration, particularly in resolving merge conflicts.
The author recommends using configurations and different Info.plist files to manage environment-specific settings like bundle IDs, asset catalogs, and app icons.
The use of build phase scripts to conditionally copy resources based on configuration is suggested as a best practice.
Select

Hi Sven Korset. Thank you for this article. I do appreciate that it puts all together a bunch of good practices. However I do want to voice my opinion on having multiple targets for the same product/target as I believe it is a bad practice.

There’s hardly anything worse than having 1000 files in one folder, ok. But it is clearly bad to duplicate a target for different environments.

Your Xcode project will be terrible to maintain if you have one or more duplicate of your build files in it. Not to say it will be an easy mistake to make to just add your sources to one target, and the day you build the other to realize it just doesn’t compile.
Your .pbxprojwill be very long.. it makes Xcode slow in many aspects.
Working in a team and having to solve merge conflicts is easier with a shorter .pbxproj. And if it’s never really short, you sadly just made it twice longer for no reason.

Configurations are there to help you out with your environments.

In order to change your bundle id, your asset catalog or just your app icon, you can just use different Info.plist files. In your example it would be Info-Dev.plist and Info-Prod.plist.

2. Then, if there is any resources that should not be copied in your production target, you can just copy through a build phase script when configuration != production.

3. Finally, if you have sources you want to exclude in one or another target. You need to decide which target is the default and compiles all sources. Then you set `EXCLUDED_SOURCE_FILE_NAMES` in your build settings only for the configuration that should exclude the sources. I believe this is case is not common so you shouldn’t have too many files to list, but if you did you could just specify a folder/*

Let me know what you think.

There is however one case where you may need to duplicate targets, and that is when you have thesame product for different platforms. Let say MyApp-iOS, MyApp-tvOS and MyApp-macOS or MyApp-watchOS.