I have been working in iOS project. Regarding Xcode Derived Data folder whose contents are generated by build system, there are many Stackoverflow posts, i.e. how to remove derived data folder or is it safe to remove derived data folder, etc. but there is none which I am looking for. My question is to know when should I delete the derived data folder and when should I not? In other word, in which conditions this derived data becomes non reusable and why? Are those derived data become stale after resource or configuration change of the project or anything else? I often see many issues are resolved after deleting derived data but we often do not try to know the root cause of the issues.
Can I simply say, until the .xcodeproj file change, the derived data can be reused safely?
Background of the question: In my project, I have a proof build system so that every CLs need to pass the proof build before getting merged to remote branch. So I need to know the risks to architect when I should (or should not) reuse the derived data folder to make the proof build system performant.
Sadly, deleting DerivedData has become the catch all to try and remedy build issues. As you already know, you can delete the DerivedData at any point in time with no issues (unless of course you were building). The nuances as to when it is safe is a little more complicated. In practice I have generally found that significant changes in the code between builds can have issues. Likewise, changing Xcode versions can also have issues. The key words here being can, which does not mean it will.
I do not believe there is any definitive means of knowing when to purge, which is why I think you find most people generally asking "did you remove DerivedData" as one of the first questions when someone has a build problem.
IMHO, I think there is some subtle caching that Xcode does within DerivedData, as I've had build failures in weird situations I could not trace. I would not be surprised if Xcode has some subtle bug related to this caching. In general, I only trusted a command line delete of the project's DerivedData. And if I was extra careful, I'd also purge any associated libraries/frameworks as well as the ModuleCache (in DerivedData). There is also some voodoo in the /var/folders. Not sure if this is still the case, but I have found myself surgically nuking stuff there. Yeah, bad. But I'm also the kind of person that has been known to edit the project.pbxproj file to fix it, so I guess I throw caution to the wind.
Let me ask you this question. What is more important? "bullet-proof" or build times? I've been roped into maintaining or upgrading the build systems for a few apps. I've always done everything as a clean build. This always was fresh pull from source control and then having a defined DerivedData within the workspace (these were Jenkins builds and was configured to use a clean workspace). This pretty much avoided build issues related to needing to remove DerivedData. I've seen way too many strange issues occur due to some Xcode voodoo. It is far better to not add red herrings if you have a build error.
If you do find that the builds as well as any tests needed are taking too long, you can start to devise other strategies to help make it more manageable. This becomes very project dependent. For example on a project I was working on, I moved all libs to pre-built versions. For some reason, they had it setup where they had to build all the 3rd party libs (like openssl) during the build process. This also means that the devs incurred this build penalty the first time they built or any time the cleaned.