Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Published : Apr 13, 2021
Not on the current edition
This blip is not on the current edition of the Radar. If it was on one of the last few editions it is likely that it is still relevant. If the blip is older it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don't have the bandwidth to continuously review blips from previous editions of the Radar Understand more
Apr 2021
Trial ? Worth pursuing. It is important to understand how to build up this capability. Enterprises should try this technology on a project that can handle the risk.

Many of our developers coding iOS in Xcode often get headaches because the Xcodeproj file changes with every project change. The Xcodeproj file format is not human-readable, hence trying to handle merge conflicts is quite complicated and can lead to productivity loss and risk of messing up the entire project — if anything goes wrong with the file, Xcode won't work properly and developers will very likely be blocked. Instead of trying to merge and fix the file manually or version it, we recommend you use a tool-managed Xcodeproj approach: Define your Xcode project configuration in YAML (XcodeGen, Struct), Ruby (Xcake) or Swift (Tuist). These tools generate the Xcodeproj file based on a configuration file and the project structure. As a result, merge conflicts in the Xcodeproj file will be a thing of the past, and when they do happen in the configuration file, they're much easier to handle.

Radar

Download Technology Radar Volume 25

English | Español | Português | 中文

Radar

Stay informed about technology

 

Subscribe now

Visit our archive to read previous volumes