> Let's say i want to expose an async call to a local sqlite instance on android.

I don’t know, I don’t do android dev. I just made sure my library was running on it then moved on. I know Swift is working on having bidirectional interoperability with Java[1], so I guess when they do it’ll just work? But I did not dig more on the subject.

Regarding the size I’m not sure as I never compiled a binary that is actually useful. I make sure everything runs, but as I’m building a library this goes to building the tests then running them on WASI and that’s it.

Regarding the Swift toolchain version, using swiftly[2] is recommended nowadays if you don’t need Xcode. Using the default toolchain provided by Xcode usually brings trouble when using SDKs. Using swiftly you’ll get the same experience as on Linux basically. (This will probably change, but it is like so currently.)

[1] https://github.com/swiftlang/swift-java

[2] https://www.swift.org/install/macos/#:~:text=Swiftly

▲

bsaul 2 months ago | parent [-]

So.. Is your library only exposing simple synchronous functions, with primitive types that map easily to C ?

I'm confused..

▲

frizlab 2 months ago | parent [-]

Not at all, but I only verified the tests to run on all platforms. I have not checked interoperability with other languages. Verifying the tests pass is just to make sure my lib can be used on these platforms if anybody wanted to use them.

	▲	bsaul 2 months ago \| parent [-]
		ok. If you ever want to see the state of the art (IMHO) i recommend you to look at wasmbindgen and uniffi in rust. The code generated for the consumer side of the library is absolutely insane. It makes it completely transparent, even when exposing nasty async await functions.