Se detiene la adopción de Swift: se cierra el issue de soporte de Swift 6.0 en el navegador Ladybird

 (github.com/LadybirdBrowser)
1 puntos por GN⁺ 2026-02-20 | 1 comentarios | Compartir por WhatsApp
  • El proyecto del navegador Ladybird organizó una lista de problemas surgidos durante la transición del soporte de Swift 6.0 desde una fase experimental a una oficial, pero después decidió no seguir impulsando la adopción de Swift
  • Los principales obstáculos fueron problemas relacionados con la interoperabilidad (Interop) entre Swift y C++, como discrepancias de ABI, dependencias circulares de headers e imposibilidad de devolver ciertos tipos; varios de estos puntos se corrigieron después de Swift 6.0.0
  • En el sistema de build CMake también se reportaron problemas como discrepancias de target de despliegue en entornos Swift + Ninja, errores en el manejo de install_name y opciones de compilación incompatibles
  • En el propio código de Ladybird también se confirmaron múltiples inestabilidades de build, como la configuración de modulemap en los módulos AK y LibGfx, crashes del frontend de Swift y conflictos de namespaces de tipos
  • Debido a estas limitaciones técnicas acumuladas, se detuvo la integración de Swift, lo que llevó a la decisión de mantener un desarrollo centrado en C++

Problemas relacionados con Swift

  • Existían numerosos bugs a nivel de lenguaje y ABI que debían resolverse para sacar el soporte de Swift 6.0 de la fase experimental
    • Se producían fallas por assertion al compilar Swift open source debido a una incompatibilidad de versiones de LLVM
    • Problema de discrepancia de ABI entre el compilador y el bridging header al devolver Optional<CxxValueType>
    • En Ubuntu 22.04, al incluir el header <execution> se generaba una dependencia circular de módulos en libstdc++
    • También había problemas de compatibilidad con C++23, como la imposibilidad de devolver swift::Optional<swift::String> y fallas al cargar el header <chrono>
  • Algunos problemas se corrigieron en lanzamientos posteriores a Swift 6.0.0, pero otros solo se resolvieron en la rama main, por lo que no se reflejaron en versiones estables
  • En varios puntos se propusieron “workarounds (métodos alternativos de build)”, pero no eran soluciones completas

Problemas relacionados con CMake

  • En la combinación de build con Swift y Ninja, CMAKE_OSX_DEPLOYMENT_TARGET no se aplicaba, lo que generaba múltiples advertencias
    • Era necesario configurar manualmente CMAKE_Swift_COMPILER_TARGET
  • Al activar la política CMP0157, la configuración del directorio de install_name se ignoraba, por lo que había que corregirlo manualmente
    • La corrección relacionada estaba prevista para backport en CMake 3.29 y 3.30
  • Existía además un problema donde dependencias externas pasaban opciones de enlace que el compilador de Swift no entiende

Problemas internos del proyecto Ladybird

  • Al configurar los clang module map de los módulos AK y LibGfx, se producían conflictos con headers del sistema
    • Al incluir <math.h>, el build fallaba por un error de reconocimiento de módulos
  • El frontend de Swift crasheaba en builds debug durante pruebas de contenedores AK
    • Solo era posible evitarlo compilando en modo release
  • Un conflicto de namespaces con el tipo String provocaba el cierre anormal del frontend de Swift
    • Era necesario especificar explícitamente AK.String o Swift.String
  • Al usar el módulo Swift Testing también había crashes del frontend del compilador, además del problema de que AK::StringView no era reconocido como CxxSequenceType

Mejoras adicionales pendientes

  • En Swift, cuando una función de C++ devuelve Optional<CxxType>, se producía un crash de la aplicación
    • Como solución temporal, se usaba devolver un arreglo de tamaño 0 o 1
  • SourceKit-LSP y vscode-swift requieren un compile_commands.json en el nivel raíz
    • Esto puede resolverse creando un enlace simbólico
  • En Linux también existía la incomodidad de tener que agregar manualmente la ruta <swift/bridging>

Preguntas sin resolver

  • No estaba claro cómo pasar desde Swift tipos view de C++ o byte slices sin copiar datos
  • Swift no reconoce tipos propios como AK::Optional o AK::HashMap como equivalentes a los tipos de std::
  • También seguía sin definirse cómo integrar el recolector de basura de Swift con la gestión de memoria de Ladybird

Este issue era un documento que registraba de forma sistemática los obstáculos técnicos para integrar Swift 6.0, pero después de que el equipo de Ladybird abandonara la adopción de Swift, el issue “Swift 6.0 Blockers” quedó cerrado.

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-02-20
Comentarios en Hacker News

  • El commit que elimina Swift incluye un poco de explicación adicional
    Contiene el mensaje: “Se abandona la adopción de Swift y se elimina del codebase porque no hubo progreso durante mucho tiempo”
    El commit relacionado puede verse aquí

    • Aquí hay más contexto detallado en el issue #933

  • Yo probé Swift por primera vez en 2021, y me sorprendió después de pasar más de 10 años con C#/.NET
    Pensaba que C# también era complejo, pero Swift era un lenguaje mucho más complejo
    En especial, casi no había material de referencia cuando querías construir APIs de backend o una capa de acceso a datos
    Como casi todo el conocimiento de Swift está acumulado para plataformas de Apple, fuera de eso se sentía como si tuvieras que ser casi un pionero

    • En los últimos años, lenguajes simples como Python o Go han reforzado la idea de que “la complejidad es mala”, pero creo que una mayor expresividad del lenguaje en realidad puede ayudar al mantenimiento
      Como dijo Larry Wall, la complejidad de la herramienta debe corresponderse con la complejidad del problema (mención de Raku)
    • Yo me pasé de Objective-C a Swift alrededor de 2018, y al principio sí se sintió como una mejora
      Pero reglas como “struct se pasa por valor y class por referencia” chocaban con el principio de “mantener una única fuente de verdad”, y eso hacía que el desarrollo se volviera tedioso y lento
      No había progreso por las best practices contradictorias de Swift, y al final me di cuenta de que muchos consejos no eran tan confiables
    • También tuve el problema de que mi laptop se sobrecalentaba cada vez que compilaba una plantilla de Vapor en una MacBook M1
    • Me pasó algo parecido. Pensé que lo aprendería rápido, como Rust, pero para nada
      Tiene demasiada azúcar sintáctica y hay decenas de formas de hacer lo mismo, así que tenía que revisar la referencia del lenguaje a cada rato
    • Por eso me da curiosidad si al final volviste a C#/.NET

  • Sin importar el lenguaje, ojalá que Ladybird más adelante se enfoque en una implementación de JavaScript amigable para el usuario
    Es un problema que JS se use indebidamente para rastrear actividad del usuario, bloquear el pegado o recolectar demasiada información del dispositivo
    Reportar valores de spoofing estandarizados entre usuarios, como hace Tor, podría ayudar a proteger la privacidad

    • Pero ese enfoque podría hacer que muchos sitios web lo confundan con detección de bots y bloqueen el acceso
      Está bien ofrecerlo como una opción con toggle, pero sería difícil adoptarlo si viniera activado por defecto
    • En lo personal, jamás querría usar un navegador que ignorara los estándares web y funcionara por su cuenta

  • Es interesante que hayan quitado Swift. Como no explicaron claramente la razón, da curiosidad
    Si al menos corre en Linux, pienso probarlo más adelante

    • Por lo que veo, parece que se rindieron por los conflictos de build repetidos
      Era un problema donde Swift no podía importar varias bibliotecas de distintas versiones de C++ al mismo tiempo, o surgían conflictos entre versiones de operadores
      Swift es un buen lenguaje, pero parece demasiado complicado para agregarlo más tarde a un proyecto ya grande

  • Me pregunto por qué Ladybird intentó usar Swift. Yo pensaría que Rust tiene una mejor interoperabilidad con C++
    Además, el GC de Swift parecería perjudicial para el rendimiento de un navegador

    • Andreas Kling mencionó en Twitter que, entre “Swift vs Rust”, Swift era mejor en soporte orientado a objetos e integración con C++
      Link1, Link2
    • Es parecido a por qué Rust resulta incómodo en desarrollo de videojuegos. El borrow checker no encaja bien con estructuras de referencias circulares
      Hay formas de rodearlo, pero la productividad cae
    • Swift en realidad tiene una interoperabilidad bastante buena, como se ve en la documentación de C++ interop
      Solo que, al parecer, no fue suficiente para Ladybird
    • Andreas Kling dijo que Rust está en desventaja para desarrollar GUIs porque le faltan capacidades orientadas a objetos
      Antes incluso crearon un lenguaje llamado Jakt en SerenityOS, pero parece que al final volvieron a C++
    • Recuerdo que Rust ya había sido descartado por temas de jerarquía del DOM o problemas de OOP
      Hay una discusión anterior relacionada en este post

  • No sorprende, Swift es un lenguaje demasiado dependiente de Apple
    Basta con usar bien las partes seguras de C++, y de hecho la mayoría de los navegadores están escritos en C++

    • Pero todos los navegadores simplemente están atrapados en C++
      Chromium y Firefox lo están reemplazando gradualmente por lenguajes más seguros, y reescribir un navegador nuevo en C++ sería repetir errores del pasado
      El uso de C++ es una herencia de la época de KHTML en 1998
    • No me queda claro qué significa exactamente un “subconjunto moderno y memory-safe de C++”
      ¿Incluye funciones modernas de STL como string_view? Aun así, sigue estando lejos de una seguridad de memoria completa
    • Tengo entendido que Rust fue desarrollado en Mozilla, pero me pregunto si Mozilla mismo está escrito en Rust
    • De todos modos, en áreas donde se necesita alto rendimiento, Swift difícilmente le va a ganar a C++
      Salvo algunos benchmarks, en programas reales casi siempre es más lento

  • Qué lástima que hayan quitado Swift. Entonces me pregunto si su propio lenguaje, Jakt, volverá a ser candidato

    • Ladybird ya se separó de SerenityOS, y Jakt no es su lenguaje
      No creo que sea muy probable que introduzcan un lenguaje nuevo
    • En lo personal, me preocupa que el proyecto cambie de dirección con demasiada frecuencia
      Si un proyecto financiado con patrocinio externo funciona así, puede ser difícil sostenerlo a largo plazo
    • Me frustra que no usen Rust. A veces me pregunto si será por una obsesión con C++

  • Al final, Swift me parece solo un lenguaje-juguete de Apple
    Apple no va a dejar que crezca más allá de eso

  • La UI de Mac de Ladybird es una capa delgada encima de AppKit
    Está escrita en Objective-C++, no en Swift
    Ver código fuente

    • Yo fui quien escribió ese código originalmente
      Lo hice mucho antes de que se introdujera Swift, en la época de SerenityOS, así que usé Objective-C++ simplemente porque era un lenguaje familiar

  • Yo había criticado antes el cambio a Swift
    Me parecía que Swift tenía un diseño flojo, compilaba lento, y veía poco probable que creciera como lenguaje de sistemas
    Como tampoco había especialistas, creo que esta decisión fue acertada

    • Aunque Swift parece open source, en realidad Apple sigue teniendo todo el poder de decisión
      Funciones como Concurrency o Swift Testing también son casos que empujaron según las necesidades de Apple
      El trabajo cross-platform lo llevan aparte, en su mayoría, equipos pequeños
    • Reconozco los problemas de Swift, pero decir que “no había especialistas” es exagerado
      Incluso dejando fuera a Chris Lattner, los líderes de Swift eran figuras reconocidas en la comunidad de C++
    • El punto central de Swift no es tanto el lenguaje en sí, sino su ABI estándar
      Estaría bien que el ecosistema Rust soportara ese ABI de Swift además de C para FFI
    • Entonces, ¿qué lenguaje recomendarías?
    • ¿Go es parecido? Quiero saber cuál es la opción con mayor consenso hoy en día