Swift

There’s no Swift binding for writing niso apps yet: no Swift package, and no Swift classes generated from the WebIDL as the JVM binding has. What exists is the other side: the Apple host is written in Swift and SwiftUI, and calls niso’s C API directly.

Planned: DECISIONS says Swift binds niso “through generated bindings (UniFFI-style) or the C ABI”, and that client bindings for Swift are to be generated from the same WebIDL as the JS glue. None of that is on main.

How the Apple host calls niso

hosts/apple/build.sh compiles the host with swiftc -import-objc-header hosts/apple/Niso-Bridging-Header.h and links libniso_app.a. The bridging header includes three headers, so every C function in them is callable from Swift:

• niso.h, the DOM API generated from the WebIDL (C, Zig and Go describes its conventions);
• niso_js.h, the JS engine for pages;
• niso_app.h, the entry point of an app library (Native apps).

The host’s engine makes a DOM and either runs an app library or evaluates a page’s script, in hosts/apple/Sources/Engine.swift: check(niso_app_main(dom)). From Swift these are plain C calls: strings go in as pointer and length, results come back through inout parameters, and the int32_t status needs checking by hand, as the host’s check helper does.

Writing an app in Swift today

The supported way to build a native Apple app’s UI with niso today is an app library in C, Rust, Zig or Go, passed to hosts/apple/build.sh --app LIB (see Native apps), or a page in JavaScript. Swift code could make the same C calls the host makes, but no example or test on main does that for app code.