swift-bridge VS cargo-xtask

A bit late, but `swift-bridge` (https://github.com/chinedufn/swift-bridge) does this intelligently, and is probably what you're looking for.

4) Another route that I tried is to develop a simple terminal app using SwiftUI with a Xcode project to build that app + link against a Rust library compiled for iOS with the actual logic. I used swift-bridge for this and it works really well, to the point where I have a custom logger that you can simply use the print stuff to SwiftUI from Rust using the log crate. Once I have a bit more time, I will probably try figuring out how to clean this up a bit more.

Since Swift is your first target, I might recommend swift-bridge which can generate bindings for Rust async fns that Swift can call directly.

I'm working on getting my GUI crate (https://github.com/audulus/rui) working on iOS (https://github.com/audulus/rui-ios). Multitouch will be fun. Shout out to the excellent work in swift-bridge: https://github.com/chinedufn/swift-bridge.

So that class SwiftString was actually unused. I've removed it here https://github.com/chinedufn/swift-bridge/pull/33 .

Here's an example of a Rust library that exposes an async function that uses reqwest to make an API call, and a main.swift that calls that async function.

Have you tried Swift Bridge? https://github.com/chinedufn/swift-bridge

💡 Inspired by matklad/cargo-xtask and based on 🏃‍♂️ Write your Rust project scripts in task.rs from the Rust ecosystem.

Using a cargo-xtask task to generate them as a manual step (inlyne currently does this)

As someone else said just is good for that job, or you could implement an xtask helper for these things and setup a suitable development environment with that: https://github.com/matklad/cargo-xtask/

Well tools like cornucopia, prisma-rust-client, protoc-gen-tonic, they don't generate in build.rs, but instead provide either a cli to be called ahead of time, or provide a library that can be called by your own binary (which should generally follow the xtask pattern)

If I understand, this is a tool for when working on the project itself? Akin to a helper script? You could go the cargo install route as already pointed out but there is also the xtask convention.

For simple cli apps for internal use, such as cargo-xtasks, I prefer pico_args due to its fast compile times.

For developer-oriented stuff, there's tools like xshell and cargo-xtask. For operator tasks that need to run in a deployed environment, it's not usually a big lift to add CLI subcommands to your binary. It's certainly more boilerplate and inertia than doing stuff in a live REPL, though, and sometimes difficult to recommend for truly one-off situations.