Add a relatively simple way to compile and generate Swift bindings.

[gezihuzi]

As mentioned in issue #1623 , by using the cargo-xcode crate, Rust crates can be quickly compiled into static (or dynamic) libraries. Then, by wrapping the generated code with UniFFI into a Framework, the process of integrating Rust crates can be simplified.

[mhammond]

This looks great at a quick glance, thanks! I'll look more in a few days, but in the meantime: I don't know much about xcode, but how difficult would it be to describe how to create the project in xcode rather than adding an entire project to the repo? It seems a shame cargo-xcode can't help :)

[gezihuzi]

This looks great at a quick glance, thanks! I'll look more in a few days, but in the meantime: I don't know much about xcode, but how difficult would it be to describe how to create the project in xcode rather than adding an entire project to the repo? It seems a shame cargo-xcode can't help :)

Thank you for reviewing this PR. Let me explain my thoughts. Developers can certainly continue to use the method mentioned in Integrating with Xcode (implementation in examples/app/ios) to compile Rust crate dependencies. However, cargo-xcode only requires one command to quickly generate an Xcode project that can be directly used and imported as a target dependency into other Xcode projects. It is simply a simpler and faster alternative solution. Regardless of which approach is chosen, the ultimate goal is to use Xcode for related development work, so I hope that integrating Rust crates can be as simple, clear, and fast as possible.

[mhammond]

However, cargo-xcode only requires one command to quickly generate an Xcode project that can be directly used and imported as a target dependency into other Xcode projects.

That's why I was a little surprised to find what appears to be an xcode project as part of the PR - I don't think it captures exactly how it makes life easier. Isn't there some way to demonstrate it without so many new files added to the repo?

[gezihuzi]

However, cargo-xcode only requires one command to quickly generate an Xcode project that can be directly used and imported as a target dependency into other Xcode projects.

That's why I was a little surprised to find what appears to be an xcode project as part of the PR - I don't think it captures exactly how it makes life easier. Isn't there some way to demonstrate it without so many new files added to the repo?

I provided an example application project that has the same content as the document. This Xcode sample application is optional.

[theolampert]

I think it's a great idea to add this to the documentation, I was looking for something like this. But I feel relying on another tool is quite opinionated, I think it would make more sense if the UniFFI docs just provided a minimal, working example as a starting point. Generating and configuring an Xcode project should be left up to the end user.

Maybe something like the bash script the y-crdt people are using here could be helpful? I was able to modify that to create an xcframework which I could drag into Xcode along with the generated Swift file or package as an SPM module.

[mhammond]

I think it's a great idea to add this to the documentation, I was looking for something like this.

Yeah, I'm still trying to find the correct balance here.

But I feel relying on another tool is quite opinionated, ... Maybe something like the bash script the y-crdt people are using here could be helpful?

But that's another tool, right? That one is written in bash while the other is in Rust, but I don't see a difference. And the Rust version is more likely to work on Windows :)

I think it would make more sense if the UniFFI docs just provided a minimal, working example as a starting point. Generating and configuring an Xcode project should be left up to the end user.

I'm inclined to agree with that - if we end up where we don't actually check any xcode projects in, but instead just allow a some relatively modest instructions, is there any reason we can't allow many tools to be so documented?

[theolampert]

But that's another tool, right? That one is written in bash while the other is in Rust, but I don't see a difference. And the Rust version is more likely to work on Windows :)

Yeah, that's definitely fair. It was clearer to me to look over a bash script and see what the exact steps were to get something similar working in my app and how I'd use it in a CI pipeline for example. I have to admit, I forgot Windows support. The cargo-xcode library lists Xcode as a requirement, however, so it might not work either. I also stumbled on this https://github.com/antoniusnaumann/cargo-swift - maybe it's somehow useful for reference too.

[badboy]

I think it's a great idea to add this to the documentation, I was looking for something like this.

Yeah, I'm still trying to find the correct balance here.

But I feel relying on another tool is quite opinionated, ... Maybe something like the bash script the y-crdt people are using here could be helpful?

But that's another tool, right? That one is written in bash while the other is in Rust, but I don't see a difference. And the Rust version is more likely to work on Windows :)

I don't think Windows support really plays a role for any Xcode-related project. You will need a Mac anyway.

---

As seen above I gave this a first look, but I'll take a detailed look tomorrow again.