Seeking feedback: Polkabind (Swift/Kotlin bindings over Subxt with UniFFI)

[wassimans]

Hi all,

I’ve been working on Polkabind, a thin Rust façade over Subxt that exposes a stable FFI API via UniFFI. The goal is to provide in a first time native Swift and Kotlin bindings (distributed via SwiftPM and Maven) so that iOS and Android developers can interact with Substrate/Polkadot chains without needing to touch Rust directly. Other language support will come after (Python notably).

Concretely:

• Rust façade handles Subxt client, calls, subscriptions, error mapping.
• UniFFI generates bindings → XCFramework + SwiftPM package, and AAR + Maven package.
• Example apps in SwiftUI/Jetpack Compose already demonstrate a transfer flow against a Chopsticks node.
• Roadmap includes balances, fees, staking, multisig, subscriptions, etc.

I recently applied to the W3F Open Source Grant program. One reviewer asked whether this project would truly be useful to the ecosystem, and I’d like to get your perspective as Subxt’s maintainers:

• Do you see a project like Polkabind as aligned with Subxt’s goals of being bindable to other languages (cf. this discussion)?
• Would providing high-level Swift/Kotlin APIs over Subxt lower the barrier for mobile/Web3 developers to integrate with Polkadot/Substrate chains?
• Is there anything in Subxt’s roadmap that might overlap or conflict with this approach?

I’m not asking for endorsement of funding, only for your technical perspective: whether this project makes sense in your view and how it might fit into the Subxt ecosystem.

Thanks a lot for your time, and for your work on Subxt, it’s been very inspiring to contribute (I added the FFI example via C) and I’d love to make Polkabind a useful companion for the ecosystem.

Best,
Wassim

(CC @jsdw)

[jsdw]

Hello Wassim!

Personally, while I don't know specifically about UniFFI, I love that you are exploring in this area!

To answer your points:

Do you see a project like Polkabind as aligned with Subxt’s goals of being bindable to other languages (cf. #2051)?

Yup; Subxt was very much designed with the idea that it would be accessible from many languages via FFI.

I have tended to steer people towards creating custom FFI bindings to expose precisely what their app needs in the past. This is because building a comprehensive interface around Subxt to meet general purpose use cases would take quite a lot of work I think, and we haven't had the manpower to build and then maintain that sort of thing going forwards (especially with the idea that we'd have to do this for every single language that we wanted to support).

Perhaps UniFFI makes this way more manageable (I'm afraid I don't know about it really), and allows interfaces in many languages to be created and maintained more easily? If so, I would definitely endorse working on this!

Roadmap includes balances, fees, staking, multisig, subscriptions, etc.

I guess your idea is to create a higher level wrapper around Subxt rather than exposing the lower level primitives? I would take into account that people may want to make quite arbitrary calls and storage accesses and so perhaps it's worth also exposing a lower level interface much like Subxt, to keep the library fairly general purpose?

Interestingly we have plans internally to eventually build a "Facade" which is basically higher level APIs like for staking/balances etc. This would be in TypeScript initially but eventually might make its way to Rust too, at which point it may offer a perfect interface to copy or eventually FFI from actually.

Would providing high-level Swift/Kotlin APIs over Subxt lower the barrier for mobile/Web3 developers to integrate with Polkadot/Substrate chains?

I would certainly hope so! As a swift developer, the thoughts of having to FFI via Rust would add a lot of overhead over having some swift native interface for the same.

Is there anything in Subxt’s roadmap that might overlap or conflict with this approach?

Nope! I can't speak to the future as priorities may change, but there is nothing on our roadmap related to developing FFI wrappers around Subxt at the moment :)

[wassimans]

Hi @jsdw thanks a lot for the thoughtful reply!

Your guidance helped me clarify the real need: rather than a big high-level wrapper, the ecosystem benefits most from a general-purpose FFI around Subxt’s primitives (dynamic extrinsics, storage, events, constants, metadata), so that any language that can call a C-ABI can use them. Same as we did for the FFI example.

I’ll try to pivot Polkabind accordingly:

• Build a small Rust core that adapts Subxt’s primitives, maybe by defining a minimal JSON schema for args and values, and maps errors.
• Expose that core via a stable C-ABI so Swift/Kotlin/Python/Go/C# can bind easily.
• Optionally a tiny CLI over the same core, so users can prototype by talking to the CLI and parsing JSON, and later, when they want speed they switch to the C-ABI. Same semantics, same outputs. This can also help in CI, quick testing.

I'll be very grateful at this stage, if you have any kind of recommendation or advice to share.

Thanks again for the steer. I’ll share progress as soon as I have the first slice working.