¿Para qué sirve un archivo de constantes globales en Swift?
\n\nTodo desarrollador iOS se ha encontrado al menos una vez en la vida con una situación en la que los mismos valores — URL del servidor, claves de API, identificadores de celdas, márgenes — están dispersos por todo el proyecto. Y entonces el jefe dice: «Cambia la URL base». Abres el proyecto y comienza la búsqueda: encontrar todas las ocurrencias de "https://old.api.com" y reemplazarlas por la nueva. ¿Te suena?
Precisamente para eso sirve un archivo de constantes globales en Swift: un lugar único donde se almacenan todos los «números mágicos» y cadenas. En este artículo, analizaremos las preguntas más frecuentes de Stack Overflow (¡el tema tiene miles de visitas!) y daremos respuestas claras con ejemplos de código. ¡Allá vamos!
\n\nPregunta 1: ¿Cómo crear un archivo de constantes simple en Swift?
\n\nLa forma más directa es usar una struct con propiedades estáticas. ¿Por qué struct y no class? Porque las estructuras son tipos de valor, son más ligeras y no requieren un inicializador.
// 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}\n\nSe usa simplemente: AppConstants.baseURL. Listo, nada de cadenas mágicas. Las constantes de Swift con let garantizan que el valor no cambiará accidentalmente.
¿Por qué no usar variables globales?
\n\nSe puede, por supuesto, escribir:
\n\nlet baseURL = "https://api.myapp.com/v1"\n\nPero esto es un archivo de constantes globales en Swift en su forma más primitiva. El problema: no hay espacio de nombres. Si tienes 50 constantes, rápidamente te confundirás sobre cuál pertenece a qué. struct resuelve este problema de forma elegante.
Pregunta 2: Enum o Struct: ¿qué elegir para las constantes?
\n\nEn Stack Overflow hay acalorados debates. Analicemos ambos enfoques.
\n\nStruct (opción popular)
\n\nstruct UIConstants {\n static let cornerRadius: CGFloat = 12.0\n static let defaultPadding: CGFloat = 16.0\n static let animationDuration: Double = 0.3\n}\n\nVentajas: familiar, se pueden crear instancias (aunque normalmente no es necesario), fácil de extender mediante extension.
\n\nDesventajas: técnicamente se puede escribir UIConstants(), lo cual no tiene sentido.
Enum (opción más estricta)
\n\nenum 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}\n\nVentajas: no se puede crear una instancia — el compilador no lo permitirá. Espacio de nombres limpio. Ideal para Swift enum constants.
\n\nDesventajas: algunos lo consideran un «hack» — usar enum para un propósito diferente al original.
\n\nMi veredicto: si quieres ser un desarrollador «correcto» y protegerte contra la creación accidental de instancias, usa enum. Si trabajas en un equipo donde todos están acostumbrados a struct, usa struct. Ambas opciones son válidas.
Pregunta 3: ¿Cómo organizar las constantes por categorías?
\n\nCuando el proyecto crece, un solo archivo se convierte en un vertedero. La solución son estructuras anidadas o archivos separados para cada categoría.
\n\nOpción A: Estructuras anidadas (en un solo archivo)
\n\nstruct 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 =