Is it effective to use an XCFramework oriented dependency when using a package for Server Side swift?

I've been fiddling with a library (automerge-swift) that uses a back-end library that's written in Rust, so far primarily in macOS and iOS. On a lark, I decided to see what I could do with it in a server-side context.

The project exposes the Rust code as a C library interface wrapped behind a Swift package encapsulating it, and presents it as an XCFramework. The framework creation process carefully assembles various platform builds (arm, intel, etc), so I thought it might "just work". However, while that package is getting downloaded and unpacked, when I compile the front-end library code on Linux, the compiler is complaining about the package not being able to be imported.

I wasn't sure using compiling swift on linux was compatible with the c-library wrapping w/ XCFramework that was done for macOS and iOS. If I want to get this operational, do I need to take a different tact on getting that backend static library available?

1 Like

This directory contains the script and components needed to generate an XCFramework that allows the Apple platforms to link and use the backend for Automerge, implemented in Rust.

You need to click that link in the readme and compile it for Linux. XCFramework is an Apple construct to distribute the same library for different architectures and Apple platforms in 1 package.

1 Like