DEV Community: Mikhail Isaev

Duck: DuckDB for Swift. Powerful SQL inside iOS and macOS apps

Mikhail Isaev — Sat, 14 Nov 2026 07:47:39 +0000

Hi, DEV!

I've been working with Swift for many years, and quite a few of my open-source projects grew out of the same simple desire: I want everyday code to be clean, expressive, and pleasant to write.

Back in 2018, that led me to build CodyFire and UIKitPlus. Later came SwifQL, FCM, and a number of other libraries I mostly use in server-side Swift projects.

Over the years, working on the server side also shaped the way I like to work with databases. I got used to PostgreSQL, powerful SQL, and the idea that the database itself can do a large part of the heavy lifting.

At the same time, my own libraries already let me describe tables as ordinary Swift models, build SQL with type-safe key paths, and use declarative result-builder syntax that feels very natural in modern Swift.

Eventually I reached a point where I didn't want to give that up every time I switched back to iOS or macOS development.

Ideally, I wanted to describe models and queries almost the same way regardless of whether the code was running on a server or inside an app, while still having a similarly powerful database engine on the client.

The Swift side of that problem wasn't especially mysterious to me. I already had SwifQL, now SwiftStream/SQL, ideas from Bridges, and a pretty clear picture of what I wanted the code to look like.

Choosing the database engine was much more interesting.

Looking for PostgreSQL for mobile apps

The obvious thought, if you want PostgreSQL-like capabilities on the client, is to try PostgreSQL itself.

The problem is that PostgreSQL was designed as a server database. It expects its own process, its own connection lifecycle, and an architecture very different from what I wanted inside an iOS app.

What I needed was something I could embed directly into the application, much more like SQLite.

I looked at existing projects that tried to bring PostgreSQL to mobile devices, but I didn't find a ready-made option that fit what I wanted. Turning PostgreSQL into a truly comfortable embedded database would require a fairly serious adaptation of the engine and its runtime model, which is a completely different project from the one I wanted to build.

There are, of course, excellent embedded databases already. SQLite is everywhere, and the Swift ecosystem around local persistence includes GRDB, Core Data, SwiftData, and many other approaches.

I have no problem with SQLite. It solves an enormous number of real-world problems extremely well.

What I wanted to explore was something different: a much richer SQL engine, while keeping syntax and capabilities familiar to someone who spends a lot of time with PostgreSQL.

That search eventually led me to DuckDB, and it turned out to be surprisingly close to what I had in mind.

DuckDB is a full relational database that runs directly inside your application process and doesn't require a separate database server. Its SQL dialect is heavily inspired by PostgreSQL, and the engine gives you much more than simple record persistence: complex queries, powerful aggregations, window functions, rich data types, transactions, vectorized execution, and efficient processing of large datasets.

DuckDB was originally designed primarily for analytical workloads, and that distinction matters. It is not a port of PostgreSQL, and I don't consider it a universal replacement for SQLite.

For my use case, though, the combination of an embedded architecture, a powerful SQL engine, and familiar syntax was exactly the kind of foundation I wanted.

DuckDB already has an official Swift client, but it mostly exposes fairly basic engine interaction. I wanted a much richer API that would make proper use of modern Swift and feel as pleasant as the database code I was already used to writing on the server.

So I took SwiftStream/SQL, brought over ideas from Bridges, added models, Codable, async/await, migrations, transactions, and the other pieces I wanted around it, and gradually built a higher-level Swift layer on top of DuckDB.

That became Duck, which recently reached its first stable release.

Under the hood it uses real DuckDB 2.0.0, while the Swift layer tries to preserve the style of database code I wanted from the beginning.

Models and everyday data access

Let's start with an ordinary model:

import Duck
import Foundation

struct Todo: Table {
    @Column("id") var id: UUID
    @Column("name") var name: String
    @Column("created_at") var createdAt: Date
    @Column("done_at") var doneAt: Date?
    @Column("deleted_at") var deletedAt: Date?

    init() {}

    init(
        id: UUID = UUID(),
        name: String,
        createdAt: Date = Date(),
        doneAt: Date? = nil,
        deletedAt: Date? = nil
    ) {
        self.id = id
        self.name = name
        self.createdAt = createdAt
        self.doneAt = doneAt
        self.deletedAt = deletedAt
    }
}

If you've used some of my SQL libraries before, this should look fairly familiar.

Todo is just a Swift structure conforming to Table, while @Column connects its properties to database columns and gives us typed references we can later use in queries.

Duck uses DatabaseIdentifier, so we don't need to manually open a connection for every small operation.

For example, we can define a database stored in Application Support:

private var appDatabaseDirectory: URL {
    FileManager.default
        .urls(
            for: .applicationSupportDirectory,
            in: .userDomainMask
        )[0]
}

extension DatabaseIdentifier {
    static var app: Self {
        Self(
            path: appDatabaseDirectory
                .appendingPathComponent("Todos.duckdb")
                .path
        )
    }
}

Creating a DatabaseIdentifier does not immediately open a native connection. It identifies the logical database, while the required resources are created when operations actually need them.

After the schema exists, inserting a model is straightforward:

let todo = Todo(name: "Write a DEV article")

try await todo.insertNonReturning(on: .app)

Or, if we want the inserted model back:

let inserted = try await todo.insert(on: .app)

Updating works with the changed model fields:

var updated = inserted
updated.doneAt = Date()

updated = try await updated.update(
    on: \.$id,
    on: .app
)

And reading the whole table can be as short as:

let todos = try await Todo.all(on: .app)

None of this is a reason by itself to use DuckDB. A Todo app obviously doesn't need a serious analytical database engine.

The point is that I didn't want a powerful engine to make simple application code unnecessarily complicated.

When the query becomes more interesting, the rest of the stack is already there.

The SQL I wanted on the client too

One of my favorite parts of Duck is that query construction uses SwiftStream/SQL directly, so the way I work with SQL on the server and on the client can stay very close.

Suppose we want all non-deleted Todo items ordered by creation date:

let todos = try await Todo
    .query
    .where(Todo.$deletedAt == nil)
    .orderBy(.asc(Todo.$createdAt))
    .all(on: .app)

Duck already knows that the result should become [Todo], because the query originates from the model.

But the form I personally enjoy more is the declarative one:

let query = SQL {
    Select {
        \Todo.$id
        \Todo.$name
        \Todo.$createdAt
        \Todo.$doneAt
        \Todo.$deletedAt
    }

    From(Todo.table)

    Where {
        \Todo.$deletedAt == nil
    }

    OrderBy {
        OrderByItem.asc(\Todo.$createdAt)
    }
}

let todos = try await query.all(
    decoding: Todo.self,
    on: .app
)

This is still regular SQL in terms of structure. Instead of manually building a string, we describe the query through a Swift Result Builder.

Swift can keep column references typed, while dynamic values are passed through prepared bindings.

This gets even nicer once the query starts depending on normal Swift logic:

let includeCompleted = false

let query = SQL {
    Select {
        \Todo.$id
        \Todo.$name
        \Todo.$createdAt
        \Todo.$doneAt
        \Todo.$deletedAt
    }

    From(Todo.table)

    Where {
        \Todo.$deletedAt == nil

        if !includeCompleted {
            \Todo.$doneAt == nil
        }
    }

    OrderBy {
        OrderByItem.asc(\Todo.$createdAt)
    }
}

The same DSL can be used for JOINs, grouping, aggregates, subqueries, and more complex SQL without switching to another query system once the application becomes more complicated.

Reusing queries and query fragments

Another part of SwiftStream/SQL that I especially like is that queries can be composed from reusable Swift values.

For example, we can move our Todo filtering logic into its own type:

struct TodoFilter: SQLQuery {
    let includeCompleted: Bool

    var query: Query {
        Where {
            \Todo.$deletedAt == nil

            if !includeCompleted {
                \Todo.$doneAt == nil
            }
        }
    }
}

Then use the same filter in a regular SELECT:

let query = SQL {
    Select(\Todo.$id, \Todo.$name)
    From(Todo.table)
    TodoFilter(includeCompleted: false)
    OrderBy(.asc(\Todo.$createdAt))
}

And reuse it again in a count query:

let query = SQL {
    Select(Fn.count(\Todo.$id) => "count")
    From(Todo.table)
    TodoFilter(includeCompleted: false)
}

A complete query can be extracted the same way:

struct TodosQuery: SQLQuery {
    let includeCompleted: Bool

    var query: Query {
        Select {
            \Todo.$id
            \Todo.$name
            \Todo.$createdAt
            \Todo.$doneAt
            \Todo.$deletedAt
        }

        From(Todo.table)
        TodoFilter(includeCompleted: includeCompleted)
        OrderBy(.asc(\Todo.$createdAt))
    }
}

Now it can be reused from different parts of the application:

let todos = try await TodosQuery(
    includeCompleted: false
).all(decoding: Todo.self, on: .app)

What I like here is that composition doesn't require another abstraction layer.

Whole queries, query fragments, and ordinary SQL expressions are all just Swift values that can be combined.

Codable doesn't mean SELECT *

You also don't need to load the entire table just because you want Codable decoding.

Suppose a screen only needs id and name:

struct TodoSummary: Decodable {
    let id: UUID
    let name: String
}

We can select exactly those columns:

let summaries = try await Todo
    .select(\.$id, \.$name)
    .where(\Todo.$deletedAt == nil)
    .all(
        decoding: TodoSummary.self,
        on: .app
    )

The same works with arbitrary SQL results.

For example, an aggregate result can be decoded into a dedicated type:

struct TodoCount: Decodable {
    let count: Int64
}

let query = SQL {
    Select(
        Fn.cast(Fn.count(\Todo.$id), .bigint) => "count"
    )
    From(Todo.table)
    Where(\Todo.$deletedAt == nil)
}

let count = try await query.first(
    decoding: TodoCount.self,
    on: .app
)?.count ?? 0

Codable isn't dictating what query you're allowed to write.

You define the SQL you need, select the fields you care about, and decode the result into an appropriate Swift type. If you need full control, QueryResult and ResultRow are still available directly.

Migrations and transactions

We've already been using Todo, but obviously the database needs the corresponding schema.

I wanted to keep the migration model close to what I'm used to on the server:

extension Todo {
    struct Create: Migration {
        let name = "Todo.Create"

        var up: MigrationPlan {
            CreateTable("todo") {
                NewColumn("id", .uuid).primaryKey()
                NewColumn("name", .text).notNull()
                NewColumn("created_at", .timestamptz).notNull()
                NewColumn("done_at", .timestamptz)
                NewColumn("deleted_at", .timestamptz)
            }
        }

        var down: MigrationPlan {
            DropTableBuilder<Todo>()
        }
    }
}

During application setup:

try FileManager.default.createDirectory(
    at: appDatabaseDirectory,
    withIntermediateDirectories: true
)

_ = try await DatabaseIdentifier.app
    .migrator([Todo.Create()])
    .migrate()

Duck keeps migration history and only applies migrations that haven't been executed yet. There is support for up, down, batches, and additional work inside migrations.

Transactions are similarly explicit:

let connection = try await DatabaseIdentifier.app.connect()

try await connection.transaction { transaction in
    let first = Todo(name: "First")
    let second = Todo(name: "Second")

    try await first.insertNonReturning(on: transaction)
    try await second.insertNonReturning(on: transaction)
}

If the closure completes successfully, Duck commits. If it throws or the task is cancelled, the transaction rolls back.

There is also an explicit connection.transaction() form for cases where the transaction lifetime cannot comfortably fit inside one closure. In that case, the caller owns finalization and must call commit() or rollback() explicitly.

A few more DuckDB features

The previous examples are enough for ordinary model-based application work, but the more interesting parts of DuckDB become visible once the data gets larger or the schema becomes richer.

Native LIST values

DuckDB supports a native LIST type, which means Swift arrays don't necessarily need to be serialized into JSON first.

For example:

struct User: Table {
    static let tableName = "users"

    @Column("id") var id: Int64
    @Column("tags") var tags: [String]

    init() {}

    init(id: Int64, tags: [String]) {
        self.id = id
        self.tags = tags
    }
}

The corresponding column can be created as a real DuckDB LIST:

NewColumn("tags", .list(.varchar)).notNull()

And the regular model API continues to work:

let user = User(
    id: 1,
    tags: ["swift", "duckdb"]
)

let inserted = try await user.insert(on: .app)

let loaded = try await User
    .query
    .where(\User.$id == inserted.id)
    .first(on: .app)

The first stable version currently supports one-dimensional LIST values and one immediate keyed STRUCT level.

More complex recursive combinations are still future work.

Bulk insertion

DuckDB can load large amounts of data efficiently through its Appender API, and I wanted that to be available both through model-level conveniences and a lower-level interface.

For an ordinary collection:

let todos = [
    Todo(name: "One"),
    Todo(name: "Two"),
    Todo(name: "Three")
]

try await todos.batchInsert(on: .app)

Or directly through Appender:

let todoTable = DB.Table(Todo.tableName)
let connection = try await DatabaseIdentifier.app.connect()

try await connection.appender(
    to: todoTable,
    columns: ["id", "name", "created_at"]
) { appender in
    for name in importedTodoNames {
        try await appender.append(
            UUID(),
            name,
            Date()
        )
    }
}

If the entire import should participate in one transaction, the same idea works through transaction.appender.

Reusable prepared statements are available as well when you want to prepare the same SQL shape once and execute it repeatedly with different parameters.

This ability to move gradually from a very small model API to lower-level DuckDB tools is one of the parts I care about most.

The simple code can stay simple, while more demanding workloads don't force you to replace the entire database stack.

Reactive SQL queries for SwiftUI and UIKit

Another feature I wanted on the client side was the ability to observe the result of a SQL query directly.

Suppose a SwiftUI screen has an ordinary Todo list:

@State private var todos: [Todo] = []

With Duck, the query itself can become an observation:

.task {
    do {
        for try await result in try Todo
            .select
            .where(Todo.$deletedAt == nil)
            .orderBy(.asc(Todo.$createdAt))
            .observe(on: .app)
        {
            todos = try result.all(decoding: Todo.self)
        }
    } catch is CancellationError {
        // SwiftUI cancelled the task
    } catch {
        print("Duck error:", error)
    }
}

This is implemented as a regular AsyncSequence<QueryResult>.

Duck itself doesn't depend on SwiftUI, so the same sequence can be consumed from UIKit, a command-line application, or any other Swift code.

When the Task is cancelled, cancellation propagates into the observation, the worker stops, and the subscription is released.

Observation is intentionally a latest-state abstraction rather than a log of every database event. Multiple invalidations can be coalesced, and identical QueryResult values are not published repeatedly.

There is also an important boundary: observation reacts to mutations routed through the same logical DatabaseIdentifier inside the process. It is not a filesystem watcher and it is not a cross-process synchronization mechanism.

Observation efficiency

After the release, I got a good question: how precisely does Duck determine whether a data change can actually affect a particular observed query?

In Duck 1.0, invalidation is deliberately conservative. Even a mutation to a completely unrelated table can currently cause a query to run again. Duck suppresses identical results before delivering them to the consumer, but the extra SQL execution has still happened.

Since I plan to use Duck myself in an application with millions of rows and a very high number of write operations, more precise invalidation is already planned for 1.1, including predicate-aware optimizations and dedicated high-load benchmarks on generated million-row datasets.

Concurrency and connection pooling

For workloads involving several concurrent tasks, Duck provides a connection pool:

let pool = try await DatabaseIdentifier.app
    .pool(maximumConnections: 4)

A connection can be borrowed for the duration of a closure:

let todos = try await pool.connection { connection in
    try await Todo
        .query
        .where(\Todo.$deletedAt == nil)
        .all(on: connection)
}

Connections are created lazily up to the configured limit.

Each Connection is an actor and owns its own native DuckDB connection.

That means work on a single connection is serialized through that ownership, while independent connections don't need to pass through one global execution queue.

Transactions can also be run directly through the pool:

try await pool.transaction { transaction in
    let todo = Todo(name: "Inserted through pool")
    try await todo.insertNonReturning(on: transaction)
}

I wanted Swift Concurrency here to reflect the real ownership and lifetime of the native database resources, rather than simply adding async methods around an opaque global lock.

Will Duck replace SQLite?

I don't think so, and that isn't the goal.

SQLite is an excellent embedded database, and GRDB provides a great Swift API around it. If an application is mostly doing ordinary CRUD and SQLite already solves the problem well, I don't see a reason to replace that stack just for the sake of replacing it.

Duck becomes more interesting to me when I want a more powerful SQL engine inside the application, with the kinds of capabilities I am used to on the server side.

At the same time, DuckDB is primarily designed around analytical queries and relatively large data operations. If your workload consists of huge numbers of tiny transactions and constant point updates, performance should be measured against your actual use case rather than assumed from either PostgreSQL or SQLite.

There is also the question of application size.

I built two minimal SwiftUI apps locally. The empty application was about 2 MB, while the same app with Duck was about 42 MB.

Those are local build sizes. I have not yet measured the real compressed and thinned App Store download size.

Personally, those numbers don't bother me. Plenty of modern apps are already hundreds of megabytes, and getting a full DuckDB engine inside the application for roughly that cost is acceptable for the kinds of projects I have in mind.

If app size is critical and SQLite already does everything you need, the additional weight of DuckDB may make no sense at all.

Trying it

Duck is available through Swift Package Manager:

.package(
    url: "https://github.com/SwiftStream/Duck",
    from: "1.0.0"
)

Then:

import Duck

SwiftStream/SQL is re-exported by Duck, so a normal application target does not need to import SQL separately.

The package currently supports:

iOS 15+
macOS 12+

The DuckDB engine itself works on many more platforms. I haven't validated all of them through Duck yet, although I expect more environments to be fairly straightforward.

On Apple platforms, DuckDB is distributed as a prebuilt XCFramework, so Xcode does not have to recompile the whole C++ engine during a normal application build.

In my current setup, that saves roughly 2 to 3 minutes on a cold build, while the minimal SwiftUI application itself compiles in about 10 seconds.

The repository also includes ready-to-run SwiftUI and UIKit examples covering models, migrations, queries, persistence, and reactive UI updates.

Conclusion

Duck is still at the beginning of its development, although the first stable release already contains a large part of what I originally wanted from a modern Swift database layer.

DuckDB itself exposes a huge amount of functionality, and there is still plenty to bring into a good Swift API. Besides improving reactive observation performance, I want to expand native type support, validate more platforms, and continue filling in the parts of the engine that make sense for application development.

The part I'm happiest with is that I can now move between server-side Swift and an iOS app without completely changing how I think about models and SQL.

One part of the application can simply do this:

let todos = try await Todo.all(on: .app)

while another part can use the same SwiftStream/SQL stack for queries involving several tables, conditions, aggregations, and reusable fragments.

Both remain part of the same approach to working with data.

I hope Duck is useful to other Swift developers who enjoy SQL, want to experiment with DuckDB inside their applications, or are simply looking for a different way to work with substantial amounts of local data.

I'd especially like to hear from people already using DuckDB or working with large local databases on iOS and macOS.

Duck is open source and released under the MIT license.

You can find the source, try the examples, and star the project here:

SwiftStream/Duck on GitHub

If you find the project or this article useful, sharing it with other Swift developers helps a lot.

You're also very welcome to join the Swift Stream community on Discord and Telegram.

Mikhail Isaev

Founder of Swift Stream

Swift on Android: JNIKit 2.11.0: Automatic Memory & 2D Arrays

Mikhail Isaev — Mon, 27 Oct 2025 02:27:59 +0000

The ecosystem for Swift on Android just got a significant upgrade with the release of JNIKit 2.11.0. This library simplifies JNI interaction, and this latest version focuses on two major pain points: robust memory management and expanded data structure support.

Automatic Memory Control

The days of manually managing JNI references are over.

JObject now automatically deletes its underlying jobject on deinit.
This logic has been extended to JClass, JClassLoader, and JObjectArray.
Key Takeaway: You can now rely entirely on Swift's deinit for memory management. No more manual deletion or worrying about reference leaks.

Note for Upgraders: This is a breaking change if you previously handled memory manually. Also, the internal method env.callObjectMethodPure has been updated—check the release notes if you use it directly.

1D & 2D Array Support

Working with Java arrays is now more Swift-like than ever.

1D Arrays (e.g., [Int8], [Float], [Double]):

Easy initialization from a Swift Array: JIntArray([1, 2, 3])
Efficient iteration to avoid copying large arrays:

for value in intArray {
    Log.d("value: \(value)")
}

New: 2D Array Support! 🎉 (e.g., [[Int32]], [[Double]])
This is crucial for many Android APIs (like ColorStateList).

Initialize directly from a nested Swift array: JIntArray2D([[1, 2, 3], [4, 5, 6]])
Iterate or convert back to a Swift array with ease.

Passing arrays to Java methods is now trivial:

// No need to manually create wrapper objects
object.callVoidMethod(name: "send1DArray", args: [1, 2, 3])
object.callVoidMethod(name: "send2DArray", args: [[1, 2, 3], [4, 5, 6]])

Enhanced Debugging

Logging for global reference creation/deletion has been greatly improved, making it easier to trace memory issues during development.

The Swift Android Setup I Always Wanted

Mikhail Isaev — Fri, 12 Sep 2025 01:25:14 +0000

Hi guys, imike here!!!

Swift 6's game-changing Android NDK support finally let me ship JNIKit, the convenient tool I've been building for the SwifDroid project since the Swift 5 days! The biggest hurdle is now gone: we can simply import Android instead of wrestling with manual header imports. While the final step, official binary production, is still handled by finagolfin's fantastic swift-android-sdk (which Swift Stream uses), the Swift project is already planning to make it the official SDK.

Today, I want to show you how to write your first real native Swift code for Android. It's going to be an interesting journey, so grab a cup of tea and let's begin.

What You'll Need:

Docker
VSCode with Dev Containers extension
The Swift Stream IDE extension for VSCode

Optionally, have Android Studio installed to test your library with a real Android app later.

Your operating system doesn't matter as long as it can run Docker and VSCode.

Once you have Docker installed, open VSCode.

First, make sure you have the Dev Containers extension installed.

Next, ensure the Swift Stream IDE extension is also installed.

If you don't have these extensions yet, just search for them in the marketplace and hit Install (your Captain Obvious 😄)

Creating a New Project

On the left sidebar in VSCode, click the Swift Stream icon (the bird).

...and hit Start New Project 😏

Now, enter your project name, for example, MyFirstAndroidLib.

You'll see that the new project will be created in your home folder by default. You can choose a different folder by clicking the three-dots button.

The next step is to choose the project type. For us, it's Android -> Library.

Click Create Project.

Next, enter the Java namespace for your library. This is usually your domain name in reverse (e.g., com.example.mylib).

After entering the namespace, hit Enter to move to the next step, where you'll choose the Android Min SDK Version.

I'd recommend choosing 24 or 29, depending on your needs. Hit Enter again to choose the Android Compile SDK Version.

As of today, 35 is a good choice. Hit Enter one more time to start the project creation process.

At this point, VSCode will create a folder with all the project files and begin downloading the Docker image with a ready-to-use Android development environment.

Once the image is downloaded, it will start the container and open a new VSCode window with your project inside it. The container will then download the Swift toolchain, Swift for Android SDK, Gradle, Android NDK, and Android SDK. These tools are cached on shared Docker volumes, so your next project will be created in seconds. However, this first launch might take some time, so please be patient.

And you're all set! Ready to write some code!

Preambula

What is JNI

The Java Native Interface (JNI) is a bridge that lets native code talk to the Java Virtual Machine. Here’s the deal: if you're writing Java code, you use the Android SDK. But if you're using a language like Swift or C++ that doesn't compile to Java Bytecode, you need the Android NDK to communicate with Java through JNI.

Using JNI, you can do pretty much anything you can do in Java, the real challenge is doing it in a way that isn't a total headache.

What is JNIKit

This is where JNIKit comes in! To feel comfortable and stay productive, we need a convenient layer that wraps those low-level, C-style JNI calls into something much more elegant and Swifty. That’s exactly what JNIKit is for.

The Project

Structure

At its heart, it's a pure Swift Package Manager project. The key dependencies are JNIKit, and AndroidLogging with swift-log.

Your Swift code lives in Sources/<target_name>/Library.swift by default.

The Android library (a Gradle project) is in the Library folder. This folder will be automatically generated after your first Swift build. Alternatively, you can create it manually from the Swift Stream sidebar panel.

The Swift Code

Everything starts with an initialize method. This method is exposed to the Java/Kotlin side and must be called before any other native methods.

The following code shows how to use @_cdecl to expose this method for JNI.

The @_cdecl naming convention is critical, as it follows the JNI pattern:

Java_<package>_<class>_<method>

package is the fully qualified package name with underscores instead of dots
class is the class name
method is the method name

The method's arguments also follow JNI convention. The first two are required and are passed automatically by the JNI:

envPointer: This never changes. It's a pointer to the JNI environment, your main interface for interacting with the JVM.
clazzRef or thizRef: You get clazzRef if the Java method is static (like in our case, where the method is inside a Kotlin object). You get thizRef if it's an instance method. The first is a pointer to a class; the second is a pointer to an instance.

Any arguments after these represent the parameters of the Java/Kotlin method itself. In our case, the method has one extra argument: a caller object. We pass this from the app to provide context. This caller instance is necessary to cache the app's class loader (more on that later). Note: if we had thizRef instead of clazzRef, we might not need to pass this extra caller object.

#if os(Android)
@_cdecl("Java_to_dev_myandroidlib_myfirstandroidproject_SwiftInterface_initialize")
public func initialize(
    envPointer: UnsafeMutablePointer<JNIEnv?>,
    clazzRef: jobject,
    callerRef: jobject
) {
    // Activate Android logger
    LoggingSystem.bootstrap(AndroidLogHandler.taggedBySource)
    // Initialize JVM
    let jvm = envPointer.jvm()
    JNIKit.shared.initialize(with: jvm)
    // ALSO: class loader cache example
    // ALSO: `toString` example
    // ALSO: `Task` example
}
#endif

The method body shows we first bootstrap the Swift logging system with the Android logger (this only needs to be done once).

After that, we can use the logger anywhere, simply like this:

let logger = Logger(label: "🐦‍🔥 SWIFT")
logger.info("🚀 Hello World!")

Then, we initialize the connection to the JVM. At this point, we're good to go!

Class Loader and Cache

Here's a common gotcha: by default, when you try to find a Java class via JNI, it uses a system class loader. This system loader (surprise, surprise!) can't see dynamically loaded classes from your app, meaning it misses your own classes and any Gradle dependencies.

The solution? We need to get the application's class loader, which is available from any Java object via .getClass().getClassLoader(). The best practice is to grab this class loader once during initialization, create a global reference to it, store it in JNIKit's cache, and use it everywhere. It remains valid for the entire app lifecycle.

Here’s how to cache it in the initialize method:

// Access current environment
let localEnv = JEnv(envPointer)
// Convert caller's local ref into global ref
let callerBox = callerRef.box(localEnv)
// Defer block to clean up local references
defer {
    // Release local ref to caller object
    localEnv.deleteLocalRef(callerRef)
}
// Initialize `JObject` from boxed global reference to the caller object
guard let callerObject = callerBox?.object() else { return }
// Cache the class loader from the caller object
// it is important to load non-system classes later
// e.g. your own Java/Kotlin classes
if let classLoader = callerObject.getClassLoader(localEnv) {
    JNICache.shared.setClassLoader(classLoader)
    logger.info("🚀 class loader cached successfully")
}

Note: You would use thizRef instead of callerRef if your native method was an instance method.

Can I use Java's `toString()`?

Yup, of course! It's a crucial Java method, and JNIKit makes using it as simple as:

logger.info("🚀 caller description: \(someObject.toString())")

Environment on Another Thread

JNIEnv is tied to the current thread. This environment is the bridge that does all the magic, transferring calls to and from the JVM.

If you switch threads (e.g., in a Task), you must attach a JNI environment to that new thread. JNIKit provides a simple method for this: JEnv.current().

Task {
    // Access current environment in this thread
    guard let env = JEnv.current() else { return }
    logger.info("🚀 new env: \(env)")
    // Print JNI version into LogCat
    logger.info("🚀 jni version: \(env.getVersionString())")
}

How the Code Looks on the Other Side

Java

public final class SwiftInterface {
    static {
        System.loadLibrary("MyFirstAndroidProject");
    }
    private SwiftInterface() {}
    public static native void initialize(Object caller);
}

Kotlin

object SwiftInterface {
    init {
        System.loadLibrary("MyFirstAndroidProject")
    }
    external fun initialize(caller: Any)
}

Swift Stream generates the Kotlin files for you, so we'll stick with that. We'll see more JNI examples in a bit 🙂

Building the Swift Project

Alright, time to build! Switch to the Swift Stream tab on the left sidebar and hit Project -> Build.

You'll be prompted to choose a Debug or Release scheme.

Let's go with Debug for now. The building process will begin.

In Swift Stream, you can choose the Log Level to control how much detail you see:

Normal
Detailed (This is the default)
Verbose
Unbearable (For when you really need to see everything)

With the default Detailed level, you'll see an output similar to this during the build:

🏗️ Started building debug
💁‍♂️ it will try to build each phase
🔦 Resolving Swift dependencies for native
🔦 Resolved in 772ms
🔦 Resolving Swift dependencies for droid
🔦 Resolved in 2s918ms
🧱 Building `MyFirstAndroidProject` swift target for arm64-v8a
🧱 Built `MyFirstAndroidProject` swift target for `.droid` in 10s184ms
🧱 Building `MyFirstAndroidProject` swift target for armeabi-v7a
🧱 Built `MyFirstAndroidProject` swift target for `.droid` in 7s202ms
🧱 Building `MyFirstAndroidProject` swift target for x86_64
🧱 Built `MyFirstAndroidProject` swift target for `.droid` in 7s135ms
🧱 Preparing gradle wrapper
🧱 Prepared gradle wrapper in 1m50s
✅ Build Succeeded in 2m20s

As you can see, the initial Swift compilation itself was pretty fast, about ~30 seconds total for all three architecture targets (arm64-v8a, armeabi-v7a, and x86_64). The bulk of the time (1m50s) was spent on the initial gradle wrapper setup, which is a one-time cost.

The great news is that subsequent builds will be super fast, taking only about 3 seconds for all three targets! This is because everything gets cached.

This build command also automatically generates the Java Library Gradle project for you. It's now ready to use in the Library folder.

The Java/Kotlin Project

Source Code

Swift Stream generates the initial boilerplate code for your library, which you'll then maintain and extend.

Here’s a sample of the generated Kotlin interface:

import android.util.Log

object SwiftInterface {
    init {
        System.loadLibrary("MyFirstAndroidProject")
    }

    external fun initialize(caller: Any)

    external fun sendInt(number: Int)
    external fun sendIntArray(array: IntArray)
    external fun sendString(string: String)
    external fun sendDate(date: Date)
    external fun ping(): String
    external fun fetchAsyncData(): String
}

Gradle Files

Swift Stream IDE automatically manages your Gradle project. It generates Java packages based on your Swift targets from Package.swift and keeps all the Gradle files in sync.

In Library/settings.gradle.kts, it manages the list of included targets within special comment tags:

// managed by swiftstreamide: includes-begin
include(":myfirstandroidproject")
// managed by swiftstreamide: includes-end

In each Library/<target>/build.gradle.kts file, it automatically manages dependencies based on the imports in your Swift code and the Swift version you're using:

implementation("com.github.swifdroid.runtime-libs:core:6.1.3")
// managed by swiftstreamide: so-dependencies-begin
implementation("com.github.swifdroid.runtime-libs:foundation:6.1.3")
implementation("com.github.swifdroid.runtime-libs:foundationessentials:6.1.3")
implementation("com.github.swifdroid.runtime-libs:i18n:6.1.3")
// managed by swiftstreamide: so-dependencies-end

By default, these dependencies are fetched automatically from the SwifDroid runtime-libs JitPack repository, which is maintained for each supported Swift version. This means no manual copying of .so files from the Android SDK bundle!

But if you need more control, you can take over manually, still without the hassle of manual file copying. The Swift Stream IDE uses a configuration file (.vscode/android-stream.json) where you can set the soMode:

"soMode": "Packed"

"Packed" (the default) means Gradle imports everything from JitPack. You can switch to "PickedManually" to specify only the .so files you actually need:

"soMode": "PickedManually",
"schemes": [
    {
        "title": "MyFirstAndroidProject Debug",
        "soFiles": [
            "libandroid.so",
            "libc.so",
            "libm.so"
        ]
    }
]

This config file is also where you control other key project settings:

"packageName": "to.dev.myandroidlib",
"compileSDK": 35,
"minSDK": 24,
"javaVersion": 11,

You can even pass custom arguments directly to the Swift compiler for fine-grained control:

"schemes": [
    {
        "title": "MyFirstAndroidProject Debug",
        "swiftArgs": []
    }
]

Assemble with Gradle

Finally, to build the distributable Android library files (.aar), just hit Java Library Project -> Assemble in the Swift Stream sidebar.

This command runs either gradlew assembleDebug or gradlew assembleRelease in the background, packaging everything up for distribution.

Add This Library to Your Android Project (Locally)

Now for the fun part, let's use this library in a real Android app! Open your existing project or create a new one in Android Studio.

Once your project is open, the first step is to add JitPack as a repository. Navigate to your settings.gradle.kts file and make sure it includes the JitPack repository:

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        maven { url = uri("https://jitpack.io") }
        mavenCentral()
    }
}

Next, you need to add the dependencies to your app module's build.gradle.kts file (app/build.gradle.kts). You must include both the .aar file and all the necessary runtime libraries:

dependencies {
    implementation(files("libs/myfirstandroidproject-debug.aar"))
    implementation("com.github.swifdroid.runtime-libs:core:6.1.3")
    implementation("com.github.swifdroid.runtime-libs:foundation:6.1.3")
    implementation("com.github.swifdroid.runtime-libs:foundationessentials:6.1.3")
    implementation("com.github.swifdroid.runtime-libs:i18n:6.1.3")
    // the rest of dependencies
}

Important: You have to manually list these dependencies because Android can't automatically pick them up from inside the .aar file.

Getting the .AAR File

Now, grab your freshly built library file! You'll find the .aar file in your Swift Stream project at this path:

Library/myfirstandroidproject/build/outputs/aar/myfirstandroidproject-debug.aar

Copy this file. Then, in your Android Studio project, navigate to your app module's directory (e.g., app/) and create a folder named libs right next to the build.gradle.kts file. Paste the .aar file into this new libs folder.

Let the Magic Begin! 🚀

You're all set! Now, somewhere in your app, typically in your Application class or the onCreate of your main activity, initialize the Swift code:

SwiftInterface.initialize(this)

Sync your Gradle project, build it, and run it on a device or emulator.

The moment of truth: Open LogCat and filter for "SWIFT". You should see our glorious message:

 I  [🐦‍🔥 SWIFT] 🚀 Hello World!

Yaaay! Your Swift code is now running on Android.

The Development Loop

When you make changes to your Swift code, here’s your quick update cycle:

In Swift Stream, hit Project -> Build
Then, hit Java Library Project -> Assemble
Copy the new .aar file from the outputs/aar folder into your Android project's app/libs folder, replacing the old one.
Rebuild and run your Android app!

That's it! You're now a cross-platform Swift developer.

JNI Examples

Now for the most exciting part, the code! Let's talk about how to communicate between Swift and Java/Kotlin. We'll stick with Kotlin, as it's the standard for Android development today.

We'll cover a few simple but common scenarios in this article and dive into more complex ones next time.

⚠️ Crucial: Don't forget to call SwiftInterface.initialize(this) before any other native calls!

Sending an `Int` from Kotlin to Swift

Let's start simple. Declare a method in SwiftInterface.kt:

external fun sendInt(number: Int)

On the Swift side, implement it:

#if os(Android)
@_cdecl("Java_to_dev_myandroidlib_myfirstandroidproject_SwiftInterface_sendInt")
public func sendInt(
    envPointer: UnsafeMutablePointer<JNIEnv?>,
    clazzRef: jobject,
    number: jint
) {
    let logger = Logger(label: "🐦‍🔥 SWIFT")
    logger.info("#️⃣ sendInt: \(number)")
}
#endif

Call it from your app:

SwiftInterface.sendInt(123)

Check LogCat:

 I  [🐦‍🔥 SWIFT] #️⃣ sendInt: 123

Too easy, right? :)

Sending an `IntArray` from Kotlin to Swift

Declare the method:

external fun sendIntArray(array: IntArray)

On the Swift side, handle the array:

#if os(Android)
@_cdecl("Java_to_dev_myandroidlib_myfirstandroidproject_SwiftInterface_sendIntArray")
public func sendIntArray(
    envPointer: UnsafeMutablePointer<JNIEnv?>,
    clazzRef: jobject,
    arrayRef: jintArray
) {
    // Create lightweight logger object
    let logger = Logger(label: "🐦‍🔥 SWIFT")
    // Access current environment
    let localEnv = JEnv(envPointer)
    // Defer block to clean up local references
    defer {
        // Release local ref to array object
        localEnv.deleteLocalRef(arrayRef)
    }
    // Get array length
    logger.info("🔢 sendIntArray 1")
    let length = localEnv.getArrayLength(arrayRef)
    logger.info("🔢 sendIntArray 2 length: \(length)")
    // Get array elements
    var swiftArray = [Int32](repeating: 0, count: Int(length))
    localEnv.getIntArrayRegion(arrayRef, start: 0, length: length, buffer: &swiftArray)
    // Now you can use `swiftArray` as a regular Swift array
    logger.info("🔢 sendIntArray 3 swiftArray: \(swiftArray)")
}
#endif

Call it from your app:

SwiftInterface.sendIntArray(intArrayOf(7, 6, 5))

Check LogCat:

 I  [🐦‍🔥 SWIFT] 🔢 sendIntArray: 1
 I  [🐦‍🔥 SWIFT] 🔢 sendIntArray: 2 length: 3
 I  [🐦‍🔥 SWIFT] 🔢 sendIntArray: 3 swiftArray: [7, 6, 5]

Sending a `String` from Kotlin to Swift

Declare the method:

external fun sendString(string: String)

On the Swift side:

#if os(Android)
@_cdecl("Java_to_dev_myandroidlib_myfirstandroidproject_SwiftInterface_sendString")
public func sendString(envPointer: UnsafeMutablePointer<JNIEnv?>, clazzRef: jobject, strRef: jobject) {
    // Create lightweight logger object
    let logger = Logger(label: "🐦‍🔥 SWIFT")
    // Access current environment
    let localEnv = JEnv(envPointer)
    // Defer block to clean up local references
    defer {
        // Release local ref to string object
        localEnv.deleteLocalRef(strRef)
    }
    // Wrap JNI string reference into `JString` and get Swift string
    logger.info("✍️ sendString 1")
    guard let string = strRef.wrap().string() else {
        logger.info("✍️ sendString 1.1 exit: unable to unwrap jstring")
        return
    }
    // Now you can use `string` as a regular Swift string
    logger.info("✍️ sendString 2: \(string)")
}
#endif

Call it from your app:

SwiftInterface.sendString("With love from Java")

Check LogCat:

 I  [🐦‍🔥 SWIFT] ✍️ sendString 1
 I  [🐦‍🔥 SWIFT] ✍️ sendString 2: With love from Java

Sending a `Date` Object from Kotlin to Swift

Declare the method:

external fun sendDate(date: Date)

On the Swift side:

#if os(Android)
@_cdecl("Java_to_dev_myandroidlib_myfirstandroidproject_SwiftInterface_sendDate")
public func sendDate(envPointer: UnsafeMutablePointer<JNIEnv?>, clazzRef: jobject, dateRef: jobject) {
    // Create lightweight logger object
    let logger = Logger(label: "🐦‍🔥 SWIFT")
    // Access current environment
    let localEnv = JEnv(envPointer)
    // Defer block to clean up local references
    defer {
        // Release local ref to date object
        localEnv.deleteLocalRef(dateRef)
    }
    // Wrap JNI date reference into `JObjectBox`
    logger.info("📅 sendDate 1")
    guard let box = dateRef.box(localEnv) else {
        logger.info("📅 sendDate 1.1 exit: unable to box Date object")
        return
    }
    // Initialize `JObject` from boxed global reference to the date
    logger.info("📅 sendDate 2")
    guard let dateObject = box.object() else {
        logger.info("📅 sendDate 2.1 exit: unable to unwrap Date object")
        return
    }
    // Call `getTime` method to get milliseconds since epoch
    logger.info("📅 sendDate 3")
    guard let milliseconds = dateObject.callLongMethod(name: "getTime") else {
        logger.info("📅 sendDate 3.1 exit: getTime returned nil, maybe wrong method")
        return
    }
    // Now you can use `milliseconds` as a regular Swift Int64 value
    logger.info("📅 sendDate 4: \(milliseconds)")
}
#endif

Call it from your app:

SwiftInterface.sendDate(Date())

Check LogCat:

 I  [🐦‍🔥 SWIFT] 📅 sendDate 1
 I  [🐦‍🔥 SWIFT] 📅 sendDate 2
 I  [🐦‍🔥 SWIFT] 📅 sendDate 3
 I  [🐦‍🔥 SWIFT] 📅 sendDate 4: 1757533833096

Receiving a String from Swift in Kotlin

Declare a method that returns a value:

external fun ping(): String

On the Swift side, return a string:

#if os(Android)
@_cdecl("Java_to_dev_myandroidlib_myfirstandroidproject_SwiftInterface_ping")
public func ping(envPointer: UnsafeMutablePointer<JNIEnv?>, clazzRef: jobject) -> jobject? {
    // Wrap Swift string into `JSString` and return its JNI reference
    return "🏓 Pong from Swift!".wrap().reference()
}
#endif

Call it from your app:

Log.i("HELLO", "Pinging: ${SwiftInterface.ping()}")

Check LogCat:

 I  Pinging: 🏓 Pong from Swift!

Executing Async/Await Swift Code from Kotlin

Declare the method:

external fun fetchAsyncData(): String

You need to know that the @_cdecl attribute doesn't work with the async operator. That's why we're using a semaphore here to execute our Swift code in a way that feels asynchronous. This approach is totally fine, but only for non-UI code. If you try this on the main thread, you'll face a complete and total deadlock, so just don't do it. I'll show you how to deal with UI in the next articles.

#if os(Android)
@_cdecl("Java_to_dev_myandroidlib_myfirstandroidproject_SwiftInterface_fetchAsyncData")
public func fetchAsyncData(env: UnsafeMutablePointer<JNIEnv>, obj: jobject) -> jstring? {
    // Create semaphore to wait for async task
    let semaphore = DispatchSemaphore(value: 0)
    // Create result variable
    var result: String? = nil
    // Start async task
    Task {
        // Simulate async operation
        try? await Task.sleep(nanoseconds: 5_000_000_000) // 5 seconds
        // Set result
        result = "Async data fetched successfully!"
        // Release semaphore
        semaphore.signal()
    }
    // Wait for async task to complete by blocking current thread
    semaphore.wait()
    // Check if result is available
    guard let result = result else { return nil }
    // Wrap Swift string into `JSString` and return its JNI reference
    return result.wrap().reference()
}
#endif

Call it from your app (off the main thread!):

CoroutineScope(Dispatchers.IO).launch {
    Log.i("ASYNC", "Swift async call started")
    try {
        val result = SwiftInterface.fetchAsyncData()
        Log.i("ASYNC", "Swift returned: $result")
    } catch (e: Exception) {
        // Handle error
    }
    Log.i("ASYNC", "Swift async call finished")
}

Check LogCat:

 I  Swift async call started
 I  Swift returned: Async data fetched successfully!
 I  Swift async call finished

Wrapping Java Classes in Swift

To use Java classes Swiftly, we need wrappers. Let's create one for java/util/Date:

public final class JDate: JObjectable, Sendable {
    /// The JNI class name
    public static let className: JClassName = "java/util/Date"

    /// JNI global reference object wrapper, it contains class metadata as well.
    public let object: JObject

    /// Initializer for when you already have a `JObject` reference.
    /// 
    /// This is useful when you receive a `Date` object from Java code.
    public init (_ object: JObject) {
        self.object = object
    }

    /// Allocates a `Date` object and initializes it so that it represents the time
    /// at which it was allocated, measured to the nearest millisecond.
    public init? () {
        #if os(Android)
        guard
            // Access current environment
            let env = JEnv.current(),
            // It finds the `java.util.Date` class and loads it directly or from the cache
            let clazz = JClass.load(Self.className),
            // Call to create a new instance of `java.util.Date` and get a global reference to it
            let global = clazz.newObject(env)
        else { return nil }
        // Store the object to access it from methods
        self.object = global
        #else
        // For non-Android platforms, return nil
        return nil
        #endif
    }

    /// Allocates a `Date` object and initializes it to represent the specified number of milliseconds since the standard base time known as "the epoch", namely January 1, 1970, 00:00:00 GMT.
    /// 
    /// - Parameter milliseconds: The number of milliseconds since January 1, 1970, 00:00:00 GMT.
    public init? (_ milliseconds: Int64) {
        #if os(Android)
        guard
            // Access current environment
            let env = JEnv.current(),
            // It finds the `java.util.Date` class and loads it directly or from the cache
            let clazz = JClass.load(Self.className),
            // Call to create a new instance of `java.util.Date`
            // with `milliseconds` parameter and get a global reference to it
            let global = clazz.newObject(env, args: milliseconds)
        else { return nil }
        // Store the object to access it from methods
        self.object = global
        #else
        // For non-Android platforms, return nil
        return nil
        #endif
    }
}

This right here is the absolute bare minimum you need to get this class working. It lets you initialize a java.util.Date from scratch or wrap an incoming JObject that's already the right class.

Alright, the skeleton is built. Now we need to give it some muscles, let's write down the class methods!

/// Returns the day of the week represented by this date.
public func day() -> Int32? {
    // Convenience call to `java.util.Date.getDay()`
    object.callIntMethod(name: "getDay")
}

You get the idea! Now, go ahead and do the exact same thing for the getHours, getMinutes, getSeconds, and getTime methods. It's just more of the same pattern!

Now for something a bit more interesting: a more complex method that takes another JDate as a parameter.

/// Tests if this date is before the specified date.
public func before(_ date: JDate) -> Bool {
    // Convenience call to `java.util.Date.before(Date date)`
    // which passes another `Date` object as a parameter
    // and returns a boolean result
    object.callBoolMethod(name: "before", args: date.object.signed(as: JDate.className)) ?? false
}

And, you guessed it, do the same thing one more time for the after method. It's practically identical to before.

Finally, to cover the absolute minimum and make this class actually useful, let's add a super convenient method that converts our Java JDate into a native Swift Date object.

/// Converts this java `Date` object to a Swift `Date`.
public func date() -> Date? {
    // Get milliseconds since epoch using `getTime` method
    guard let time = time() else { return nil }
    // Convert milliseconds to seconds and create a Swift `Date` object
    return Date(timeIntervalSince1970: TimeInterval(time) / 1000.0)
}

Now you have a basic understanding of how Swift works with Java/Kotlin via JNI! I hope you've successfully compiled and tested this with your Android project.

That's all for today, folks!

For even more deep dives and advanced features, check out the comprehensive JNIKit README on GitHub. It's packed with details!

Find me in Swift Stream Discord community, join and don't hesitate to ask questions!

Hit subscribe so you don't miss the next article! We'll definitely talk about library distribution via JitPack, dive into more complex JNI cases, and the... UI!

Stay tuned!

Systemd for the Swift app

Mikhail Isaev — Sat, 12 Oct 2024 21:57:21 +0000

This post is for server-side Swift developers.

All apps on a server need to be launched under some watchdog daemon. You might already be using supervisord or systemd.

This article will show you how to simplify your life with systemd by integrating it directly into your app.

First, let's look at how we usually work with systemd and the steps needed to set up a service.

Pure `systemd`

Setting Up

Create a unit configuration file manually by searching for examples online and saving it in the /etc/systemd/system folder.

Not so easy, right? Most people give up somewhere around here.

Management

You have to remember a few simple commands:

systemctl start   myapp.service
          restart myapp.service
          stop    myapp.service

But also the name you gave your service 🙉

Don't forget to start your app after creating the unit configuration file.

If You Want to Remove the Service

systemctl stop myapp.service
systemctl start clean --all

Not too hard to remember, but still...

Logs

This is where most people get lost, because logs can either be stored in some .log files somewhere in the system, or you have to use journalctl commands like these:

For live logs:

journalctl -u myapp -f

For the last few log lines:

journalctl -u myapp -n 100 --no-pager

I believe it's a bit hard to remember, and I often use the up-arrow in the console to find the right command from history.

🍰 The Swift Plugin Way

SwiftSystemd to the rescue!

It provides a simple way to handle all the above without headaches.

⚡️ Installation

Open your app's Package.swift and add just one line:

.package(url: "https://github.com/MihaelIsaev/SwiftSystemd.git", from:"1.0.0")

After that, you're ready to go!

🛠️ Setting Up

Let's see how to create a proper unit configuration file for systemd. In the folder with your app, just run:

swift run systemd install

It will prompt you with a few questions in the console, and then you're done.

Or you can specify the answers in advance like this:

swift run systemd install -c release -t App -u mike

where
-c or --config is for configuration: release or debug
-t or --target is for Executable target name
-u or --user is for user under which the service will run

This command generates the following unit config file:

[Unit]
Description="AppName"
After=network.target

[Service]
User={user}
EnvironmentFile=/path/to/AppName/.env
WorkingDirectory=/path/to/AppName
TimeoutStopSec=2

Restart=always

ExecStart=/path/to/AppName/.build/{config}/{target}

[Install]
WantedBy=multi-user.target

That's it! You've set up your app the right way in just two simple steps, and it's already running.

📋 Logs

One of the most essential tasks is watching logs, and it's as easy as:

swift run systemd logs

This displays live logs of your app via journalctl.

swift run systemd logs --limit 100

This shows the last 100 lines from your app's log via journalctl

Easy to remember!

🎛️ Management

You can check the app's status by running:

swift run systemd status

Or manage the app state with the following commands:

swift run systemd start    # starts the app
                  stop     # stops the app
                  restart  # restart the app
                  disable  # temporarily disables the app
                  enable   # re-enables the app

You can also send a kill signal to the app:

swift run systemd kill

🧹 Cleaning Up

If you no longer need the service, you can remove it easily:

swift run systemd uninstall

This deletes the systemd configuration file and stops the service if it's still active.

👏 Conclusion

I believe you can now throw away all your systemctl and journalctl notes, just like I did!

❤️ Feel free to contribute!

DEV Community: Mikhail Isaev

Duck: DuckDB for Swift. Powerful SQL inside iOS and macOS apps

Looking for PostgreSQL for mobile apps

Models and everyday data access

The SQL I wanted on the client too

Reusing queries and query fragments

Codable doesn't mean SELECT *

Migrations and transactions

A few more DuckDB features

Native LIST values

Bulk insertion

Reactive SQL queries for SwiftUI and UIKit

Observation efficiency

Concurrency and connection pooling

Will Duck replace SQLite?

Trying it

Conclusion

Swift on Android: JNIKit 2.11.0: Automatic Memory & 2D Arrays

Automatic Memory Control

1D & 2D Array Support

Enhanced Debugging

Links:

The Swift Android Setup I Always Wanted

What You'll Need:

Creating a New Project

Preambula

What is JNI

What is JNIKit

The Project

Structure

The Swift Code

Class Loader and Cache

Can I use Java's toString()?

Environment on Another Thread

How the Code Looks on the Other Side

Java

Kotlin

Building the Swift Project

The Java/Kotlin Project

Source Code

Gradle Files

Assemble with Gradle

Add This Library to Your Android Project (Locally)

Getting the .AAR File

Let the Magic Begin! 🚀

The Development Loop

JNI Examples

Sending an Int from Kotlin to Swift

Sending an IntArray from Kotlin to Swift

Sending a String from Kotlin to Swift

Sending a Date Object from Kotlin to Swift

Receiving a String from Swift in Kotlin

Executing Async/Await Swift Code from Kotlin

Wrapping Java Classes in Swift

Systemd for the Swift app

Pure systemd

Setting Up

Management

If You Want to Remove the Service

Logs

For live logs:

For the last few log lines:

🍰 The Swift Plugin Way

⚡️ Installation

🛠️ Setting Up

📋 Logs

🎛️ Management

🧹 Cleaning Up

👏 Conclusion

Can I use Java's `toString()`?

Sending an `Int` from Kotlin to Swift

Sending an `IntArray` from Kotlin to Swift

Sending a `String` from Kotlin to Swift

Sending a `Date` Object from Kotlin to Swift

Pure `systemd`