Thank you for your quick response! [quote='799295022, Developer Tools Engineer, /thread/761439?answerId=799295022#799295022'] If you want to vary runtime behavior when previewing, you could check the value of [...] [/quote] Switching off certain behavior at runtime is indeed a critical case for us, as we absolutely must prevent certain things like network requests that are normally executed when the app is started. Otherwise internal data about our developers and their behavior during development could leak to other parties since those network requests will happen each time a developer opens a preview. However, this is not the primary case I wanted to refer to. [quote='799295022, Developer Tools Engineer, /thread/761439?answerId=799295022#799295022']If you have a unique situation [...], we would be interested in hearing more details about what you’re trying to do.[/quote] We have a relatively large amount of special code that is exclusively there to ensure that SwiftUI previews work correctly and that the views can be displayed in all relevant states. This includes the typical mocks of types and services used via dependency injection. Usually, it is undesirable for previews to trigger actual network requests, for example; instead, you want simulated results. These mocks are currently only built for unit tests and previews, compilation conditionals prevent them from being available for other build configurations. Another example is special code for view models and methods that can change their otherwise internal (or even private) state. These are therefore methods that should not and must not be used by developers in the app's regular code, as they soften the visibility and accessibility of types and thus violate the integrity of the software architecture. As a specific example, we have view model methods for previews that allow their internal state to be injected or changed from "outside" (i.e. inside the #Preview macro). I hope this makes it clear why certain code whose sole purpose is for previews may not be included in any other build. Developers should not be able to use this code outside of the context of a SwiftUI preview. That's also why the dead code stripping build feature is not sufficient for this purpose.