# \[Accepted\] SE-0463: Import Objective-C completion handler parameters as \`@Sendable\`

**URL:** <https://forums.swift.org/t/accepted-se-0463-import-objective-c-completion-handler-parameters-as-sendable/78489>\
**Category:** Announcements\
**Created:** [March 13, 2025, 5:04am UTC](https://forums.swift.org/t/accepted-se-0463-import-objective-c-completion-handler-parameters-as-sendable/78489 "2025-03-13T05:04:47Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [March 13, 2025, 5:04am UTC](https://forums.swift.org/t/accepted-se-0463-import-objective-c-completion-handler-parameters-as-sendable/78489/1 "2025-03-13T05:04:47Z")

</div>

Hello, Swift community.

The [review](https://forums.swift.org/t/se-0463-import-objective-c-completion-handler-parameters-as-sendable/78169) of [SE-0463: Import Objective-C completion handler parameters as `@Sendable`](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0463-sendable-completion-handlers.md) ran from February 27th through March 10th, 2025.

Feedback on the review was light but positive. The Language Steering Group is in accord with the community, and SE-0463 has been **accepted**.

I'd like to thank the reviewers for taking the time to read the proposal, ask questions, and leave feedback on this proposal; it may not seem like much, but these contributions are a vital part of ensuring the quality of the language.

John McCall  
Review Manager

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [March 27, 2025, 2:04am UTC](https://forums.swift.org/t/accepted-se-0463-import-objective-c-completion-handler-parameters-as-sendable/78489/2 "2025-03-27T02:04:10Z")

</div>

I keep encountering this issue. Here's today's example:

```swift
import SwiftUI
import AVFoundation

struct RecordingView: View {
  // ...
 
  func recordButtonPressed() {

    AVAudioApplication.requestRecordPermission { granted in
      guard granted else {
        self.error = .recordingPermissionDenied
        return
      }
      self.recorder.startRecording()
    }
  }

}

```

If the user has already granted the app recording permissions, `AVAudioApplication.requestRecordPermission` calls the handler closure synchronously. If the app does not have permissions already granted, the framework will request those permissions from the user and call the handler closure on an arbitrary thread.

Worse is that it seems this information has been lost as APIs have been shuffled around. The docs for [`AVAudioApplication.requestRecordPermission`](https://developer.apple.com/documentation/avfaudio/avaudioapplication/requestrecordpermission(completionhandler:)) do not mention this at all, but if you dig long enough, eventually you'll find its [now-deprecated predecessor](https://developer.apple.com/documentation/avfaudio/avaudiosession/requestrecordpermission(_:)) on `AVAudioSession`, which _does_ mention it:

> The framework may call the thread from a different thread context. Dispatch back to the main thread for any changes that update the user interface.

* * *

The rate at which I'm encountering these errors is alarming. I consider this an exceptionally severe bug, to the point where I feel Swift Concurrency is not usable (certainly in Apple's SDKs) until a fix is available in a shipping release. Anybody who ships code using Swift Concurrency before that time runs the risk of hidden crashes if an SDK method has dynamic concurrency behaviour as `.requestRecordPermission` does -- and developers taking that risk regardless should be aware that the documentation may not be a reliable source for determining whether that behaviour exists.

I haven't tested them, but I would assume the compiler-generated `await x.requestRecordPermission()` functions are also inherently broken, and I'm not aware of any workaround to save them similar to the `@Sendable` closure trick.

Can you confirm whether the upcoming Xcode 16.3 release will include this fix? A release candidate was posted a few days ago, and I searched [the release notes](https://developer.apple.com/documentation/xcode-release-notes/xcode-16_3-release-notes) but could not find any reference to this issue.

If not, I hope it can be released very quickly after that.

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [March 28, 2025, 11:03pm UTC](https://forums.swift.org/t/accepted-se-0463-import-objective-c-completion-handler-parameters-as-sendable/78489/3 "2025-03-28T23:03:58Z")

</div>

This change happened too late to make the Xcode 16.3 release. You will probably have to wait until the release that includes Swift 6.2, whenever that happens.

When the compiler synthesizes completion handlers for ObjC `async` calls, it always uses sendable code patterns.