Elegir con criterio: dónde gana Swift y dónde no

Después de comparar Swift con cuatro lenguajes queda la pregunta que de verdad importa, y no admite respuesta ideológica: dado un proyecto concreto, con su plazo, su equipo y su plataforma de despliegue, ¿es Swift la elección correcta? La respuesta honesta es que en un puñado de dominios es la única opción sensata, en otro puñado compite de igual a igual, y en un tercero —más grande de lo que a sus entusiastas les gusta admitir— no compite en absoluto, y no por deficiencias del lenguaje sino por ausencia de ecosistema, de herramientas maduras fuera del entorno de Apple y de gente disponible. Saber trazar esa frontera con precisión es más valioso profesionalmente que dominar cualquiera de sus construcciones avanzadas.

El mapa de dominios

Conviene separar tres situaciones distintas que suelen confundirse en una sola discusión.

La fila de las herramientas de sistema merece un comentario porque suele pasarse por alto: es el dominio donde Swift ofrece la mejor relación entre esfuerzo y resultado fuera de las aplicaciones, gracias a que el análisis de argumentos, el sistema de archivos y los procesos hijos están cubiertos por bibliotecas oficiales y el binario resultante no necesita nada instalado en la máquina.

import ArgumentParser

@main
struct Migrar: AsyncParsableCommand {
    @Argument var origen: String
    @Option(name: .shortAndLong) var destino: String = "."
    @Flag var simular = false

    mutating func run() async throws {
        for archivo in try await listar(origen) {
            simular ? imprimir(archivo) : try await copiar(archivo, a: destino)
        }
    }
}

La primera columna decide más que ninguna otra cosa. En el territorio de Apple no hay debate: cualquier alternativa implica renunciar a herramientas, a integración con el sistema y a las novedades del año, y esa renuncia rara vez se compensa. En el extremo opuesto, en ciencia de datos, el lenguaje es irrelevante frente al hecho de que las bibliotecas que todo el mundo usa viven en otro sitio; el proyecto de tensores para Swift se canceló precisamente al chocar con esa realidad.

Dónde no compite y por qué

Los tres huecos grandes tienen causas distintas y merecen diagnósticos separados. Conviene nombrarlas antes de entrar en cada caso, porque confundirlas lleva a conclusiones equivocadas sobre qué se puede arreglar:

• Obstáculo técnico: falta una capacidad concreta y alguien podría construirla.
• Obstáculo de ecosistema: la capacidad existe, pero nadie ha escrito la periferia que la hace utilizable.
• Obstáculo político: el proveedor de la plataforma respalda otra ruta, y eso no lo arregla ningún compilador.

En el navegador, el obstáculo no es la falta de un objetivo de compilación —existe— sino todo lo demás: el tamaño del binario resultante, la integración con el modelo de eventos, la ausencia de un marco de interfaz consolidado y la competencia de un ecosistema que ha invertido dos décadas en resolver exactamente ese problema. Es un territorio donde ganar no significa ser mejor, significa ser mejor por un margen enorme, y ese margen no está.

En Android el obstáculo es político antes que técnico. Swift compila para esa plataforma y existen herramientas para compartir lógica entre ambos móviles, pero la ruta oficial pertenece a otro lenguaje y ninguna empresa razonable adopta como estrategia una vía que su proveedor de plataforma no respalda. El mismo razonamiento explica su posición marginal en Windows, donde el soporte es real y la adopción testimonial.

En el servidor el diagnóstico es más matizado, porque aquí Swift es técnicamente competitivo: rendimiento excelente, consumo de memoria bajo, concurrencia estructurada verificada y marcos maduros. Lo que falta es la periferia —clientes de bases de datos, integraciones con proveedores de nube, agentes de observabilidad, bibliotecas de autenticación— y, sobre todo, gente. Contratar a alguien que ya escriba Swift de servidor es difícil; contratar a alguien que ya escriba Go o Java no lo es. Ese factor decide más proyectos que cualquier prueba de rendimiento.

Lo que le falta

Los déficits que estrechan su territorio son concretos y en su mayoría reconocidos por el propio proyecto.

Ecosistema fuera de Apple. El gestor de paquetes funciona, pero el catálogo de bibliotecas de uso general es una fracción del de sus competidores, y la mantenida por Apple está sesgada hacia sus propias necesidades.

Herramientas fuera de Xcode. El servidor de lenguaje ha mejorado mucho y la experiencia en editores externos ya es viable, pero la depuración, el perfilado y la construcción de proyectos siguen siendo notablemente más cómodos dentro del entorno oficial, lo que ata al lenguaje a un sistema operativo concreto.

Tiempos de compilación y diagnósticos. La inferencia agresiva y la comprobación de restricciones producen compilaciones lentas en proyectos grandes y mensajes de error que a veces exigen entender el algoritmo de resolución para descifrarlos.

El coste de la transición a Swift 6. La seguridad frente a carreras de datos es un logro técnico mayor y también una barrera de adopción real: migrar una base de código existente cuesta trabajo, y esa fricción ha frenado a equipos que de otro modo estarían al día.

Percepción de gobernanza. Aunque el proceso de evolución es abierto y documentado, la dirección la marca de facto una empresa, y esa percepción pesa cuando alguien decide en qué apoyar una infraestructura que debe durar diez años.

Un criterio operativo

La decisión se puede reducir a una secuencia corta de preguntas, respondidas en orden y sin saltarse ninguna.

flowchart TD
A[Objetivo de despliegue] -->|Plataformas de Apple| SI[Elige Swift]
A -->|Firmware o embebido| B[Hay soporte para el chip]
B -->|Si| SI
B -->|No| OTRO[Elige C o Rust]
A -->|Servidor o herramienta| C[El equipo ya escribe Swift]
C -->|No| OTRO2[Elige el lenguaje del equipo]
C -->|Si| D[Existen las bibliotecas criticas]
D -->|No| OTRO2
D -->|Si| SI
A -->|Navegador o datos| OTRO3[Swift no compite hoy]
style SI fill:#a6e3a1,color:#11111b
style OTRO3 fill:#f38ba8,color:#11111b

Hay una excepción legítima a ese árbol y conviene enunciarla para no aplicarlo como dogma: cuando la propiedad que ofrece el lenguaje coincide exactamente con el riesgo dominante del proyecto, la falta de ecosistema deja de ser el criterio principal. Un firmware donde un desbordamiento de búfer significa un fallo de seguridad no negociable, o un sistema concurrente donde una carrera de datos corrompería registros contables, son casos en los que aceptar una red de bibliotecas más pobre a cambio de una garantía verificada es una decisión defendible ante cualquier auditoría.

El orden importa: la plataforma manda sobre el equipo, el equipo manda sobre las bibliotecas y las bibliotecas mandan sobre las preferencias. Invertir ese orden —empezar por lo que uno prefiere escribir— es la forma más común de tomar una decisión que alguien lamentará dentro de dos años, cuando descubra que la biblioteca crítica no existe y hay que escribirla.