Add build step to create iOS framework

[breez]

Add build step to create iOS framework

[cnixbtc]

I've been looking into this and have some working code to generate an XCFramework bundle for the Rust binaries.

The reason for using an XCFramework over an old school .framework bundle is that XCFrameworks can include multiple platforms and architectures. That way we get a singe bundle including binaries for:

• aarch64-apple-ios: iOS devices
• x86_64-apple-ios: iOS Simulators on Intel Macs
• aarch64-apple-ios-sim: Simulators on Apple Silicone Macs

This XCFramework bundle can then be dropped into Xcode's Frameworks, Libraries, and Embedded Content section and everything should just work™️:

---

The one thing that's missing still, in my opinion at least, is including the Swift bindings generated by UniFFI. With my current code, the developer would still have to drop the generated breez_sdk.swift file from the make swift-ios step into their Xcode project.

Before continuing to further work on this, I wanted to clarify how we want the final developer experience to be as I believe there's a couple of options:

1. Provide a Swift Package that includes the breez_sdk.swift Swift bindings generated by UniFFI and the XCFramework containing the Rust binaries: That way the developer could simply add the Swift package to their Xcode project and be done.
2. Keep what I have on my fork: That way the developer needs to drop both the breez_sdk.swift and the XCFramework into their Xcode project.
3. Somehow compile the breez_sdk.swift into the XCFramework. That way the developer needs to drop only the XCFramework into their Xcode project.

Any other ideas? Let me know what you think!

[roeierez]

@cnixbtc that looks great!
I think we should explore option 3 as it eventually produces one binary artifact that is self contained and easy for the user to configure.
One of the uniffi output artifact is the .swiftmodule file which is a binary file equivalent to header files for a C framework or library.
I think (although not sure) this file should be embedded inside the framework Modules folder to achieve this goal.

[cnixbtc]

Yeah I agree that would be the nicest developer experience for sure. Unfortunately there's little to no documentation on how to exactly build framework bundles without Xcode. I guess I'll have to do some experimenting to find out how this could be achieved. 🔬 👨‍🔬

[roeierez]

I think it is about putting the swiftmofule files 7nder the Modules dir of the framework but perhaps it is better to build with xcode and then open the archive and see where these files are located.

[cnixbtc]

it is about putting the swiftmofule files 7nder the Modules dir of the framework

That's certainly a part of it yes! It looks like there's more to it, though.

A progress update where my head is currently at: As far as I see it there's two options:

As far as I can tell, if we want to produce .framework bundles, we also need to compile breez_sdk.swift to a library (linking it to the existing Rust bindings in the process). There's some good info on the internal structure of a .framework bundle in this article. We'd then have to combine the module definitions and the library into a separate .framework for each architecture (simulator and device) and pull the frameworks together into a single XCFramework bundle.

There's also the option of creating a XCFramework directly from static libraries and their header files. Again the official documentation is a bit sparse but this could be a way around needing to construct .framework bundles first.

I'm looking into how the Swift Package Manager produces binary packages at the moment to try and reverse engineer the best way to do things.

I'll keep reporting my progress here.

[cnixbtc]

After some discussions we decided to go with option 1 as described above. This is a similar approach to how bdk is doing its Swift bindings.

I've added a build step to the Makefile which fully configures a Swift package. This package can then be dropped into any Xcode or SPM managed project. I'll open a PR for that later today.

A second step, that would make developer experience even better, would be setting up a dedicated repo to which we automatically push a fully configured Swift package on every release of the SDK. That could be achieved using GitHub actions. Again, this is what bdk does too.