Introduction

In Swift projects, the answer is yes: you can define project-level or scheme-specific flags without relying on C-style preprocessor macros. The practical tools are build configurations, .xcconfig files, Swift active compilation conditions, Info.plist values, and scheme environment variables, depending on whether the flag must exist at compile time or runtime.

Separate Compile-Time Flags From Runtime Configuration

The first decision is what kind of switch you need.

Use compile-time conditions when code should be included or excluded from the build. Use runtime configuration when the same binary should behave differently depending on the selected scheme or environment.

A useful split is:

• compile-time: feature stubs, debug-only code, logging branches
• runtime: API base URLs, analytics endpoints, demo credentials, test toggles

Mixing those concerns leads to confusing build setups.

Use Swift Active Compilation Conditions

Swift does not use the old C preprocessor macro style for most app code. Instead, Xcode exposes SWIFT_ACTIVE_COMPILATION_CONDITIONS, which lets you define custom conditions per build configuration.

For example, suppose you create three configurations:

• 'Debug'
• 'Staging'
• 'Release'

You can assign a compilation condition such as STAGING to the Staging configuration. Then use it in Swift code.

1struct Environment {
2    static let apiBaseURL: String = {
3        #if STAGING
4        return "https://staging.example.com"
5        #elseif DEBUG
6        return "https://dev.example.com"
7        #else
8        return "https://api.example.com"
9        #endif
10    }()
11}
12
13print(Environment.apiBaseURL)

This is the Swift-native equivalent of using build-time flags for conditional compilation.

Store the Settings in .xcconfig Files

For real projects, hardcoding everything in the Xcode UI does not scale well. .xcconfig files are a cleaner way to define per-configuration values and keep them in source control.

Example Staging.xcconfig:

SWIFT_ACTIVE_COMPILATION_CONDITIONS = $(inherited) STAGING
API_BASE_URL = https://staging.example.com
APP_DISPLAY_NAME = MyApp Staging

Example Release.xcconfig:

SWIFT_ACTIVE_COMPILATION_CONDITIONS = $(inherited)
API_BASE_URL = https://api.example.com
APP_DISPLAY_NAME = MyApp

Once the project or target uses these files, the build settings become readable and reproducible.

Use Build Settings or Info.plist for Runtime Values

Not every flag should be a compile-time condition. If the app should read a value at runtime, define a user setting in build settings and inject it into Info.plist.

For example, add API_BASE_URL in build settings, reference it in Info.plist, and read it from code.

<key>APIBaseURL</key>
<string>$(API_BASE_URL)</string>

Then read it in Swift:

1import Foundation
2
3let apiBaseURL = Bundle.main.object(forInfoDictionaryKey: "APIBaseURL") as? String
4print(apiBaseURL ?? "missing")

This pattern is excellent for environment-specific values that should not require separate source files or compile-time branching.

Schemes Select Configurations

Schemes themselves do not usually hold the main truth of configuration. Instead, schemes choose which build configuration to use for Run, Test, Profile, and Archive actions.

That means the scalable setup is:

1. create named build configurations
2. attach .xcconfig files to them
3. map scheme actions to those configurations

The scheme then becomes a selector, while the configuration files hold the actual environment settings.

Use Environment Variables for Tests and Local Overrides

Scheme environment variables are best for runtime behavior during local execution or UI tests. They are not a strong substitute for build configuration, but they are useful for temporary overrides.

1import Foundation
2
3let featureEnabled = ProcessInfo.processInfo.environment["FEATURE_X_ENABLED"] == "1"
4print(featureEnabled)

This works well for test-only knobs or local experiments that should not change the compiled app structure.

Pick the Right Tool for the Job

A practical rule is:

• use SWIFT_ACTIVE_COMPILATION_CONDITIONS for compile-time inclusion rules
• use build settings plus Info.plist for runtime constants bundled into the app
• use scheme environment variables for local runtime overrides
• use .xcconfig files to keep all of the above maintainable

That combination covers most needs without reaching for preprocessor-style macro habits.

Common Pitfalls

The most common mistake is putting runtime values behind compile-time flags. That creates extra binaries when a simple bundled setting would have been enough.

Another mistake is storing all configuration only in the Xcode UI. It works until another developer or CI job needs to reproduce the setup exactly.

Teams also confuse schemes with configurations. A scheme selects how the app is built and run, but the reusable settings usually belong in build configurations and .xcconfig files.

Finally, avoid using too many custom flags when a single environment object or configuration value would be clearer.

Summary

• Swift projects can use scheme-specific behavior without C-style macros.
• 'SWIFT_ACTIVE_COMPILATION_CONDITIONS is the normal compile-time mechanism.'
• '.xcconfig files are the maintainable place to define per-configuration settings.'
• Build settings plus Info.plist are ideal for runtime constants.
• Schemes should usually select configurations, not become the only place configuration lives.