Since I received an “official” response from Apple Engineers on the subject, I wanted to share the findings on this and the answer to my questions:
First of all, there is no actual replacement for ENABLE_PREVIEWS with Xcode 16 and the new build system.
The change has been made deliberately, and the following quote explains why:
New in Xcode 16, Previews now shares build products with normal debug builds. There's no difference anymore. This effort drastically reduces preview time since there’s no need to completely rebuild the entire project. This also resolves bugs when previewing in large package graphs and positions us to maintain fidelity with the normal build-and-run behavior. All debug builds are now “enabled for previews” because there's no distinction.
One can also observe that the build behavior of SwiftUI previews has changed with Xcode 16. For example, a build for a SwiftUI preview may no longer be triggered if the artifacts of a previous debug build are already available and no code has changed for the preview.
With regard to the new SwiftUI build system, this means:
1. Conditionally compiled code for SwiftUI previews is no longer possible
As already described in the question, special code could previously exist in a project (e.g. mocks / extensions etc.), which was compiled exclusively for SwiftUI Previews and was not available in other builds.
This code could therefore not be used “by mistake” in productive parts of the project.
The only thing that is still possible in this respect is to rely on the dead code stripping feature, which removes unused code from builds. Of course, this feature does not prevent a developer from using code that may only be used for previews and should not end up in the production app.
2. Prevention of code execution in SwiftUI previews at runtime
Since SwiftUI Previews are known to start the app in the background with every view / refresh, code is also executed that you may not want to execute. This can include, for example, network calls in the AppDelegate.
Information about the developer systems that should not be disclosed may be leaked this way.
ENABLE_PREVIEWS made it possible to use a compilation conditional in a simple way to prevent such executions in previews.
Fortunately, at this point there is a possibility at runtime to identify the execution for previews via an environment variable:
ProcessInfo.processInfo.environment["XCODE_RUNNING_FOR_PREVIEWS"]
Therefore, without ENABLE_PREVIEWS there is a way that certain code for previews is not executed.
3. Build scripts and SwiftUI preview builds
In many large iOS projects, various build scripts are often used that should only be executed for certain build variants for various reasons.
In general, such scripts may slow down the build process considerably.
(e.g. formatter and linter scripts)
ENABLE_PREVIEWS was a very useful tool in the past to significantly speed up and optimize the build process for SwiftUI previews, as these could sometimes become extremely slow in large projects.
There is no direct replacement here either. It might be possible to use the default "Debug" build configuration (which Apple says is used by SwiftUI previews) exclusively for SwiftUI previews and use or create a separate debug build configuration with a different name for regular debug builds.
However, I have not yet tried this in practice.
