Introduction

Welcome to the SwiftWasm Documentation!

SwiftWasm is an open source project to support the WebAssembly target for Swift.

The goal of this project is to fully support the WebAssembly target for Swift and to be merged into the upstream repository.

WebAssembly is described on its home page as:

WebAssembly (abbreviated as Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

We use LLVM as a compiler backend to produce WebAssembly binaries. Our resulting binaries also depend on WASI, which is a modular system interface for WebAssembly. WASI is mainly required to compile Swift Standard Library.

Getting Started

This is a getting started guide section to use SwiftWasm.

You can learn about:

  • How to set up a Swift toolchain for compiling to WebAssembly
  • How to compile a simple Swift code and Swift Package into WebAssembly
  • How to interoperate with JavaScript

Installation

You can install latest toolchain of SwiftWasm from Release Page

The toolchains can be installed via swiftenv like official nightly snapshot.

Here's an example swiftenv invocation for installing the latest stable SwiftWasm toolchain on macOS Catalina:


$ swiftenv install \
  https://github.com/swiftwasm/swift/releases/download/swift-wasm-5.3-SNAPSHOT-2020-10-02-a/swift-wasm-5.3-SNAPSHOT-2020-10-02-a-osx.tar.gz
$ swift --version
Swift version 5.3-dev (LLVM ba56ef042e, Swift 5855a96018)
Target: x86_64-apple-darwin19.3.0

Hello, World!

This section will show you how to compile a simple Swift code into WebAssembly and run the produced binary on WASI supported WebAssembly runtime.

1. Create a Swift file

$ echo 'print("Hello, world!")' > hello.swift

2. Compile Swift code into WebAssembly with WASI

$ TOOLCHAIN_PATH=$(dirname $(swiftenv which swiftc))/../
$ swiftc \
    -target wasm32-unknown-wasi \
    -sdk $TOOLCHAIN_PATH/share/wasi-sysroot \
    hello.swift -o hello.wasm

3. Run the produced binary on WebAssembly runtime

You can the run the produced binary with wasmer (or other WebAssembly runtime):

$ wasmer hello.wasm

The produced binary depends on WASI which is an interface of system call for WebAssembly. So you need to use WASI supported runtime and when you run the binary on browser, you need WASI polyfill library like @wasmer/wasi.

Compile a SwiftPM package to WebAssembly

You can also use SwiftPM for managing packages in the same way as other platforms.

1. Create a package from template

$ swift package init --type executable
Creating executable package: hello
Creating Package.swift
Creating README.md
Creating .gitignore
Creating Sources/
Creating Sources/hello/main.swift
Creating Tests/
Creating Tests/LinuxMain.swift
Creating Tests/helloTests/
Creating Tests/helloTests/helloTests.swift
Creating Tests/helloTests/XCTestManifests.swift

2. Build the Project into a WebAssembly binary

You need to pass --triple option, which indicates that you are building for the target.

$ swift build --triple wasm32-unknown-wasi

3. Run the produced binary

Just as in the previous section, you can run the produced binary with the wasmer WebAssembly runtime.

$ wasmer ./.build/debug/hello-swiftwasm
Hello, world!

Creating a Browser App

Currently, the Tokamak UI framework is one of the easiest ways to build a browser app with SwiftWasm. It tries to be compatible with the SwiftUI API as much as possible, which potentially allows you to share most if not all code between SwiftWasm and other platforms.

Requirements

Tokamak relies on the carton development tool for development and testing. While you can build Tokamak apps without carton, that would require a lot of manual steps that are already automated with carton.

System Requirements

  • macOS 10.15 and Xcode 11.4 or later.
  • Swift 5.2 or later and Ubuntu 18.04 for Linux users.

Installation

On macOS carton can be installed with Homebrew. Make sure you have Homebrew installed and then run:

brew install swiftwasm/tap/carton

You'll have to build carton from sources on Linux. Clone the repository and run swift build -c release, the carton binary will be located in the .build/release directory after that. Assuming you already have Homebrew installed, you can create a new Tokamak app by following these steps:

  1. Install carton:
brew install swiftwasm/tap/carton

If you had carton installed before this, make sure you have version 0.6.1 or greater:

carton --version
  1. Create a directory for your project and make it current:
mkdir TokamakApp && cd TokamakApp
  1. Initialize the project from a template with carton:
carton init --template tokamak
  1. Build the project and start the development server, carton dev can be kept running during development:
carton dev
  1. Open http://127.0.0.1:8080/ in your browser to see the app running. You can edit the app source code in your favorite editor and save it, carton will immediately rebuild the app and reload all browser tabs that have the app open.

You can also clone the Tokamak repository and run carton dev in its root directory. This will build the demo app that shows almost all of the currently implemented APIs.

JavaScript interoperation

JavaScriptKit is a Swift framework to interact with JavaScript through WebAssembly.

You can use any JavaScript API from Swift with this library. Here's a quick example of JavaScriptKit usage in a browser app:

import JavaScriptKit

let document = JSObject.global.document

var divElement = document.createElement("div")
divElement.innerText = "Hello, world"
_ = document.body.appendChild(divElement)

You can also use JavaScriptKit in SwiftWasm apps integrated with Node.js, as there no assumptions that any browser API is present in the library.

JavaScriptKit consists of a runtime library package hosted on npm, and a SwiftPM package for the API on the Swift side. To integrate the JavaScript runtime automatically into your app, we recommend following the corresponding guide for browser apps in our book.

Use Swift Foundation in your code

The Foundation core library is available in SwiftWasm, but in a limited capacity. The main reason is that the Dispatch core library is unavailable due to the lack of standardized multi-threading support in WebAssembly and SwiftWasm itself. Many Foundation APIs rely on the presence of Dispatch under the hood, specifically file system access and threading helpers. A few other types are unavailable in browsers or aren't standardized in WASI hosts, such as support for sockets and low-level networking, or support for time zone files, and they had to be disabled. These types are therefore absent in SwiftWasm Foundation:

  • FileManager
  • Host
  • Notification
  • NotificationQueue
  • NSKeyedArchiver
  • NSKeyedArchiverHelpers
  • NSKeyedCoderOldStyleArray
  • NSKeyedUnarchiver
  • NSNotification
  • NSSpecialValue
  • Port
  • PortMessage
  • Process
  • ProcessInfo
  • PropertyListEncoder
  • RunLoop
  • Stream
  • Thread
  • Timer
  • UserDefaults

Related functions and properties on other types are also absent or disabled. We would like to make them available in the future as soon as possible, and we invite you to contribute and help us in achieving this goal!

Examples

This section shows you example usage of our toolchain.

Importing function from host environment

You can import a function from host environment using special attribute and linker option.

@_silgen_name("add")
func add(_: Int, _: Int) -> Int

print("2 + 3 = \(add(2, 3))")

You need to compile the Swift code with linker option --allow-undefined.

$ TOOLCHAIN_PATH=$(dirname $(swiftenv which swiftc))/../
$ swiftc \
    -target wasm32-unknown-wasi \
    -sdk $TOOLCHAIN_PATH/share/wasi-sysroot \
    lib.swift -o lib.wasm \
    -Xlinker --allow-undefined

Then, you can inject a host function into the produced WebAssembly binary.

Note that we use env as default import module name. We will add a way to specify module name to import in the near future.

const WASI = require("@wasmer/wasi").WASI;
const WasmFs = require("@wasmer/wasmfs").WasmFs;

const promisify = require("util").promisify;
const fs = require("fs");
const readFile = promisify(fs.readFile);

const main = async () => {
  const wasmFs = new WasmFs();
  // Output stdout and stderr to console
  const originalWriteSync = wasmFs.fs.writeSync;
  wasmFs.fs.writeSync = (fd, buffer, offset, length, position) => {
    const text = new TextDecoder("utf-8").decode(buffer);
    switch (fd) {
      case 1:
        console.log(text);
        break;
      case 2:
        console.error(text);
        break;
    }
    return originalWriteSync(fd, buffer, offset, length, position);
  };

  // Instantiate a new WASI Instance
  let wasi = new WASI({
    args: [],
    env: {},
    bindings: {
      ...WASI.defaultBindings,
      fs: wasmFs.fs,
    },
  });

  const wasmBinary = await readFile("lib.wasm");

  // Instantiate the WebAssembly file
  let { instance } = await WebAssembly.instantiate(wasmBinary, {
    wasi_snapshot_preview1: wasi.wasiImport,
    env: {
      add: (lhs, rhs) => (lhs + rhs),
    }
  });

  wasi.start(instance);
};

main()

If you use SwiftPM package, you can omit linker flag using clang's __atribute__. Please see swiftwasm/JavaScriptKit#91 for more detail info

Exporting function for host environment

You can expose a Swift function for host environment using special attribute and linker option.

@_cdecl("add")
func add(_ lhs: Int, _ rhs: Int) -> Int {
    return lhs + rhs
}

You need to compile the Swift code with linker option --export.

$ TOOLCHAIN_PATH=$(dirname $(swiftenv which swiftc))/../
$ swiftc \
    -target wasm32-unknown-wasi \
    -sdk $TOOLCHAIN_PATH/share/wasi-sysroot \
    lib.swift -o lib.wasm \
    -Xlinker --export=add

Then, you can use the exported function from host environment.

const WASI = require("@wasmer/wasi").WASI;
const WasmFs = require("@wasmer/wasmfs").WasmFs;

const promisify = require("util").promisify;
const fs = require("fs");
const readFile = promisify(fs.readFile);

const main = async () => {
  // Instantiate a new WASI Instance
  const wasmFs = new WasmFs();
  let wasi = new WASI({
    args: [],
    env: {},
    bindings: {
      ...WASI.defaultBindings,
      fs: wasmFs.fs,
    },
  });

  const wasmBinary = await readFile("lib.wasm");

  // Instantiate the WebAssembly file
  let { instance } = await WebAssembly.instantiate(wasmBinary, {
    wasi_snapshot_preview1: wasi.wasiImport,
  });
  // Get the exported function
  const addFn = instance.exports.add;
  console.log("2 + 3 = " + addFn(2, 3))

};

main()

If you use SwiftPM package, you can omit linker flag using clang's __atribute__. Please see swiftwasm/JavaScriptKit#91 for more detail info

Example Projects

You can learn more practical usage of our toolchain in swiftwasm/awesome-swiftwasm

Contribution Guide

Forum posts

Repositories

swiftwasm/swift

The main repository of this project. Forked from apple/swift. We are tracking upstream changes using pull

Branching scheme

  • swiftwasm is the main development branch.
  • main is a mirror of the main branch of the upstream apple/swift repository. This branch is necessary to avoid some issues.
  • swiftwasm-release/5.3 is the branch where 5.3 release of SwiftWasm is prepared.
  • release/5.3 is a mirror of the upstream release/5.3 branch.

swiftwasm/llvm-project

This repository is a fork of apple/llvm-project.

swiftwasm branch is based on swift/main branch of apple/llvm-project.

Please see the AppleBranchingScheme.md document in the upstream repository for more details.

swiftwasm/icu4c-wasi

Build script and patches for building ICU project for WebAssembly. The required changes to build it were merged to the upstream repository.

swiftwasm/wasi-sdk and swiftwasm/wasi-libc

Forked from WebAssembly/wasi-sdk and WebAssembly/wasi-libc.

We fork them to build wasi-sysroot with pthread header. There aren't so many diff from upstream.

How to build toolchain

1. Checkout the project source code.

$ mkdir swiftwasm-source
$ cd swiftwasm-source
$ git clone https://github.com/swiftwasm/swift.git
$ ./swift/utils/update-checkout --scheme wasm --clone

2. Install required dependencies

Before building Swift, please install required dependencies.

# On macOS
$ brew install cmake ninja llvm sccache wasmer
$ ./utils/webassembly/macos/install-dependencies.sh
# On Linux
$ ./utils/webassembly/linux/install-dependencies.sh

3. Build using custom preset options

We support both Linux and macOS to build Swift. You need to select the preset name, sccache path and LLVM tools directory.

# On macOS
$ ./utils/build-script \
        --preset=webassembly-macos-target \
        --preset-file ./utils/webassembly/build-presets.ini  \
        SOURCE_PATH=$(dirname $(pwd)) \
        LLVM_BIN_DIR=/usr/local/opt/llvm/bin \
        C_CXX_LAUNCHER=$(which sccache)
# On Linux
$ ./utils/build-script \
        --preset=webassembly-linux-target \
        --preset-file ./utils/webassembly/build-presets.ini  \
        SOURCE_PATH=$(dirname $(pwd)) \
        LLVM_BIN_DIR=/usr/local/opt/llvm/bin \
        C_CXX_LAUNCHER=$(which sccache)

Or if you want to build whole toolchain, please use ./utils/webassembly/build-toolchain.sh. This script builds compiler, Swift Standard Library for host environment (e.g. macOS or Linux) and target environment (wasm32-unknown-wasi), Foundation and other packages. So it takes longer time than the above script.

$ ./utils/webassembly/build-toolchain.sh

If you want to get more information about build system, please feel free to ask @kateinoigakukun on Twitter or GitHub.

Continuous Integration

We use GitHub Actions to build and run tests continuously. (But jobs without cache takes 2~3 hours to be completed)

Currently (2020/10/4), we only run stdlib tests on Linux CI because the job execution time and storage reached GitHub Actions limits.

References:

Nightly distribution

We distribute latest swiftwasm branch and swiftwasm-release/5.3 branch toolchains at UTC 00:00 everyday. You can check the latest toolchain at GitHub Release Page

Cache

Compilation time of LLVM and the Swift toolchain is very long, so we recommend to cache the artifacts using sccache. The "Getting started" guide from the upstream toolchain provides more details about the use of sccache.

References

Debugging

When you want to debug a WebAssembly binary, wasminspect can help in the investigation if the debugged binary does not rely on integration with JavaScript. We recommend splitting your packages into separate executable targets, most of which shouldn't assume the availability of JavaScript to make debugging easier.

demo