Arquivo de constantes globais em Swift: tudo o que você queria saber, mas tinha medo de perguntar

Para que serve um arquivo de constantes globais em Swift?

Todo desenvolvedor iOS já se deparou pelo menos uma vez com a situação em que os mesmos valores — URL do servidor, chaves de API, identificadores de células, margens — estão espalhados por todo o projeto. E então o chefe diz: "Mude a URL base". Você abre o projeto e começa a missão: encontrar todas as ocorrências de "https://old.api.com" e substituir pela nova. Familiar?

É exatamente para isso que serve o arquivo de constantes globais em Swift — um local único onde todos os "números mágicos" e strings são armazenados. Neste artigo, vamos abordar as perguntas mais frequentes do Stack Overflow (o tópico tem milhares de visualizações!) e dar respostas claras com exemplos de código. Vamos lá!

Pergunta 1: Como criar um arquivo de constantes simples em Swift?

A maneira mais direta é usar uma struct com propriedades estáticas. Por que struct e não class? Porque structs são tipos de valor, são mais leves e não requerem um inicializador.

// Constants.swift\nimport Foundation\n\nstruct AppConstants {\n    static let baseURL = "https://api.myapp.com/v1"\n    static let apiKey = "sua-chave-secreta-aqui"\n    static let defaultTimeout: TimeInterval = 30.0\n    static let maxRetryCount = 3\n}

Usar é simples: AppConstants.baseURL. Pronto, sem strings mágicas. As constantes Swift com let garantem que o valor não será alterado acidentalmente.

Por que não usar variáveis globais?

Você pode, é claro, escrever:

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

Mas isso é um arquivo de constantes globais em Swift na sua forma mais primitiva. O problema: não há namespace. Se você tiver 50 constantes, rapidamente ficará confuso sobre qual pertence a quê. A struct resolve esse problema de forma elegante.

Pergunta 2: Enum ou Struct — o que escolher para constantes?

No Stack Overflow, há debates acalorados. Vamos analisar ambas as abordagens.

Struct (opção popular)

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

Vantagens: familiar, pode criar instâncias (embora geralmente não seja necessário), fácil de estender com extension.

Desvantagens: tecnicamente, você pode escrever UIConstants(), o que não faz sentido.

Enum (opção mais rigorosa)

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}

Vantagens: não é possível criar uma instância — o compilador não permite. Namespace puro. Ideal para Swift enum constants.

Desvantagens: alguns consideram isso um "hack" — usar enum fora de seu propósito original.

Meu veredito: se você quer ser um desenvolvedor "correto" e se proteger contra a criação acidental de instâncias — use enum. Se você trabalha em uma equipe onde todos estão acostumados com struct — use struct. Ambas as opções são válidas.

Pergunta 3: Como organizar constantes por categorias?

Quando o projeto cresce, um único arquivo se torna uma bagunça. A solução são structs aninhadas ou arquivos separados para cada categoria.

Opção A: Structs aninhadas (em um único arquivo)

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 =