{"id":126,"date":"2017-05-05T19:40:03","date_gmt":"2017-05-05T22:40:03","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/2017\/05\/instalando-swift-no-linux\/"},"modified":"2026-09-22T21:37:47","modified_gmt":"2026-09-23T00:37:47","slug":"instalando-swift-no-linux","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/es\/2017\/05\/instalando-swift-no-linux\/","title":{"rendered":"Swift en Linux: instalaci\u00f3n, Hola Mundo y primer proyecto"},"content":{"rendered":"

\"Mascote<\/p>\n

Nota (2026):<\/strong> Publicado originalmente en mayo de 2017 para Swift 3.1 en Ubuntu; esta gu\u00eda se actualiz\u00f3 en 22 de septiembre de 2026 para Swift 6.4.0, instalado por el m\u00e9todo oficial con Swiftly, manteniendo la URL y la fecha hist\u00f3rica.<\/div>\n

\u00bfQuieres probar Swift en Linux sin empezar por un proyecto enorme? Vamos a instalar el lenguaje por el m\u00e9todo oficial de swift.org, ejecutar un Hello World, generar un binario y montar una peque\u00f1a herramienta de terminal con argumentos. El objetivo es salir de este art\u00edculo con c\u00f3digo funcionando y entender la diferencia entre swift<\/code>, swiftc<\/code> y Swift Package Manager.<\/p>\n

<\/p>\n

Antes de instalar: el lenguaje Swift no es OpenStack Swift<\/h2>\n

Este tutorial trata sobre el lenguaje de programaci\u00f3n. El paquete llamado swift en Debian<\/a> pertenece a OpenStack, un sistema de almacenamiento de objetos. No lo uses apt install swift<\/code> como atajo para instalar el compilador de este art\u00edculo: consulta siempre la descripci\u00f3n del paquete.<\/p>\n

Usa una distribuci\u00f3n y arquitectura presentes en las opciones oficiales de instalaci\u00f3n de Swift en Linux<\/a>. Los ejemplos de preparaci\u00f3n siguientes usan Ubuntu\/Debian y Bash. Comprueba la distribuci\u00f3n y la arquitectura antes de empezar:<\/p>\n

cat \/etc\/os-release\nuname -m<\/code><\/pre>\n
Para empezar, reserva una carpeta en tu usuario y ten acceso a internet. Las dependencias del sistema requieren sudo; Swiftly, la toolchain y los comandos de compilaci\u00f3n quedan en tu usuario y no necesitan root.<\/p>\n
Instala Swift 6.4 con Swiftly<\/h2>\n
Swiftly es el instalador oficial: descarga la toolchain, verifica su firma y permite alternar entre versiones. En la consulta de 22\/09\/2026, la p\u00e1gina oficial<\/a> indicaba Swift 6.4.0<\/strong>, publicado el 15 de septiembre de 2026. Prepara las herramientas b\u00e1sicas:<\/p>\n
sudo apt update && sudo apt install -y ca-certificates curl gnupg tar<\/code><\/pre>\n
Descarga el instalador indicado por el sitio, la firma y las claves del proyecto. El nombre del archivo usa la arquitectura de la m\u00e1quina (x86_64<\/code> o aarch64<\/code>) y siempre apunta a la versi\u00f3n actual de Swiftly:<\/p>\n
mkdir -p \"$HOME\/Downloads\/swiftly-linuxpro\"\ncd \"$HOME\/Downloads\/swiftly-linuxpro\"\n\ncurl -O https:\/\/download.swift.org\/swiftly\/linux\/swiftly-$(uname -m).tar.gz\ncurl -O https:\/\/download.swift.org\/swiftly\/linux\/swiftly-$(uname -m).tar.gz.sig\ncurl --compressed https:\/\/www.swift.org\/keys\/all-keys.asc | gpg --import -\ngpg --verify swiftly-$(uname -m).tar.gz.sig swiftly-$(uname -m).tar.gz<\/code><\/pre>\n
La salida debe contener Good signature from \"Swift Automatic Signing Key<\/code>. El aviso de que la clave no est\u00e1 certificada por una firma de confianza es normal cuando la acabas de importar. Si aparece BAD signature<\/code>, para: no extraigas ni ejecutes el archivo. Con la firma confirmada, ejecuta exactamente el comando de la p\u00e1gina oficial:<\/p>\n
tar zxf swiftly-$(uname -m).tar.gz && \\\n.\/swiftly init --quiet-shell-followup && \\\n. \"${SWIFTLY_HOME_DIR:-$HOME\/.local\/share\/swiftly}\/env.sh\" && \\\nhash -r<\/code><\/pre>\n
O init<\/code> descarga poco m\u00e1s de 1 GB, comprueba la firma del toolchain y define Swift 6.4.0 como predeterminado. Al final, imprime un comando apt-get<\/code> con las dependencias que faltan en el sistema. No te saltes este paso:<\/strong> en Ubuntu 24.04 limpio que usamos en la prueba, swift<\/code> fallaba con libncurses.so.6: cannot open shared object file<\/code> hasta instalar la lista indicada, que fue esta:<\/p>\n
sudo apt-get -y install binutils git unzip zip gnupg2 libc6-dev libcurl4-openssl-dev \\\n  libedit2 libgcc-13-dev libpython3-dev libstdc++-13-dev libxml2-dev libncurses-dev \\\n  libz3-dev pkg-config tzdata zlib1g-dev<\/code><\/pre>\n
En otra distribuci\u00f3n o versi\u00f3n, usa la lista que tu swiftly init<\/code> muestre, no esta. Despu\u00e9s comprueba:<\/p>\n
swift --version\nswiftc --version<\/code><\/pre>\n
La salida debe mencionar Swift version 6.4.0<\/code>. El archivo env.sh<\/code> ajusta la sesi\u00f3n actual; init<\/code> tambi\u00e9n configura tu shell para los pr\u00f3ximos terminales. Los detalles de cada paso est\u00e1n en la gu\u00eda oficial Getting Started with Swiftly on Linux<\/a>.<\/p>\n
Hello World b\u00e1sico: un archivo y una l\u00ednea<\/h2>\n
Comience fuera de la carpeta del instalador. Cree un directorio de estudio y un archivo llamado hello.swift<\/code>:<\/p>\n
mkdir -p \"$HOME\/projetos\/swift-linuxpro\"\ncd \"$HOME\/projetos\/swift-linuxpro\"\ncat > hello.swift <<'SWIFT'\nprint(\"Hello, world!\")\nSWIFT\n\nswift hello.swift<\/code><\/pre>\n
La salida esperada es:<\/p>\n
Hello, world!<\/code><\/pre>\n
Aqu\u00ed, print<\/code> escribe un mensaje en la salida est\u00e1ndar. La llamada swift hello.swift<\/code> ejecuta el archivo sin que tengas que gestionar manualmente un ejecutable. Es una buena v\u00eda para peque\u00f1os experimentos; no es necesario crear un paquete para cada prueba.<\/p>\n
Compila el mismo programa con swiftc<\/h2>\n
Ahora genera un ejecutable con un nombre definido:<\/p>\n
swiftc hello.swift -o hello\n.\/hello<\/code><\/pre>\n
El mensaje es el mismo, pero el flujo ha cambiado: primero has compilado; despu\u00e9s lo has ejecutado .\/hello<\/code>. Cuando modifiques el c\u00f3digo, vuelve a ejecutar el compilador para actualizar el binario. El prefijo .\/<\/code> indica que el archivo est\u00e1 en el directorio actual.<\/p>\n
Un binario compilado en tu equipo no es autom\u00e1ticamente compatible con todo Linux. La arquitectura, las bibliotecas y el runtime del entorno de destino importan. Para una distribuci\u00f3n m\u00e1s controlada, estudia el Swift SDK for Static Linux<\/a>; esto es un paso posterior al Hola Mundo.<\/p>\n
Crea una herramienta con Swift Package Manager<\/h2>\n
Cuando el c\u00f3digo gane m\u00e1s archivos y dependencias, usa Swift Package Manager, que acompa\u00f1a a la toolchain. En lugar de gestionarlo todo manualmente, organiza el manifiesto y la compilaci\u00f3n. Crea un proyecto nuevo dentro del directorio de estudio:<\/p>\n
mkdir OlaLinux\ncd OlaLinux\nswift package init --name OlaLinux --type executable\nswift run OlaLinux<\/code><\/pre>\n
La plantilla inicial ya imprime un saludo. En la toolchain Swift 6.4.0 probada en esta revisi\u00f3n, Package.swift<\/code> es el manifiesto y Sources\/OlaLinux\/OlaLinux.swift<\/code> es el punto de entrada. Comprueba la estructura creada por tu versi\u00f3n antes de editar archivos. La gu\u00eda oficial de herramientas de l\u00ednea de comandos<\/a> explica este flujo.<\/p>\n
Sustituye el contenido de Sources\/OlaLinux\/OlaLinux.swift<\/code> por el ejemplo de abajo. Acepta un nombre en el terminal y usa LinuxPro cuando no se pasa ning\u00fan argumento:<\/p>\n
@main\nstruct OlaLinux {\n    static func saudacao(para pessoa: String) -> String {\n        return \"Ol\u00e1, \\(pessoa)! Swift est\u00e1 rodando no Linux.\"\n    }\n\n    static func main() {\n        let nome = CommandLine.arguments.dropFirst().first ?? \"LinuxPro\"\n        print(saudacao(para: nome))\n    }\n}<\/code><\/pre>\n
swift run OlaLinux\nswift run OlaLinux Nilton<\/code><\/pre>\n
Los mensajes esperados son, respectivamente:<\/p>\n
Ol\u00e1, LinuxPro! Swift est\u00e1 rodando no Linux.\nOl\u00e1, Nilton! Swift est\u00e1 rodando no Linux.<\/code><\/pre>\n
El marcador @main<\/code> define el punto de entrada, que llama main()<\/code>. En este c\u00f3digo, let<\/code> declara un valor que no se va a reasignar. CommandLine.arguments<\/code> contiene los argumentos del proceso; dropFirst()<\/code> salta el nombre del ejecutable y first<\/code> obtiene el siguiente elemento, si existe. El operador ??<\/code> proporciona el valor por defecto. La funci\u00f3n recibe un nombre y devuelve el mensaje usando interpolaci\u00f3n de cadenas.<\/p>\n
Para estudiar la sintaxis con m\u00e1s calma, sigue el tour oficial del lenguaje Swift<\/a>. Para una CLI con opciones, ayuda y validaci\u00f3n de entradas, el siguiente paso es el Swift Argument Parser<\/a>; no necesitamos a\u00f1adir dependencias para este primer saludo.<\/p>\n
A\u00f1ade una prueba automatizada<\/h2>\n
La plantilla tambi\u00e9n cre\u00f3 una carpeta de pruebas. Sustituye Tests\/OlaLinuxTests\/OlaLinuxTests.swift<\/code> por el ejemplo de abajo, que verifica el mensaje producido por la funci\u00f3n sin depender de la salida de la terminal:<\/p>\n
import Testing\n@testable import OlaLinux\n\n@Test func saudacaoIncluiNome() {\n    #expect(OlaLinux.saudacao(para: \"Nilton\") ==\n        \"Ol\u00e1, Nilton! Swift est\u00e1 rodando no Linux.\")\n}<\/code><\/pre>\n
swift test<\/code><\/pre>\n
La anotaci\u00f3n @Test<\/code> identifica la prueba y #expect<\/code> compara el resultado. Si cambias el saludo, actualiza la expectativa de forma consciente; un fallo debe provocar una investigaci\u00f3n, no ocultarse. El @testable import<\/code> permite probar la l\u00f3gica interna de este m\u00f3dulo.<\/p>\n
Genera la versi\u00f3n release y haz una prueba r\u00e1pida<\/h2>\n
Dentro de la carpeta que contiene Package.swift<\/code>, compila la configuraci\u00f3n release y ejecuta el resultado:<\/p>\n
swift build -c release\n.build\/release\/OlaLinux Nilton<\/code><\/pre>\n
Una sencilla prueba de salida ayuda a detectar regresiones al modificar este ejemplo:<\/p>\n
test \"$(.build\/release\/OlaLinux Nilton)\" = \"Ol\u00e1, Nilton! Swift est\u00e1 rodando no Linux.\" && echo \"OK\"<\/code><\/pre>\n
Esto es solo una comprobaci\u00f3n b\u00e1sica del programa, no una suite completa de pruebas. En un proyecto m\u00e1s grande, separe la l\u00f3gica en m\u00f3dulos testeables. Para publicar el proyecto en Git, mantenga el c\u00f3digo y el manifiesto; la carpeta de resultados .build\/<\/code> no necesita entrar en el repositorio.<\/p>\n
Alternativa: prueba usando Docker<\/h2>\n
Si Docker ya est\u00e1 instalado, la imagen oficial de Swift<\/a> permite probar sin instalar la toolchain en el host. Este ejemplo fija la versi\u00f3n usada en la revisi\u00f3n y no necesita modo privilegiado:<\/p>\n
docker run --rm swift:6.4.0 swift --version\n\ncd \"$HOME\/projetos\/swift-linuxpro\"\ndocker run --rm \\\n  --mount \"type=bind,source=$PWD,target=\/work,readonly\" \\\n  -w \/work swift:6.4.0 swift hello.swift<\/code><\/pre>\n
El montaje es solo de lectura porque este comando solo ejecuta el script. La primera llamada puede descargar la imagen. Para aprender lo b\u00e1sico de containers, vea tambi\u00e9n el curso de Docker<\/a>.  . No mezcle sin cuidado archivos de build generados en containers con los de su host.<\/p>\n
Editor y problemas comunes<\/h2>\n
En VS Code, instale la extensi\u00f3n Swift y abra la carpeta del proyecto, no solo un archivo suelto. Integra navegaci\u00f3n de c\u00f3digo, depuraci\u00f3n y funciones de pruebas; la gu\u00eda oficial de configuraci\u00f3n<\/a> detalla el entorno. El blog tambi\u00e9n tiene una gu\u00eda de VS Code en Ubuntu<\/a>.<\/p>\n