I've been looking through my source code for completion handlers that might benefit from the new async/await features. A few of them are UIKit completionHandlers, e.g. UIViewController#present(animated:completion:), and UIViewController#dismiss(animated:completion:).

I thought it might be nice to replace code that uses a completion handler for the presentation/dismissal animation with cleaner async/await-oriented code, e.g.

await oldController.dismiss(animated: true)

// now animation is complete, do some cleanup

However, async-oriented functions don't exist for these API's. Their declarations actually include an NS_SWIFT_DISABLE_ASYNC directive that seems to prevent that from happening.

I was curious why that is. Is it a bad idea for me to write my own async-oriented wrappers for these? Or will they be coming later?

The existence of a modifier explicitly preventing these functions from being generated suggests that maybe there's some fundamental reason that this kind of programming won't work, e.g. a deadlock issue.

Probably because UIKit is actually an Objective-C set of frameworks with Swift wrappers. Not sure if async/await works yet with anything other than pure Swift.

No, I don't think that's it. URLSession is Objective-C as well, for example, but supports async. And there are lots of details in the proposal about automatically translating Objective-C API's into async functions.

It’s probably because these APIs should only be called from the main thread/actor and it generally wouldn’t make sense for another actor to call these methods, so they were marked as blocked from the async/await overlay.

Terms of Service

Privacy Policy

Cookie Policy