Prevent Xcode rebuild from changing configuration - ios

Question

Our project are using different build configurations to separate server environments
(e.g: Production, Staging)
#if STAGE
public struct endpoint {
public static let api = URL(string: "https://stage.???.com/api")!
}
#else
public struct endpoint {
public static let api = URL(string: "https://prod.???.com/api")!
}
#endif
}
Chances are sometimes we need to switch between different configs to debug repeatedly,
however, Xcode will rebuild almost all files when switching configurations, even if we didn't change files.
Is it possible to optimize Xcode to prevent building almost every files when we change configurations, to let it build just like an incremental build?
Below is part of our configs in build settings
Environment:
Xcode 11
Swift & Objective-C mixed project
Cocoapods to install 3rd party libraries

Answer 1

Perhaps there is a different strategy you can use to avoid rebuilding.
I have a game which I wrote which is a server based game. I have a version of the server that runs on MacOS for easier debugging and is built with Xcode, and the game is an iOS game. Both client and server support building different environments, however I do not control them using the Build Configuration per se. Instead I use targets as the main way of controlling access to environments.
I use the following approaches:
Command line arguments to "control" environment
Using Config files to "control" environment
Using Build Target to "control" environment
All 3 are used in the case of the server (since it is a command line executable), and the last two are used in the case of the game.
The trick here is that my code allows for the dynamic switching of environments (and this is really the key element to this approach).
I use the Build Target to control the extent of switching allowed. For example, my Dev target allows switching between Dev, QA, Stage, and Prod. My QA target allows switching between QA, Stage, and Prod, and my AppStore target only supports Prod.
Of course, backing the targets are build configurations. For build configurations I use Debug, DevDebug, Release, DevRelease, and AppStore. So plain Debug configuration and Release configuration are used by the "QA Target". And DevDebug configuration and DevRelease configuration are used with the "Dev target". I use 3 targets in all.
When the app starts, if it can take a command line and an env is defined, it uses it (if it can). The next fallback is a config file (You can easily edit this if you are on the simulator or running a MacOS app). Then what's baked in.
This also implies I have an environment chooser. I have found that also allowing a chooser to be selected from network error popups is also handy (in case you are in the wrong env). Choosers are only available on non-AppStore builds.