{"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\/en\/2017\/05\/instalando-swift-no-linux\/","title":{"rendered":"Swift on Linux: installation, Hello World and first project"},"content":{"rendered":"

\"Mascote<\/p>\n

Note (2026):<\/strong> Originally published in May 2017 for Swift 3.1 on Ubuntu; this guide has been updated in 22 September 2026 for Swift 6.4.0, installed using the official method with Swiftly, keeping the original URL and historical date.<\/div>\n

Want to try Swift on Linux without starting a huge project? Let's install the language using the official swift.org method, run a Hello World, generate a binary, and build a small terminal tool with arguments. The goal is to leave this article with working code and understand the difference between swift<\/code>, swiftc<\/code> and Swift Package Manager.<\/p>\n

<\/p>\n

Before installing: the Swift language is not OpenStack Swift<\/h2>\n

This tutorial is about the programming language. The package called swift in Debian<\/a> belongs to OpenStack, an object storage system. Don't use apt install swift<\/code> as a shortcut to install the compiler from this article: always check the package description.<\/p>\n

Use a distribution and architecture listed in the official Swift installation options on Linux<\/a>. The preparation examples below use Ubuntu\/Debian and Bash. Check your distribution and architecture before starting:<\/p>\n

cat \/etc\/os-release\nuname -m<\/code><\/pre>\n
To start, set aside a folder in your user directory and have internet access. System dependencies require sudo; Swiftly, the toolchain, and compilation commands stay in your user directory and don't require root.<\/p>\n
Install Swift 6.4 with Swiftly<\/h2>\n
Swiftly is the official installer: it downloads the toolchain, verifies its signature, and allows switching between versions. As of the 22\/09\/2026 check, the official page<\/a> indicated Swift 6.4.0<\/strong>, released on 15 September 2026. Prepare the basic tools:<\/p>\n
sudo apt update && sudo apt install -y ca-certificates curl gnupg tar<\/code><\/pre>\n
Download the installer indicated by the site, the signature, and the project keys. The file name uses the machine's architecture (x86_64<\/code> or aarch64<\/code>) and always points to the current version of 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
The output must contain Good signature from \"Swift Automatic Signing Key<\/code>. The warning that the key is not certified by a trusted signature is normal when you have just imported it. If BAD signature<\/code>,  appears, stop: do not extract or run the file. With the signature confirmed, run exactly the command from the official page:<\/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
The init<\/code> downloads a little over 1 GB, checks the signature of the toolchain and sets Swift 6.4.0 as the default. At the end, it prints a command apt-get<\/code> with the dependencies missing from the system. Do not skip this step:<\/strong> on the clean Ubuntu 24.04 we used in the test, swift<\/code> failed with libncurses.so.6: cannot open shared object file<\/code> until we installed the indicated list, which was this:<\/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
On another distribution or version, use the list that your swiftly init<\/code> shows, not this one. Then check:<\/p>\n
swift --version\nswiftc --version<\/code><\/pre>\n
The output should mention Swift version 6.4.0<\/code>. The file env.sh<\/code> adjusts the current session; it init<\/code> also configures your shell for subsequent terminals. The details of each step are in the official guide Getting Started with Swiftly on Linux<\/a>.<\/p>\n
Basic Hello World: one file and one line<\/h2>\n
Start outside the installer folder. Create a study directory and a file named 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
The expected output is:<\/p>\n
Hello, world!<\/code><\/pre>\n
Here, print<\/code> writes a message to standard output. The call swift hello.swift<\/code> runs the file without you manually managing an executable. It's a good approach for small experiments; you don't need to create a package for each test.<\/p>\n
Compile the same program with swiftc<\/h2>\n
Now generate an executable with a defined name:<\/p>\n
swiftc hello.swift -o hello\n.\/hello<\/code><\/pre>\n
The message is the same, but the flow has changed: first you compiled; then you ran it .\/hello<\/code>. When you change the code, run the compiler again to update the binary. The prefix .\/<\/code> indicates that the file is in the current directory.<\/p>\n
A binary compiled on your computer is not automatically compatible with all of Linux. Architecture, libraries, and runtime of the target environment matter. For more controlled distribution, study the Swift SDK for Static Linux<\/a>; this is a step beyond Hello World.<\/p>\n
Create a tool with Swift Package Manager<\/h2>\n
When the code gains more files and dependencies, use the Swift Package Manager, which comes with the toolchain. Instead of managing everything manually, it organizes the manifest and the compilation. Create a new project inside the study directory:<\/p>\n
mkdir OlaLinux\ncd OlaLinux\nswift package init --name OlaLinux --type executable\nswift run OlaLinux<\/code><\/pre>\n
The initial template already prints a greeting. In the Swift 6.4.0 toolchain tested in this review, Package.swift<\/code> is the manifest and Sources\/OlaLinux\/OlaLinux.swift<\/code> is the entry point. Check the structure created by your version before editing files. The official command-line tools guide<\/a> explains this flow.<\/p>\n
Replace the content of Sources\/OlaLinux\/OlaLinux.swift<\/code> with the example below. It accepts a name in the terminal and uses LinuxPro when no argument is given:<\/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
The expected messages are, respectively:<\/p>\n
Ol\u00e1, LinuxPro! Swift est\u00e1 rodando no Linux.\nOl\u00e1, Nilton! Swift est\u00e1 rodando no Linux.<\/code><\/pre>\n
The marker @main<\/code> defines the entry point, which calls main()<\/code>. In this code, let<\/code> declares a value that will not be reassigned. CommandLine.arguments<\/code> contains the process arguments; dropFirst()<\/code> skips the executable name and first<\/code> gets the next item, if it exists. The operator ??<\/code> provides the default value. The function takes a name and returns the message using string interpolation.<\/p>\n
To study the syntax more carefully, follow the official tour of the Swift language<\/a>. For a CLI with options, help, and input validation, the next step is the Swift Argument Parser<\/a>; we don't need to add dependencies for this first greeting.<\/p>\n
Add an automated test<\/h2>\n
The template also created a tests folder. Replace Tests\/OlaLinuxTests\/OlaLinuxTests.swift<\/code> with the example below, which checks the message produced by the function without depending on the terminal output:<\/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
The annotation @Test<\/code> identifies the test and #expect<\/code> checks the result. If you change the greeting, update the expectation consciously; a failure should prompt investigation, not be hidden. The @testable import<\/code> allows testing the internal logic of this module.<\/p>\n
Generate the release version and run a quick test<\/h2>\n
Inside the folder containing Package.swift<\/code>, compile the release configuration and run the result:<\/p>\n
swift build -c release\n.build\/release\/OlaLinux Nilton<\/code><\/pre>\n
A simple output test helps detect regressions when modifying this example:<\/p>\n
test \"$(.build\/release\/OlaLinux Nilton)\" = \"Ol\u00e1, Nilton! Swift est\u00e1 rodando no Linux.\" && echo \"OK\"<\/code><\/pre>\n
This is just a basic check of the program, not a complete test suite. In a larger project, separate the logic into testable modules. To publish the project on Git, keep the code and the manifest; the results folder .build\/<\/code> does not need to go into the repository.<\/p>\n
Alternative: try it using Docker<\/h2>\n
If Docker is already installed, the official Swift image<\/a> allows testing without installing the toolchain on the host. This example pins the version used in the review and does not need privileged mode:<\/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
The mount is read-only because this command only runs the script. The first call may download the image. To learn the basics of containers, see also the Docker course<\/a>. Do not carelessly mix build files generated in containers with those on your host.<\/p>\n
Editor and common issues<\/h2>\n
In VS Code, install the Swift extension and open the project folder, not just a loose file. It integrates code navigation, debugging, and testing features; the official setup guide<\/a> details the environment. The blog also has a guide to VS Code on Ubuntu<\/a>.<\/p>\n