Hey guys, I am taking to iOS group in slack channel regarding async/await. Some people said that `a...

# multiplatform

[Vivek Modi]

Hey guys, I am taking to iOS group in slack channel regarding async/await. Some people said that
async/await kmm bridging support in swift is experimental and not recommended to be used in production currently though. So what is the best approach? Any suggestions please

[kpgalligan]

Who said that, and from where did they get that info?

[Arkadii Ivanov]

I believe it doesn't support cancellation, correct me if I'm wrong. If this is true, I would avoid using it in production.

[kpgalligan]

If its the compiler-generated suspend support, I’ve been saying you shouldn’t use that since it launched. You need to create some kind of adapter so you can control the lifecycle. I guess I’m more curious about if I missed some kind of new thing.

[kpgalligan]

The compiler generated suspend functions really don’t make sense to me because you can’t do anything about the lifecycle (as far as I know), and if you wanted to expose a Flow or similar, you’re on your own anyway. Should use https://github.com/rickclephas/KMP-NativeCoroutines or similar, yes?

[kpgalligan]

I’d love to be able to suppress those functions being generated, actually. They just wind up being extra bloat on the API surface (the compiler-generated ones).

[kpgalligan]

I seem to regularly miss new things, though 🙂

[kpgalligan]

Was wondering if there was a new thing.

[Vivek Modi]

https://ios-developers.slack.com/archives/C033DC2TW/p1651698597332589?thread_ts=1651674625.627689&cid=C033DC2TW

[Vivek Modi]

I got this news from iOS developer slack channel

[kpgalligan]

Interesting. I’d have to dig into the compiler support more. I still don’t think the compiler-generated functions are a great way to call suspend functions because of the lack of coroutine context. Guess it depends on how you look at it and what you’re doing with it, though.

[kpgalligan]

The compiler functions are “experimental”, but as far as I know, you can do this with the various library options. I feel like I’m yelling to an empty room when I say “don’t use the compiler generated suspend functions”, but anyway. I assume whatever the compiler generates is designed to conform to whatever hack Obj-C/Swift interop has to simulate “async” calls, but I’ll have to defer to others on that.

[kpgalligan]

If I get the energy (and supporting info) I’ll jump into the iOS debate tomorrow. Maybe 🙂

[Vivek Modi]

Thank you kevin

[Vivek Modi]

Really appreciate ☺️

[Rick Clephas]

don’t use the compiler generated suspend functions

Completely agree!

I assume whatever the compiler generates is designed to conform to whatever hack Obj-C/Swift interop has to simulate “async” calls

Jup from the Kotlin side not much has changed. Kotlin still exports functions with completion handlers. As part of the Swift concurrency interop with ObjC those completion handler functions can be used as async functions in Swift.
In the end it’s still a completion handler though, so there is no cancellation support for these “async” functions.

This interop is an easy way to use ObjC APIs in your concurrent Swift code. However IMO it’s very confusing when combined with Kotlin. Just from looking at the generated code you expect your suspend function to be correctly mapped to async functions. Which unfortunately isn’t the case.