Global constants file in Swift: everything you wanted to know but were afraid to ask

Why do you need a global constants file in Swift?

Every iOS developer has encountered a situation at least once where the same values — server URL, API keys, cell identifiers, paddings — are scattered throughout the project. And then the boss says: "Change the base URL." You open the project, and the quest begins: find all occurrences of "https://old.api.com" and replace them with the new one. Sound familiar?

That's exactly what a global constants file in Swift is for — a single place where all "magic numbers" and strings are stored. In this article, we'll break down the most common questions from Stack Overflow (the topic has thousands of views!) and provide clear answers with code examples. Let's go!

Question 1: How to create a simple constants file in Swift?

The most straightforward way is to use a struct with static properties. Why struct and not class? Because structs are value types, they are lighter and don't require an initializer.

// Constants.swift\nimport Foundation\n\nstruct AppConstants {\n    static let baseURL = "https://api.myapp.com/v1"\n    static let apiKey = "your-secret-key-here"\n    static let defaultTimeout: TimeInterval = 30.0\n    static let maxRetryCount = 3\n}

Usage is simple: AppConstants.baseURL. That's it, no magic strings. Swift constants with let guarantee that the value won't be accidentally changed.

Why not use global variables?

You could, of course, write:

let baseURL = "https://api.myapp.com/v1"

But this is a global constants file in Swift in its most primitive form. The problem: no namespace. If you have 50 constants, you'll quickly get confused about which one belongs where. struct solves this problem elegantly.

Question 2: Enum or Struct — which to choose for constants?

On Stack Overflow, heated debates are raging. Let's break down both approaches.

Struct (popular option)

struct UIConstants {\n    static let cornerRadius: CGFloat = 12.0\n    static let defaultPadding: CGFloat = 16.0\n    static let animationDuration: Double = 0.3\n}

Pros: familiar, you can create instances (though usually not needed), easy to extend via extension.

Cons: technically you can write UIConstants(), which doesn't make sense.

Enum (stricter option)

enum NetworkConstants {\n    static let baseURL = "https://api.myapp.com/v1"\n    static let apiVersion = "2.0"\n    static let defaultHeaders: [String: String] = [\n        "Content-Type": "application/json"\n    ]\n}

Pros: you cannot create an instance — the compiler won't allow it. A clean namespace. Ideal for Swift enum constants.

Cons: some consider this a "hack" — using an enum not for its intended purpose.

My verdict: If you want to be a "proper" developer and protect against accidental instance creation — use enum. If you work in a team where everyone is used to struct — use struct. Both options are valid.

Question 3: How to organize constants by category?

When a project grows, one file turns into a dump. The solution — nested structs or separate files for each category.

Option A: Nested structs (in one file)

struct Constants {\n    struct Network {\n        static let baseURL = "https://api.myapp.com"\n        static let timeout: TimeInterval = 30\n    }\n    \n    struct UI {\n        static let cornerRadius: CGFloat = 8\n        static let buttonHeight: CGFloat = 44\n    }\n    \n    struct Storage {\n        static let userDefaultsKey = "com.myapp.user"\n        static let maxCacheSize =