Suspend Functions as Swift async

A Kotlin suspend function is exposed to Swift as an async method, so iOS can await it with native Swift concurrency.

Older bridges forced completion handlers. Modern KMP maps suspend straight to async, so Swift code stays clean and linear.

From Swift you simply await the call inside an async context. The coroutine runs and resumes Swift when it finishes.

If the suspend function can fail, Swift sees it as a throwing async method, so you wrap the await in try and catch errors.

When Swift cancels its Task, that cancellation propagates into the Kotlin coroutine, stopping the shared work cleanly.

Call your async shared function from inside a Swift Task when you are not already in an async context, such as a button tap.

The coroutine runs on whatever dispatcher you set in shared code, so heavy work stays off the iOS main thread by default.

Whatever the suspend function returns becomes the result of the Swift await, mapped through the usual Kotlin-to-Obj-C rules.

A suspend function returning Unit shows up in Swift as an async method that simply returns nothing, just like void.

Plain KMP gives you basic async support, but tools like SKIE generate even smoother Swift signatures for these suspend calls.

The big win is readability: shared async logic reads top-to-bottom in Swift, with no nested callbacks or completion pyramids.

Let us check how a suspend function feels from Swift.

Kotlin suspend becomes Swift async: await it in a Task, catch thrown errors, and cancellation flows both ways. Clean concurrency. ✅