Our great sponsors
-
-
cffi
Safe* C foreign function interface for Rust, using proc macros and marshaling types. (by cffi-rs)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
From what you're describing it sounds like you just want to have a Rust library that is used by Swift. If this is the approach you take, then you would need to have C headers and write nice little Swift wrappers around that to make your life not hell. Here is a real life advanced example of how I've done that before.
I use a (poorly documented) crate called cffi to make converting the types between Rust and C (and therefore Swift) as coherent as possible.
Xcode is an angry child when it comes to external dependencies, so I made cargo-cocoapods to make generating a cocoapod out of a Rust crate simple. This will generate a podspec, build all the required targets for iOS and/or macOS, then allow you to bundle the output into a valid zip file that a Cocoapods Podfile can consume.
At the moment I would recommend gRPC for Swift and Rust, even though in general gRPC drives me insane, it is currently the most convenient choice. Use tonic for the Rust server-side, and grpc-swift for the client-side. I've had quite a lot of success with this in the past.
At the moment I would recommend gRPC for Swift and Rust, even though in general gRPC drives me insane, it is currently the most convenient choice. Use tonic for the Rust server-side, and grpc-swift for the client-side. I've had quite a lot of success with this in the past.